View Issue Details

IDProjectCategoryView StatusLast Update
0032098mantisbtbugtrackerpublic2023-05-04 16:24
Reportertk Assigned Todregad  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionunable to reproduce 
Product Version2.25.6 
Summary0032098: 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

TagsNo tags attached.
Attached Files
php81_initial_delay.png (39,651 bytes)   
php81_initial_delay.png (39,651 bytes)   

Relationships

related to 0032086 closeddregad IssueViewPageCommand.php line 135: 'Undefined array key "version" with php 8.1.16 

Activities

dregad

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

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

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

tk

2023-03-24 12:01

reporter   ~0067524

login_delay.png (41,059 bytes)   
login_delay.png (41,059 bytes)   
tk

tk

2023-03-24 12:02

reporter   ~0067525

login_response.png (16,500 bytes)   
login_response.png (16,500 bytes)   
dregad

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

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

dregad

2023-03-24 13:58

developer   ~0067528

may be you can preproduce when cutting down you internet access.

Makes no noticeable difference.

tk

tk

2023-03-30 04:20

reporter   ~0067594

Last edited: 2023-03-30 04:20

As I've learnt yesterday currently we see a similar performance issue with another application on our webservers (30sec delay).
So I assume the problem is actually related to our environment, as you assumed earlier.

dregad

dregad

2023-03-30 12:13

developer   ~0067597

OK, thanks for the feedback. I'm resolving this issue as unable to reproduce. Again ;-)