

![]() | Start a set with this search |
![]() | Include this search in one of my sets |
![]() | Exclude this search from one of my sets |
![]() | Permalink to these results Paste this link in email or IM: |
| Atom feed for tracking future search results Paste this URL into your reader: |
8 messages in ru.sysoev.nginxRe: response times and network io| From | Sent On | Attachments |
|---|---|---|
| Joe Williams | Feb 28, 2008 6:06 pm | |
| Joe Williams | Feb 28, 2008 6:24 pm | |
| Igor Sysoev | Feb 29, 2008 8:38 am | |
| Joe Williams | Feb 29, 2008 9:05 am | |
| Igor Sysoev | Feb 29, 2008 1:23 pm | |
| Joe Williams | Feb 29, 2008 1:53 pm | |
| Denis S. Filimonov | Feb 29, 2008 2:43 pm | |
| Joe Williams | Feb 29, 2008 7:59 pm |

![]() | Permalink for this message Paste this link in email or IM: |
![]() | Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: response times and network io | Actions... |
|---|---|---|
| From: | Denis S. Filimonov (den....@public.gmane.org) | |
| Date: | Feb 29, 2008 2:43:55 pm | |
| List: | ru.sysoev.nginx | |
You are using a tiny file (robots.txt) for your measurements, which means HTTP headers constitute large part of the traffic and may well account for 10-15% difference.
Denis.
On Friday 29 February 2008 16:54:09 Joe Williams wrote:
Understood, thanks for the insight. The Nginx was consistently 10 to 15% lower than Apache, such as 98MB/s versus 110MB/s.
If you would like to see my results for httperf you can download the spreadsheet here: http://www.joeandmotorboat.com/wp-content/files/bench_results-comb-static.o ds
I also posted about it here: http://www.joeandmotorboat.com/2008/02/28/apache-vs-nginx-web-server-perfor mance-deathmatch/
Let me know what you think.
Thanks. -Joe
Igor Sysoev wrote:
On Fri, Feb 29, 2008 at 11:05:37AM -0600, Joe Williams wrote:
I used httperf to give me the network I/O (KB/s) and response times. I could probably produce the sar data from each if you would like it. I assume the response times are due to Nginx not needing to take time to start up another process/thread?
So nginx's network I/O is for example, 20M/s, while Apache's - 100M/s ?
In this case network I/O and response times are the same things. The lesser response times, the more you can get for the same time.
Apache usually does not start new processes, it has some number of already preforked processes ready to handle requests.
Igor Sysoev wrote:
On Thu, Feb 28, 2008 at 08:24:24PM -0600, Joe Williams wrote:
please excuse my typo. regarding network I/O nginx uses consistently lower I/O than apache.
regardless i am curious about how it processes requests differently to obtain lower response times and network I/O.
How do you measure network I/O ?
In short, Apache and nginx use different model for processing requests. Apache processes connection in one process or thread while nginx processes thousand connections in one process/thread using scaleable methods such as kqueue/epoll/etc.
thanks for any help you can provide.
-Joe
Joe Williams wrote:
i am performing some httperf tests against apache and nginx. something i noticed that piqued my interest were the consistency of response times (0.4 ms each run regardless of number of request, much lower than apache in all cases) and network I/O (consistently higher than apache regardless of number of request). it also uses less cpu than apache and doesn't nearly drive up the load.
are these normal results? is there a mechanism in nginx that keeps the response times low and consistent? also, is it normal that it uses more network I/O? if so, what is the cause? to me it would seem like that it uses more bandwidth to respond to the same number of requests which seems inefficient.
please correct me if i am wrong. i am just trying to understand the core differences in how nginx works in comparison to apache and why i would see these performance differences.
thanks for the help.
-joe
-- Name: Joseph A. Williams Email: joe-...@public.gmane.org
-- Name: Joseph A. Williams Email: joe-...@public.gmane.org
-- Denis.







