• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Resolved TTFB high radomly

josede

Basic Pleskian
I have a big issue with TTFB after migration from cpanel. (The same vps in ovh)
My vps has fresh centos 7 installation and plesk.
I have 5 wordpress websites and all of them migrate with wp all import.
When i am in the website and i navegate throw the links, its fine, but sometimes the TTFB (if its not a visited link) goes to 2-8s.
I dont know where is the issue. When it happens, the website is loadding and suddenly, after 8s the web load the page clicked.

Im desperate
 
Yes but thats no sense. I was in 50ms, i go to plesk from cpanel and now 600 ms to 8s randomly. (same vps, fresh centos 7, same websites, all the same)

total used free shared buff/cache available
Mem: 7631 997 499 450 6134 5884
Swap: 0 0 0

This is normal? (8gb vps)
 
Yes but thats no sense. I was in 50ms, i go to plesk from cpanel and now 600 ms to 8s randomly. (same vps, fresh centos 7, same websites, all the same)

total used free shared buff/cache available
Mem: 7631 997 499 450 6134 5884
Swap: 0 0 0

This is normal? (8gb vps)
Change apache to litespeed and you will see the difference.
 
Last edited:
Change apache to litespeed and you will see the difference.
Sorry but this does not have anything to do with Litespeed!
I know so many sites which are powered by Apache and are blazing fast 24/7 so a general statment like this is just not right.

Before judging anything we should analyse the reason for this or the "bottleneck".

But pls do not rely on general statements like this. Yes Litespeed does a lot of things right, but that does not in any way mean that it will solve this issue here.

Also: what is telling you that litespeed will solve this issue if he before had a TTFB of 50ms and now have a TTFB of 0.6s-8s that litespeed is the solution for??
What TTFB do you have with LiteSpeed? A better one then 50ms? Would be keen to know what your TTFB is and if its cached completely static (what is unusable for dynamic content & Shops/eCommerce) or still dynamic caching?

Change apache to litespeed and you will see the difference.

Where did he told anything about his WebServer? Maybe hes already using LiteSpeed, or maybe he it running a pure Nginx Setup? How you know?? He did not wrote anything about this.
 
Sorry but this does not have anything to do with Litespeed!
I know so many sites which are powered by Apache and are blazing fast 24/7 so a general statment like this is just not right.

Before judging anything we should analyse the reason for this or the "bottleneck".

But pls do not rely on general statements like this. Yes Litespeed does a lot of things right, but that does not in any way mean that it will solve this issue here.

Also: what is telling you that litespeed will solve this issue if he before had a TTFB of 50ms and now have a TTFB of 0.6s-8s that litespeed is the solution for??
What TTFB do you have with LiteSpeed? A better one then 50ms? Would be keen to know what your TTFB is and if its cached completely static (what is unusable for dynamic content & Shops/eCommerce) or still dynamic caching?



Where did he told anything about his WebServer? Maybe hes already using LiteSpeed, or maybe he it running a pure Nginx Setup? How you know?? He did not wrote anything about this.

You can think what you want, I just say that after 15 years using apache, switching to litespeed have been the better things that we have made... And also customer have appreciate the change....

Yes, you can spend time to try optimize and get good time to one website with apache... and sometime, if you are expert, you will have success, but customer don't want to spent time in this... they want to get they website works fine after install them, and for this, I am absolutely sure that litespeed have a lot of advantage of apache solution in same hardware, and if you add the cache plugin in case of CMS, only you can make test to view difference.
 
Last edited:
You can think what you want, I just say that after 15 years using apache, switching to litespeed have been the better things that we have made... And also customer have appreciate the change....

Yes, you can spend time to try optimize and get good time to one website with apache... and sometime, if you are expert, you will have success, but customer don't want to spent time in this... they want to get they website works fine after install them, and for this, I am absolutely sure that litespeed have a lot of advantage of apache solution in same hardware, and if you add the cache plugin in case of CMS, only you can make test to view difference.

I can feel you but you dont even know what he uses?
What if he is already using Apache?
Also this problem could be related to things a WebServer can not improve, like temporary DDoS of the whole Server or whatever, ATM we do not know everything, so providing a "solution" in my eyes is very unprofessional.

I used LiteSpeed for some WebProjects but I do not see any improvments over a good optimized Nginx + Apache Setup, but opinions are different and thats pretty ok.

Also I think that the way LiteSpeed is caching is not good for all cases. For Websites its ok/good, but when it comes to dynamic content like Shops/eCommerce it will impact the way things are working as the page you hit will not be 100% up to date due to the agressiv caching.

But thats just my point of view. When it comes to static sites (most WebPages) Nginx will serve them exact as fast as LS.
I do have a TTFB of:

TTFB (Hard Reload):
TTFB Hard Reload.PNG
(32ms)


TTFB (normal):
TTFB.PNG
(30ms)

I'm using Nginx + Apache Setup, so bad TTFB does not directly mean someone is using the wrong technology. Specially if before (same Software) the TTFB was at 50ms which is very good.
 
Last edited:
I can feel you but you dont even know what he uses?
What if he is already using Apache?
Also this problem could be related to things a WebServer can not improve, like temporary DDoS of the whole Server or whatever, ATM we do not know everything, so providing a "solution" in my eyes is very unprofessional.

I used LiteSpeed for some WebProjects but I do not see any improvments over a good optimized Nginx + Apache Setup, but opinions are different and thats pretty ok.

Also I think that the way LiteSpeed is caching is not good for all cases. For Websites its ok/good, but when it comes to dynamic content like Shops/eCommerce it will impact the way things are working as the page you hit will not be 100% up to date due to the agressiv caching.

But thats just my point of view. When it comes to static sites (most WebPages) Nginx will serve them exact as fast as LS.
I do have a

View attachment 16541

I'm using Nginx + Apache Setup, so bad TTFB does not directly mean someone is using the wrong technology. Specially if before (same Software) the TTFB was at 50ms which is very good.

Just have some carrefull with you "unprofessional" opinion, you don't know nothing about us and the experience that we can have... With our plesk servers with SAME numbers of web, SAME traffic, SAME hardware, just switching nginx+apache to litespeed, the number of complaints of problem TTFB have drastically down.

josede have ask about an solution for his wordpress website : THIS is an valid solution to obtain better result, Is the only one? of course no, but for all tests we have make over the lastest years to have better general result with all clients (another time, clients don't generally want to spent time to optimize there web) have been worst that what we have obtain just switching to litespeed.

We have other clients with dedicated servers with just an webmin, nginx / php-fpm configuration with optimized wordpress and very hight traffic and great TTFB, so no need litespeed in these special case, but it's an special case as not all clients are able to spent this time and have capacity of this.

In anycase will not continue answering in this post as seem entering to stupid conversation.
 
Yes you are right. The solution is not litespeed. Literally no sense.

My issue is, i was with cpanel with 50ms and loading the full page in 400ms. Now in the same vps with a fresh centos 7 i have 500ms-8s TTFB.
Its so weird. Ah! I stopped nginx because it was throwing "bad gateway 502" sometimes navigating and sometimes when active-desactive a plugin.

With cpanel i was working with fresh centos 7 and apache only.

In local, some webs have "Start transfer time "0.541" and other "0.145". Its really weird i am going to reinstall all.


Well. I tried litespeed right now and the result its just the same. I will reinstall all..... I will update the thread.
 
Last edited:
If i open a website, i wait 1 hour and i click a internal link. I have this:

Conection Start > Stalled 4.5s
And TTFB 1s

Thats really weird.
 
Well. I tried litespeed right now and the result its just the same. I will reinstall all..... I will update the thread.

Thats exactly what I ment.. befor providing a solution the "problem" have to be discovered. If its not and someone just calls a 'solution' this is just wrong in my opinion and yes IMO this is unprofessional.

But now "opinions" doesnt matter anymore as LiteSpeed does just not solve this issue. This is fact.

And TTFB 1s

Would you mind providing your domain? You can share it here or just send it to me via DM but I would like to do some tests.

Conection Start > Stalled 4.5s

This is very strange indeed. But having long stalled requests is normally stating that your browser is waiting for an already established connection to become available for re-use.
This would result in your Server beeing busy handling the current requests.

Also the chances are high that you do have to few workers or ThreadsPerChild. Pls provide more infos about how you configurated your Domain:

Are you using FPM-Apache, FastCGI-Apache, or CGI-Apache?
If you do not use FPM-Apache, pls try to change to it.

Then adjust (higher) these parameters:
PHP FPM.PNG
Set both to 100 just for testing. Pls notice that you should adjust them to a value your appication really needs somewhen.


Also you should adjust these parameters:

ThreadLimit
ThreadsPerChild


And set both to about (just for testing 2000) Then restart your Apache and retest.

Could be done like this:

<IfModule mpm_winnt_module>
ThreadLimit 2000
ThreadsPerChild 2000
</IfModule>

Also I would recommend you to use Nginx in front of Apache. If something is not working try to solve the problems not just turning thingsof and taking the easiest way :)
 
Last edited:
Thx, i will try all of this. (anyway the plesk was as default with fpm-apache).
My test in the vps:

CPU model : Intel Core Processor (Haswell, no TSX)
Number of cores : 2
CPU frequency : 2399.988 MHz
Total size of Disk : 82.5 GB (6.1 GB Used)
Total amount of Mem : 7631 MB (263 MB Used)
Total amount of Swap : 0 MB (0 MB Used)
System uptime : 0 days, 0 hour 23 min
Load average : 0,01, 1,05, 1,63
OS : CentOS 7.7.1908
Arch : x86_64 (64 Bit)
Kernel : 3.10.0-1062.18.1.el7.x86_64
----------------------------------------------------------------------
I/O speed(1st run) : 64.9 MB/s
I/O speed(2nd run) : 111 MB/s
I/O speed(3rd run) : 111 MB/s
Average I/O speed : 95.6 MB/s
----------------------------------------------------------------------
Node Name IPv4 address Download Speed
CacheFly 205.234.175.175 11.6MB/s
Linode, Tokyo2, JP 139.162.65.37 5.16MB/s
Linode, Singapore, SG 139.162.23.4 8.93MB/s
Linode, London, UK 176.58.107.39 11.7MB/s
Linode, Frankfurt, DE 139.162.130.8 11.7MB/s
Linode, Fremont, CA 50.116.14.9 5.17MB/s
Softlayer, Dallas, TX 173.192.68.18 6.78MB/s
Softlayer, Seattle, WA 67.228.112.250 7.20MB/s
Softlayer, Frankfurt, DE 159.122.69.4 11.6MB/s
Softlayer, Singapore, SG 119.81.28.170 4.35MB/s
Softlayer, HongKong, CN 119.81.130.170 4.58MB/s
 
Node Name IPv4 address Download Speed
CacheFly 205.234.175.175 11.6MB/s
Linode, Tokyo2, JP 139.162.65.37 5.16MB/s
Linode, Singapore, SG 139.162.23.4 8.93MB/s
Linode, London, UK 176.58.107.39 11.7MB/s
Linode, Frankfurt, DE 139.162.130.8 11.7MB/s
Linode, Fremont, CA 50.116.14.9 5.17MB/s
Softlayer, Dallas, TX 173.192.68.18 6.78MB/s
Softlayer, Seattle, WA 67.228.112.250 7.20MB/s
Softlayer, Frankfurt, DE 159.122.69.4 11.6MB/s
Softlayer, Singapore, SG 119.81.28.170 4.35MB/s
Softlayer, HongKong, CN 119.81.130.170 4.58MB/s

Now thats very very very low Internet Speed.
When I try with one of my 20€ VPS I get 800Mb/s - 1.000Mb/s (100MB/s - 125MB/s) Download and the same upload.
This is pretty sure the bottleneck here. Pls contatc your Hoster and report this to him.
Also in seems you are running on a HDD not an SSD but in this case it is not the bottleneck now.
 
Last edited:
Now thats very very very low Internet Speed.
When I try with one of my 20€ VPS I get 800Mb/s - 1.000Mb/s (100MB/s - 125MB/s) Download and the same upload.
This is pretty sure the bottleneck here. Pls contatc your Hoster and report this to him.
Also in seems you are running on a HDD not an SSD but in this case it is not the bottleneck now.
My vps should be ssd.... (i bought as ssd)

Some news....

With new centos 7, new plesk. I add a domain and his TTFB:

with standard plesk page: 50ms always.

with wordpress fresh instalation: 150 ms

with wordpress restored backup: 500 ms
 
My vps should be ssd.... (i bought as ssd)

Possible, but for a SSD its not very fast. Shouldnt be the reason anyway.

with wordpress restored backup: 500 ms

Do you use any kind of caching? OpCache? Some Wordpress Plugin to Cache?
The problem is: we have to determinate what the bottleneck is and then solve it.

with standard plesk page: 50ms always.
with wordpress fresh instalation: 150 ms
with wordpress restored backup: 500 ms

How fast is your TTFB at static assets? I ask this to check if just the TTFB of dynamic content is rising or every respons from the Server
 
In this website i am using fastest cache.

I set pm.max_requestes and pm.max_requests to 100

Now i was in the web clicking internal links:

TTFB:
1º link: 500ms
2º link 500ms
3ºLINK 6.47s

Omg thats no sense. I cant understand nothing.
 
Thanks for the DM.

I checked your Website and I do have some questions:

While testing your Website are you loged in?
Or to ask the question more clear: when you test from an anonym Tab, do you still have a slow Website?

For me seems your TTFB is pending between 60ms - 100ms which is very good.

Pls answer these questions.

Also if your site is very fast from any anonym Tab pls notice this:
- when being logged in your Cookies are bypassing every kind of caching, thats why its slow. This way you always see a 'fresh' generated page instead of a cached one.
 
Edit:

By watching at this
Screenshot (34).png

I think it is your VPS/Connection.
It took (randomly) about 900ms to download a 80kb file and I do have 100MB/s Connection.

Now thats very very very low Internet Speed.
[...]
This is pretty sure the bottleneck here. Pls contatc your Hoster and report this to him.

Like I said here, the internet connection is most probably the problem here. Maybe your Hoster "over-sold" his network.
Is this affecting all Websites installed on this Server?

If you do have another Server, can you try to move the Website and Domain to the other Server and try if the same issue appears on another Server?

You also use PHP 7.0, pls change to the newest supported version. But as you are on Wordpress 5.3.2 PHP 7.4 is recommended for best performance
 
Last edited:
Back
Top