Periodically slow response times

[HebRech GmbH & Co. KG]

I've got an odd issue with my forum. Occasionally the pages will take ages to load and it's always because the server seems to deliberate for seconds before sending any data at all. This is highly time-dependent; there are phases where TTFB is 300 ms but there are also phases where it's 4000 ms or more. Each phase typically lasts for a few minutes.

It can't be load since it also happens on my test forum, which is on a VM in my intranet and has plenty of resources to spare even during slow phases (as does the production server). It's probably also not background processes since those are kicked off by cron so they shouldn't delay page visits.The delay only seems to happen for the main page request, never for content, so I think it has to be something on the PHP side.

The server runs Apache 2.4/PHP 7.2/MySQL 5.6 (InnoDB) on Windows; OPcache is enabled and verified running. There is no further caching enabled.

Are there any common configuration mistakes that typically cause this kind of behavior?

[bfarber]

How active is your community? How long in between these slow requests, or is it quite random?

[HebRech GmbH & Co. KG]

On average I see about 80 concurrently active users (out of about 1,100) with maybe 50-80 new posts a day (plus about 110,000 old posts that were imported from an earlier forum). I haven't been able to determine a pattern in when the forum is slow.

The test forum runs on a clone of the production forum's database so the user and post counts are similar.

[bfarber]

If you adjust your widget caching configuration time (use the AdminCP live search to find the option), does it decrease the frequency of the issue? If so, then this might indicate that widget caches are rebuilding which is causing the periodic slowness.

[HebRech GmbH & Co. KG]

I just did some testing with a profiler. The results are... odd. In those cases where the page load time is especially slow upwards of 40% of the load time are eaten by uniqid(), which the IPS codebase seems to love. Just replacing all instances of uniqid() with random_bytes(13) cut my load time by half. Further tests revealed that while uniqid() is potentially twice as fast as random_bytes() on Linux, it's almost three orders of magnitude slower on Windows.

I will try setting the widget cache time to 15 minutes; mayble that'll help. But I get the feeling that IPS may not be optimized particularly well for the few fools who run Windows webservers. I'll try talking with Invision about this. Perhaps they can make the codebase a bit more Windows-friendly without too much work.

Edit: It turns out that it's apparently not a Windows issue but rather something related to how the VM Windows runs on handles the system timer. Just for the record.

[bfarber]

I'll follow up in your new topic