I’ve been struggling for ages with our TTFB value, which is always over 2 seconds. Everything else is lightning fast.
It definitely seems to be a combination of plugins. I’ve also turned them all off one by one, where I found out → the less, the faster (logically) - but I’ve never found out what exactly causes the +1 second delay.
With Chrome Inspector and the Symfomy Profiler I also tried to find out WHAT exactly the bottleneck is, I’m just not sure where exactly to look.
It would be difficult to do without certain plugins.
But at least a clue which function, which listener, which part is responsible would be great.
You know that the TTFB is the problem. Thus it cannot be any frontend JavaScript.
Next, open different type of pages: category, detail, shop page (e.g. legal notes). Is there a difference between these types? If yes, you can focus on all plugins that are involved in that type. If not, it looks like a more general problem.
Activate the dev mode and also log all SQL query (within the MySQL server) and then look for maybe broken configuration or UUIDs.
There is also a slow query log in MySQL that might help.
thanks for the detailed reply!
its predominantly in the category pages
the „privacy“ page with no images etc has a TTFB of around 1 second which still isn’t optimal, but still better than 2-3 seconds on category pages or 2 second on product pages.
I’ve removed all plugins for testing and it definitely helps, however some of the plugins are essential, that’s why i want to find out what plugin or more specifically what query or request is causing the bottleneck.
so your suggestion would be logging all SQL querys and see which one are „long“ correct?
regarding the dev mode i’ve tried it and utilised the symfomy profiler to check for bottlenecks, however it didn’t reveal much more than chrome inspector or pingdom - maybe i was looking at the wrong areas?
the MySQL Slow Query Log sounds promising - however we are using the nativa MariaDB as our nginx server doesn’t have MySQL8 installed - is there a similar option for MariaDB?
Approximately, how many variants are loaded on one category in complete? Not the 8 or 16 products, their variants included.
What is the RAM limit for PHP?
Which PHP version do you use?
How many PHP processes are allowed to run parallel?
How many and which CPU cores are available?
I guess it is a performance bottleneck.
You should be able to see in the Symphony Profiler how many ms an sql query took.
i did ask my hoster and he replied that the server has lots of resources left even at peak visitor times, so it must be related to some plugins and maybe the server not handling it correctly?
we are using a managed dedicated root server
Intel(R) Core™ i7-7700 CPU @ 3.60GHz (8 core(s))
Version
Plesk Obsidian v18.0.59_build1800240229.10 os_CentOS 7
CentOS Linux 7.9.2009 (Core)
64 Gigabytes of RAM (15GB used on average load)
500GB SSD (80% Full)
on CPU Load it says „2.8“ on average
attached you will find the php settings and the frosch tools status - is there anything which can be increased?
I’m curios about SSD’s read/write performance. Had some issues some time ago, and was due to poor read/write performance. It’s a dedicated server and should perform well - but was just an idea.
just analysed a bit further with profiler
curious that the base.html.twig blog of the storefront standard theme takes 400 ms to render?
Jumps from 94% to 19% for only that block (base doctype and base html)
which would explain a lot because its on every page.
I might add that I added a staging environment under staging.domain.de and the TTFB, after turning off EVERY plugin only improved by 100 ms, so it’s still above 700 for most pages, but never lower than 500.
Plugins aren’t the main cause it seems it must be something with the server config, since the server ressource limits are not even close to being hit
okay, if I have some spare time I want to dig deeper whats causing the problem.
When I check the stats for example „Stabilo.com“ which should be an sw 6.6.x shop (js is split for dynamic imports) the inital page load is around 500ms+ after that it drops to 30-50ms.
With the new dynamic import it is also more transparent, which plugins they use. They use quite a few as well.
thats pretty nice! were happy to provide any data neccessary
Im pretty sure it has a LOT to do with server configuration, but Ive tried so many iterations of configuration changes and none of them brought the intended effect
CPU: the i7-7700 is released in Q1/2017. So it is very old in the tech world: the hoster should update the CPU. Min 8 physical cores for average usage.
SSD: is that a SATA or M2 SSD? Better usw. M2
PHP: use version 8.3
CentOS: this is End of Life (EOL). The hoster should upgrade to a supported operating system.
But these significant bottlenecks down to minimal php version differences?
Server is quite powerful still compared to what many others are using. Could use an update for sure, but im not sure if thats the underlying cause because other shops on this server worked normally.
