Waiting time is very long, every page


October 3.6.13
php 8.2
maria db
docker desktop

My waiting time by clean page (and others backend pages) without plugins and themes ~2s. I also developed php 8.3 and postgresql - nothing special. That’s not the point. The speed of the file system is also normal. He suggested that I set up laravel - the waiting time is 30 ms. Please help me, I do not understand what the problem is.
p.s. I did not install the profiler

$response = $kernel->handle(
$request = Illuminate\Http\Request::capture()

That’s exactly what it takes.


This is most likely caused by the disk operations in the combiner, something added to the admin panel in v2.

The root of the issue is that Windows 10 is (was) using WSL (Windows Subsystem for Linux), which is a layer between Windows and Linux . Communication between these two (Hard Drive operations) can be quite slow.

Related link: Docker extremely slow, on linux and windows - Docker Desktop for Linux - Docker Community Forums

To run the Image on Windows you will need to use WSL 2 (Windows Subsystem for Linux). Follow the instructions from Microsoft and make sure you use WSL 2.

I’m using Hyper-V. Windows-11. That when working on WSL2, you need to place the project inside wsl, I am also in the course. The problem is deeper somewhere =)

2s response is really very slow; slower than I could intentionally make the code run, so it suggests something external. OC v3 runs much faster than v1 or v2 thanks to benchmarking work we did on the internals. This kind of thing is important to us, so finding the answer is more than a curiosity.

We can try process of isolation. I will list some possibilities I’m aware of:

Do you have xdebug enabled? This can be a performance bottleneck when used with default configuration.

Do all pages produce the slow time, cms and backend pages?

Is the cms using the demo theme?

Do you have debug mode enabled?

Do these performance recommendations make any difference? Web Server Configuration - October CMS - 3.x

Does it happen running Laravel Sail?

Beyond this. Some exact instructions to reproduce it would be great

xdebug is disabled and not installed in the container.
All pages are slow, both backend and frontend.
I tried using a demo theme and the first thing I tried was to reinstall the cms without a demo theme. Unfortunately, the problem remains.
Nginx in a separate container - completely repeats your config.
Laravel sail - I haven’t tried to use it. I’ll try and unsubscribe.

Let me try to deploy everything again today with different versions of octobercms. And I will describe all my steps in more detail.

I can also set up an xhprof profiler nearby. To check the bottleneck.

I tried running different versions of octobercms with xhprof. I have problems in realpath, which in ClassLoader::load Upper Or Lower er → … is Real File Path → is_file(realpath(… apparently there are too many calls because a lot has been added.

In octobercms (figure 2 in the image), the results: 80ms on loading the main one with the default demo theme. The difference there is only php versions 8.0 (ver 2), 8.2 or 8.3 (ver 3) - do not affect performance
I tried to put: opcache.enable_file_override=1 - it didn’t affect anything, I tried to change realpath to an analog, it didn’t help. The speed does not change whether I install the demo theme or not.

UPD: php artisan serve - 380ms waiting time, apparently the problem is somewhere with the docker

docker use hyper-v settings:

octobercms ver 2

ver 3

Hi @pavelmgn

Did you find out what was causing this?

The only difference between v2 and v3 is the database access. The v2 demo theme will be file-based only, whereas v3 will access the database. Internally, they are based on the same framework, and I can’t think of any change that would produce this outcome except the database difference mentioned.

Hi @daft.
Unfortunately, I have not solved this problem. The difference is clearly visible on xhprof. In version 3, the problem is in the ClassLoader. Therefore, I think the problem is in docker + hyper-V.

Ok, I found the problem. It is fixed in v3.6.19

Super! Please tell me what the problem was, just out of curiosity)

Priority order of the autoloader was reversed in v3 as a performance improvement but had the opposite effect