0032098: Long initial delay with mantis 2.25.6 and php 8.1.16 - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update

0032098	mantisbt	bugtracker	public	2023-03-03 11:03	2023-03-25 06:03

Reporter	tk	Assigned To	dregad
Priority	normal	Severity	major	Reproducibility	always
Status	feedback	Resolution	reopened
Product Version	2.25.6

Summary	0032098: Long initial delay with mantis 2.25.6 and php 8.1.16
Description	Mantis 2.25.6 (with patch 0032086) in connection with php 8.1.16 can lead to high delay for setup of initial screen, i.e. Call mantis page --> delay until initial list of issues is shown (anonymous access is enabled, similar to mantisbt.org's site) However, the delay is reproducability not seen when using mantis 2.25.6 with php 7.4.21. The problem appears to depend on browser cache history. I.e., switching between mantis 2.25.6 with php 7.4.21 and mantis 2.25.6 with php 8.1.16 seems to trigger the problem, according to the state the 7.4.21 session is left at. I've added screenshot of strg-shift-e in firefox. Notes: a) I've also seen the problem Login with authenticated user --> delay after initial page (view issues in my case) is setup But this is obviously harder to reproduce, couldn't catch a strg-shift-e for that yet b) In case there is access to external data in the internet this would be prohibited by a firewall. So this /could/ account for the delay.
Additional Information	PHP Version 8.1.16 Apache/2.4.55 (Unix) mysqli: mysqlnd 8.1.16 Authentication: LDAPS, Server is MS-ActiveDIrectory
Tags	No tags attached.
Attached Files	php81_initial_delay.png (39,651 bytes) php81_initial_delay.png (39,651 bytes)

dregad 2023-03-04 11:07 developer ~0067450	Well without being able to reproduce the problem on my end, I'm afraid that it will not be possible to give you much support with this. Looking at your screenshot, I see 2 requests with > 30 seconds duration javascript_config.php -> there could be something caused by MantisBT here, but without further info, impossible for me to say if it is so, or what it could be mantis_logo.png -> that's just an image, so definitely not something caused by PHP version - most likely a problem on your end As things stand, I don't really believe the performance degradation is caused by MantisBT code, especially if you confirm that clearing the cache fixes the issue.

dregad 2023-03-13 12:33 developer ~0067477	You did not provide any feedback; I am therefore resolving this issue as "unable to reproduce".

tk 2023-03-24 12:00 reporter ~0067523	Hi, I repeated profiling again, since I see the problem in all of my 3 mantis deployments. The 30s are wasted during wait or some translations to be loaded, so it does appear to me. Best regards

tk 2023-03-24 12:01 reporter ~0067524	login_delay.png (41,059 bytes) login_delay.png (41,059 bytes)

tk 2023-03-24 12:02 reporter ~0067525	login_response.png (16,500 bytes) login_response.png (16,500 bytes)

dregad 2023-03-24 12:41 developer ~0067526	Still not reproducible at my end. Pages consistently load under 0.3 seconds. I'd like to point out that it is not the same file that is suffering from the 30 seconds delay as in your initial report (last time it was javascript_config.php) so I continue to think that this is caused by environment and not MantisBT code. Do you consistently get the same 30 seconds execution time if you load javascript_translations.php from the browser's address bar with the same query string (cache_key) ? What about without it or with a different cache key value ? Maybe you can trace what is happening during code execution, and find out what is causing the delay.

tk 2023-03-24 13:26 reporter ~0067527	I'll try. Maybe for reproduction it's important to know that internet access is blocked in our environment. So may be you can preproduce when cutting down you internet access.

dregad 2023-03-24 13:58 developer ~0067528	may be you can preproduce when cutting down you internet access. Makes no noticeable difference.