Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have nginx+apache web-server with several sites.

But with very long Time To First Byte (TTFB): 0,5-2 seconds for every request (for static & dynamic content).

How to optimize Time To First Byte (TTFB)?

share|improve this question
    
What are you serving? –  Mark Henderson Oct 30 '11 at 19:23

2 Answers 2

In general, time to first byte is dependent on:

DNS Lookup: Definition: Find the IP address of the domain Improve: more numerous/distributed/responsive DNS servers

Connection time: Definition: Open a socket to the server, negotiate the connection Improve: typical value should be around 'ping' time - a round trip is usually necessary

Waiting: Definition: initial processing required before first byte can be sent Improve: This is where your improvement should be - it will be most significant for dynamic content.

An additional consideration comes from:

Processing (after first byte): Definition: Sum of waiting + complete transfer of content Improve: if the transfer time is significantly longer than what would be expected to download the quantity of data received, further processing is occurring, and may be optimized (e.g. the page is flushing content as it is available)

Given that I don't know how you performed your test (or much about your setup, or the content you are serving), the following are rather general suggestions:

Firstly, try using Firebug on a remote (client side) machine and something such as ab (ApacheBench) on your server. This will help to breakdown the TTFB number into its component values, so that you can focus on fixing them one at a time - or narrow down the problem. Running the test from different locations also helps to point out problems in connection time and DNS lookups which may not occur if run directly from your server. Additionally, you will want to run a ping from the remote machine to your server to determine how much of the time is attributed to simply 'round trip time'.

Secondly, avoid using nginx as a reverse proxy to the extent possible. Expect it to be slower than Apache if every request has to go through nginx before reaching Apache. Try to serve static files directly from nginx (i.e. bypass Apache entirely), and cache some content that is received from Apache (i.e. proxy_cache). Nginx should be able to serve static files extremely quickly, especially if the test is running from the local machine. If this isn't true, then you need to look into your configuration, and the resources being used by your server.

Thirdly, try and determine where your performance is suffering - is it Apache or nginx? Compare the ab results for requests through nginx vs. requests directly to apache (just change the port, and specify the host header) to determine if the reverse proxying is a significant bottleneck).

You have mentioned that the problem applies equally to static and dynamic content - but the next step would be to profile your scripts, and look at slow query logs to determine if there are any significant bottlenecks.

share|improve this answer
    
Thanks for answer. For test I used Firefox's Firebug, webpagetest.org (webpagetest.org/result/111031_NX_21G3B/1/details) and fpt.pingdom.com (fpt.pingdom.com/#!/BOWVDRVWn/romankutsy.com). You can see that TTFB for images is very big. –  RKI Oct 31 '11 at 3:39

Some ideas:

  1. Upgrade your ram (for buffers/cache),
  2. Use the proxy_cache in Nginx,
  3. Use SSD or Ramdisk,
  4. Use a Content Delivery Network.

If you want a more detailed answer you must tell us more about.

share|improve this answer
    
Thanks. But I using proxy_cache in Nginx. Problem is the same for static & dynamic content. –  RKI Oct 31 '11 at 3:48
    
See my comment above: serverfault.com/questions/326164/… –  RKI Oct 31 '11 at 3:49
    
Have you made the sames test from localhost ? It can be a network issue. You can test it from your shell with curl -o /dev/null -w "Connect: %{time_connect} TTFB: %{time_starttransfer} Total time: %{time_total} \n" -s http://www.romankutsy.com –  Adrien P. Oct 31 '11 at 12:32
    
From localhost (romankutsy.com): romankutsy.com NOT IN /etc/hosts (127.0.0.1 romankutsy.com): # curl -o /dev/null -w "Connect: %{time_connect} TTFB: %{time_starttransfer} Total time: %{time_total} \n" -s romankutsy.com Connect: 0,573 TTFB: 2,084 Total time: 2,366 romankutsy.com IN /etc/hosts (127.0.0.1 romankutsy.com): # curl -o /dev/null -w "Connect: %{time_connect} TTFB: %{time_starttransfer} Total time: %{time_total} \n" -s romankutsy.com Connect: 0,003 TTFB: 0,058 Total time: 0,058 –  RKI Nov 1 '11 at 13:17
    
Ok, so Nginx is not the guilty here. Have you particulars rules in you firewall (on public interface) ? –  Adrien P. Nov 2 '11 at 7:32

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.