Menu Close

Speed up for Apache2 server performance

Last Update : 26/02/2017 / Last Review : 26/02/2017 / First Create  : 21/02/2017

If you have long blocking times then the machine running the browser is running slowly. You can fix this by upgrading the machine (more RAM, faster processor, etc.) or by reducing its workload (turn off services you do not need, closing programs, etc.).

Long wait times indicate that your server is taking a long time to respond to requests. This either means:

  1. The request takes a long time to process (like if you are pulling a large amount of data from the database, large amounts of data need to be sorted, or a file has to be found on an HDD which needs to spin up). 
  2. Your server is receiving too many requests to handle all requests in a reasonable amount of time (it might take .02 seconds to process a request, but when you have 1000 requests there will be a noticeable delay).

The two issues (long waiting + long blocking) are related. If you can reduce the workload on the server by caching, adding new server, and reducing the work required for active pages then you should see improvements in both areas.

The most common slow speed reason for Apache is the usage of DNS Reversal Lookup. What this means is that the server tries to figure out what the name of your machine is, each time you make a request. This can take several seconds, and that explains why you have a long WAIT time and then a very quick load, because the matter is not about bandwidth.

The obvious solution for this is to disable hostnamelookup in Ubuntu apache2

HostnameLookups Off

However, this is usually NOT enough. The fact is that in many cases, apache still does a reversal lookup even when you have disabled host name lookup, so you need to take a careful look at each line of your apache config. In particular, one of the most common reasons for this are LOGS. By default on many red hat – centos installations, the log format includes %h which stands for “hostname”, and requires apache to do a reverse lookup. You can see this here:

LogFormat “%h %l %u %t \”%r\” %>s %b \”%{Referer}i\” \”%{User-Agent}i\”” combined
LogFormat “%h %l %u %t \”%r\” %>s %b” common
You should change those %h for %a to solve this problem.

The wait time, also known as time to first byte (TTFB) is how long it takes for the server to send the first byte from when the connection is initiated. If this is high, it means your server has got to do a lot of work to render the page before sending it. You need more information about what your site is doing to render the page.

TTFB is directly influenced by “physical” distance between browser and server. CDN proxy is the best way to shorten said distance. This, coupled with native caching capabilities, will help provide swifter response by loading cached object from the nearest POP (point of placement) location.

Load time is how long it takes for a webpage to be loaded and usable by a browser. Oftentimes in web page delivery a page is compressed in the Gzip format to make the size of the download smaller. This practice prevents the first byte from being sent until the compression is complete and increases the TTFB significantly. TTFB can go from 100-200ms to 1000 -2000ms, but the page will load much faster and be ready for the user in a much smaller amount of time. Many websites see a common 5-10x increase in TTFB but a much faster browser response time garnering 20% load time decrease. There are some drawbacks however in using Gzip compression:

  • server CPU load increases during compression.
  • data can take a long time to process and since a first byte isn’t sent until it’s done compressing it can make the webpage appear to be hung.
  • long times to first bytes will often cause a user to cancel and reissue their request to the web-server resulting in increased CPU loads because of sequential load requests.
Speed up for Apache2 server performance.
How to reduce server “Wait” time?
Taking a good pingdom Test or site performance

Reference for Issue