Jump to content

Bad performance. Time to first byte


h-y-b-r-i-d
 Share

Recommended Posts

A fresh IPS4 setup seems to have a rather large time to first byte.

I have a dedi, optimized php and apache setup. 4 cores, plenty of RAM. SSD drives. Zend opcode/memcached etc being tested from a few miles away. Server in London, test from London.

The TTFB is ~ 1 second. This is abnormal and normally caused by server spec or DB bottlenecks. Server is good. Invisions own site has the same issue when tested. Other forum software responds in ~300 when tested on same server.

Is this something you are aware of and would look into improving?

Edited by DealTrakr
Link to comment
Share on other sites

3 minutes ago, DealTrakr said:

Zend opcode/memcached

Use one or the other, not both. Some people would beg to differ, research that one. One trap many fall into is installing a few different caches. Don't. Zend opcache is very good in PHP 5.5+.

Try using a cloud service. They will also do some caching, but on their side.

 

 

Link to comment
Share on other sites

31 minutes ago, Paul.F said:

Use one or the other, not both. Some people would beg to differ, research that one. One trap many fall into is installing a few different caches. Don't. Zend opcache is very good in PHP 5.5+.

Try using a cloud service. They will also do some caching, but on their side.

 

 

What? Opcache and Memcached are two very different things. 

Link to comment
Share on other sites

1 hour ago, DealTrakr said:

A fresh IPS4 setup seems to have a rather large time to first byte.

I have a dedi, optimized php and apache setup. 4 cores, plenty of RAM. SSD drives. Zend opcode/memcached etc being tested from a few miles away. Server in London, test from London.

The TTFB is ~ 1 second. This is abnormal and normally caused by server spec or DB bottlenecks. Server is good. Invisions own site has the same issue when tested. Other forum software responds in ~400 when tested on same server.

Is this something you are aware of and would look into improving?

https://blog.cloudflare.com/ttfb-time-to-first-byte-considered-meaningles/

Link to comment
Share on other sites

1 minute ago, Paul.F said:

It's not meaningless if Google says it's not meaningless.  While I agree with the idea of not obsessing over small changes in TTFB, there is a large difference in TTFB between IPS and other heavy PHP software on the same server. 

Link to comment
Share on other sites

3 minutes ago, maidos said:

i wonder if php 7 would have any significant impact on TTFB along with httpd 2.0

Anyone wanna do comparison test? :D

It certainly improved it for me but I wouldn't say it's significant. Unfortunately I cannot do a comparison test due to having sucuri in the middle which also affects TTFB :/

Might consider turning it off for a test but not sure yet.

Link to comment
Share on other sites

40 minutes ago, maidos said:

so your server is using httpd 2 aswell?

Yes but since sucuri only supports SPDY it will be served through that unless you bypass sucuri (which I do).

Edit: tested it using webpagetest without having sucuri in the middle, TTFB is 0.500-0.630 seconds (php7 + http/2)

Edited by Ahmad E.
Link to comment
Share on other sites

Yeah, the increase in average server execution time from IPS 3.4 to 4.0 is quite bad at the moment :(

I'll give you a guess on when the community that this chart belongs to was upgraded: 

564a03649ca76_Skjermbilde2015-11-16kl.17

(October 28 is the answer)

I've tracked some of it down to slow queries. But a big part of it seems to be a general significant increase in the execution of the "framework basics" itself. It seems a "fast" page load is now done in approximately a second, while a fast page load in 3.4 was done in 0.25 seconds.

I know 4.1 will bring some improvements, but due to various factors I'm unable to do that upgrade in the immediate future. Still, I suspect 4.1 will still be far from as fast as we had 3.4 running. 

Edited by TSP
Link to comment
Share on other sites

2 hours ago, DealTrakr said:

From some inital testing it does appear that it could be related to opening like 14 connections for the css and js. 2 would be better. 4 even. But 14?

This has nothing to do with the server response time for the initial document (or first byte delivered). Server response time is basically the time it takes for index.php to deliver the HTML-document that tells you to load 14 CSS/JS.

Link to comment
Share on other sites

 

You know I did some testing and gzip did a much better job then memcached.  Try it...   Server settings for this and pigz may make a difference also.

But here is my cpanel optimize configuration for now.  Adding images adversely impacted page load time a lot.

application/x-javascript application/javascript application/xhtml+xml text/html text/xml text/css text/javascript

Keep alive also decreased my page load time by 85%  for my older version site.  And made my 4.1 site 2.5 times as fast.

A ctrl f5 loads my graphic intense and heavily modded older version with VPAID, animated and enhanced ads in 1.5 seconds.  My 4.1 with the same ads loads in 1.75 seconds.  

Edited by Lab Rats Rule
Link to comment
Share on other sites

2 hours ago, ZeroHour said:

You should use innodb but along with MySQL 5.6 or a later MariaDB version as older versions as considered much slower with InnoDB.

It also seems once you run >5.6 with innodb there is no going back to a lessor version..    So if anyone switches servers afterwords, you have to have >5.6.

Link to comment
Share on other sites

16 minutes ago, DealTrakr said:

Running innodb now on mysql 5.6. Seems quicker. Still a cold first page load has some large TTFB.

Have keepalive and gzip enabled anyway. Will try MariaDB over the weekend I think if it's worth it?

I noticed a good performance improvement with MariaDB. Do you also have my.cnf optimized to innodb?

Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...