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
