At Sat, 11 Dec 2010 11:53:17 -0500,
Chetan Sarva wrote:
>
> On Sat, Dec 11, 2010 at 9:12 AM, Dennis Jacobfeuerborn
> <dennisml@conversis.de> wrote:
>
> > I don't have any direct experience with services like EC2 but remember that
> > before the traffic hits your machine it first has to pass through various
> > routers and switches in Amazons infrastructure that is shared between
> > probably millions of EC2 instances. You might either hit a bottleneck on
> > these shared components or maybe Amazon just has put some limitations in
> > place to prevent abuse.
>
> With shared resources you would expect to see a range of throughput
> numbers from when resources are constrained and when they are not. On
> EC2, disk & network I/O is a shared resource and both can be measured.
> I've done raw network throughput tests and they confirm this. With my
> nginx tests (and, to be fair, other webservers as well), I
> consistently get around 12k reqs/sec.
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://nginx.org/mailman/listinfo/nginx

There are some things you have to consider, when doing network benchmarks:
1) bandwidth (as you were told) - you can test with iperf
2) rtt
3) statefull firewall (statefull NAT goes in here too) - big penalty especially when every new request is a new connection and you are using keepalive
4) OS max and per nginx process limits for file descriptors
5) network buffers
6) polling
7) backlog
8) tcp fin timeout
9) nginx number of processes
10) nginx backlog per socket
11) nginx regexp in locations, ifs and so on...
12) nginx keepalive? this is important when you are benchmarking req/s, becase a) 3 way tcp handshake takes some time, closing connections too, b) requests cannot be parallelized per connection

good luck with benchmarking :)

_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx