A good indicator of your Server-side performance is the time it takes to generate the HTML page (page generation time). This is labeled as “Waiting†time on the first element in the waterfall graph (also known as the “time to first byteâ€). Generally, this time should be kept under one second (or as low as possible).
Mine is around 2.91 seconds consistently...seems to be holding my speeds back.
I'm on a dedicated server with LiquidWeb so there shouldn't be lack of resources....using apcu/redis/imagick anything I could find to help.
Any suggestions or things to look for or tell liquid web about???
How much memory on your server? What kind of traffic are you handling?
How much of your physical memory do you have allocated to mySQL? To the file cache?
9 our 10 TTFB issues are related to either general DB performance, the system file cache being too small or 3rd party addons that either communicate remotely or make an unusual number of DB requests. I'd recommend you allocate 1GB to file cache and 25% of the remaining RAM to mySQL.
Suggest you work with your hosting to do performance tuning of your server. I'd disable your redis caching until you get performance under control because it can mask the real problems you need to solve.
Thanks Tony! I was just experimenting with deactiving the scrollers and banners scrolls. Deactivating them did lower my page load time but didn't change the TTFB at all...still at 2.9 or so. Those side scrollers do add a couple seconds to page load though!!
Server is Intel Xeon E3-1230 v5 Quad-Core, 16 gb ram. I definitely don't have traffice issues...I wish. This server it total overkill and I should probably move to something more affordable and the right size for my needs.....and fast TTFB!!!
Ask your hosting to tell you how much of your 16GB is dedicated to file buffers and mySQL. I'd allocate 2GB to mySQL right out of the gate. That will insure that all your indexes and logs remain in memory.
TTFB is a measure of how long the server takes to generate the html page and start to transmit it. All the other measures are related to browser performance and page execution (I.e. JS and other tool kits). You should be under 500ms for TTFB.
Ask your hosting to tell you how much of your 16GB is dedicated to file buffers and mySQL. I'd allocate 2GB to mySQL right out of the gate. That will insure that all your indexes and logs remain in memory.
TTFB is a measure of how long the server takes to generate the html page and start to transmit it. All the other measures are related to browser performance and page execution (I.e. JS and other tool kits). You should be under 500ms for TTFB.
In my experience, this can be blamed on the server on most occassions. Lots of hosters have very old and slow hardware.
Okay, will try your suggestions if I can ever get them to answer the tickets. I sure liked Wired Tree a lot more before they were taken over by Liquid Web.
Ask your hosting to tell you how much of your 16GB is dedicated to file buffers and mySQL. I'd allocate 2GB to mySQL right out of the gate. That will insure that all your indexes and logs remain in memory
Are you talking about the InnoDB buffer pool size here?
Allocating memory to mysql sql is not as simple as saying here is 2 gigs, be faster. Most Mysql settings are based on data size and you do not have 2G worth of data in mysql so you would simply be wasting RAM. Generally getting mysql in line helps the TTL, however in your case it did not help the TTL for the store. These are the configuration options that I have set:
With these changes you can see that the TTFB for your domain is around 3ms each time. Going to the store it is around 2400-2500ms each load. This tells me that there is something in the store that is slowing things down.
I tested again and Full load time is 4.3s now, but I have scrollers off and TTFB is still 2.48s. So, nothing much changed with regards to TTFB.
However, I'm thinking about moving the site to Knownhost Cloud-2 or MVPS-2 setup (each have 4gb or 6gb ram, 2/3 cores). I have about 10,000 items in the shop, 35gb of disc usage...check my stats on this dedicated and it's so low it comes up as 0% ...so it's way overkill for me. Anyone have experience or opinion about these two knownhost setups? Would these be sufficient?
So, I disabled all addons to see what would happen. Total page load time dropped to like 1.2s and TTFB to 300ms or something. All the scores went up. The size was blazing!
So, I disabled all addons to see what would happen. Total page load time dropped to like 1.2s and TTFB to 300ms or something. All the scores went up. The size was blazing!
This can be expected although the difference is very big with you. Maybe it's 1 add-on that's slowing the site down the most, and you can get the site back to reasonable speed with the most important add-ons?
I experimented with the addons for a long time, but none turned out to be a major culprit. However, I changed 'cache backend' from apcu to sqlite and my TTFB dropped to 500ms!! I guess I was under the impression apcu was supposed to be better, in my case, I guess not. Are there specific reasons to use one cache backend over another????
Site fully loads in 2.8s now with most of my add-ons enabled, except a couple scrollers.
Well, it looks like you found the culprit then. I believe cs-cart recommends file for the latest versions (but I'm not 100% sure - someone else knows better?).
Well, it looks like you found the culprit then. I believe cs-cart recommends file for the latest versions (but I'm not 100% sure - someone else knows better?).
We use a tmpfs mount for file cache. Gives you the best possible speed and it is the most reliable.
mySQL will take an overall allocation and then parcel it up as it sees fit. You can then further tweak. But if you've only allocated 100MB then it doesn't matter, you'll be short.
FIRST STEP is to give it enough memory to work with. Tuning mySQL for a certain environment is well outside the the time anyone can spend in the forums! :-) Should never leave the mySQL temporary dir as /tmp. Way too variable and generally too small. Not many applications are very good at cleaning up their tmp files so it can fill up before you know it. Best to put in in the regular file system (and again, with proper file buffer cache size it will stay in memory).
Regarding caching. If you use 'File' and have enough file buffers allocated then all your files (including the cache) will be in memory.
In my experience, simple configurations with adequate hardware are the best solutions because they can be understood as to what's happening, diagnosed and resolved. If you have customer bases across oceans, use a quality CDN. If not, don't bother.
So, I migrated to a new server to save some cash. A Cloud VPS with Knownhost and now my TTFB is back UP to about 1.6s. Back to using database instead of redis for backend cache as they don't have it available to install. Any suggestions on what I might tweak to get back down to 400ms or so??
They suggested this:
"your server is currently running with PHP 7.0 as the default version but with CGI mode enabled, which is one of the slowest PHP processing engines available. I'd recommend switching to DSO with mod_ruid2 as this typically provides the best combination of performance, speed and security."
Why would you use the database to cache the results of database queries and file data. It just further hammers your (more than likely) inadequet mySQL configuration.
Yes, the suggestion is doable. But I don't think PHP startup performance is your issue.
Please see my original post on this issue related to file buffer cache and allocation of memory to mySQL.
CS-cart 4.7.4 on KnownHost Cloud VPS (4 GB ram) running with PHP 7.2 / DSO with mod_ruid2 ....using File cache / Redis session cache and all is running smoothly! The TTFB might be able to come down with some further tweaking as you suggested, but I don't know how to do what you are suggesting myself and the store seems quite fast enough to not garner and complaints from customers, like I was getting when the TTFB was 2.7s.