Hi Joubert,
On Thu, Dec 23, 2010 at 03:29:34PM -0500, Joubert Berger wrote:
> Hi Cyril,
>
> On Wed, Dec 22, 2010 at 7:33 PM, Cyril Bonté <cyril.bo...@free.fr> wrote:
> > Hi Joubert,
> >
> > Le mercredi 22 décembre 2010 22:11:27, Joubert Berger a écrit :
> >> (...)
> >> > For the proxy I am comparing squid (as a reverse proxy) and haproxy.
> >>
> >> For squid, the only major thing I added was:
> >> max_filedesc 32768
> >> cache_dir null /tmp
> >> http_port 80 accel defaultsite=server
> >> cache_peer 192.168.0.120 parent 80 0 no-query originserver
> >> (???)
> >> And now to the results:
> >> And a reminder, I am measuring high concurrency and large transfers. I am
> >> using Apache Benchmark tool (ab).
> >> So, I would do something like:
> >> ab -n 4000 -c 4000 http://192.168.0.115/2M.file
> >>
> >> Here are some results:
> >>
> >> At 800 concurrent connections:
> >> web server (no proxy): 55 req/sec and throughput of 890 Mbps
> >> squid: 53 req/sec and throughput of 875 Mbps
> >> haproxy: 49 req/sec and throughput of 782 Mbps
> >>
> >> At 4000 concurrent connections:
> >> web server (no proxy): 55 req/sec and throughput of 890 Mbps
> >> squid: 41 req/sec and throughput of 664 Mbps
> >> haproxy: 30 req/sec and throughput of 474 Mbps
> >>
> >> I have more data, but for now it shows haproxy not comparing well to squid.
> >> Anyone have any insight what is going on?
> >
> > Have you verified the number of requests received on your nginx backend for
> > each tests ? I wonder if you don't still have cache enabled in squid.
>
> I verified that my configuration did have cache deny all.
>
> >
> > Do you also have this directive in your squid configuration ?
> > cache deny all
> >
> > Or you could retry with -H "Cache-Control: no-cache, must-revalidate" in
> > your
> > ab command line.
> >
>
> I will give that a try, but I don't think it is a caching issue.
Given the numbers I don't think it's a caching issue either. However, could
you check that your haproxy is correctly built to use epoll ("haproxy -vv") ?
Have you checked CPU usage in both configurations ? If haproxy is running
with the legacy poll() or select(), it could very well be running close to
100% system with 4000 connections.
4000 concurrent connections is not much, some sites are regularly running
above 30000 with one reporting more than 150000. And at least one of them
recently reported 5 Gbps of production traffic, reason why I'm finding
your results quite low. In fact, even in my 10gig tests, I achieve around
570 requests per second on 2M objects.
Also, I don't know if this is meant as a pure benchmark or as a test for
future production plans, but 1 Gbps to serve 4000 connections means 250 kbps
on average per connection. While this is more than enough for normal sites
(lots of small objects), you should keep in mind that if your average object
size will be 2M, then your link will be the limiting factor, causing the
average download time to reach one minute for such objects, even if the
visitor have more than 250 kbps of connectivity. Depending on how you
use your benchmarks, it may be something to keep in mind for the site's
scalability.
Cheers,
Willy
