Hello,
Can anyone point me to some to some study that compares the
performance of apache configured as a reverse proxy versus direct
connection to the remote backend web server?
I know my question may be too vague but I 'd like to get an order of
magnitude and also to know what can be tuned to improve the reverse
proxy performance.
Thanks,
Gael
Gael Marziou wrote:
> Can anyone point me to some to some study that compares the
> performance of apache configured as a reverse proxy versus direct
> connection to the remote backend web server?
>
> I know my question may be too vague but I 'd like to get an order of
> magnitude and also to know what can be tuned to improve the reverse
> proxy performance.
The connection through a reverse proxy will always be slightly slower
than a direct connection - assuming no caching is in place. How slightly
is dependant on the speed of the reverse proxy machine, and the speed of
the networks between reverse proxy and backend server.
If there is caching in place, then the performance will depend entirely
on the type of data you're serving (whether it's cacheable or not), and
the speed of your backend.
It's really difficult to benchmark this kind of thing, as there is no
"standard" data type or "standard" machine.
The proxy is very lightweight, significantly more so than most
interactive backends (web applications, php, asp, etc). The best way to
test is is set up a test system and see for yourself in your environment.
Regards,
Graham
--
On Mon, Apr 26, 2004 at 07:19:09PM +0200, Graham Leggett wrote:
> Gael Marziou wrote:
>
> >Can anyone point me to some to some study that compares the
> >performance of apache configured as a reverse proxy versus direct
> >connection to the remote backend web server?
> >
> >I know my question may be too vague but I 'd like to get an order of
> >magnitude and also to know what can be tuned to improve the reverse
> >proxy performance.
>
> The connection through a reverse proxy will always be slightly slower
> than a direct connection - assuming no caching is in place. How slightly
> is dependant on the speed of the reverse proxy machine, and the speed of
> the networks between reverse proxy and backend server.
>
> If there is caching in place, then the performance will depend entirely
> on the type of data you're serving (whether it's cacheable or not), and
> the speed of your backend.
>
> It's really difficult to benchmark this kind of thing, as there is no
> "standard" data type or "standard" machine.
>
> The proxy is very lightweight, significantly more so than most
> interactive backends (web applications, php, asp, etc). The best way to
> test is is set up a test system and see for yourself in your environment.
We use modproxy(without cache) for about 30 backend webservers, the whole
traffic is about 10 million hits/month , and we use a pentium 2 / 400MhZ with
750MB ram as reverse proxy, but its 15min load average during working hour is
only about 0.05 , so the cpu is not a bottleneck or modproxy is just very
fast.
regards,
cahya
On Mon, 26 Apr 2004, it was written:
> Can anyone point me to some to some study that compares the
> performance of apache configured as a reverse proxy versus direct
> connection to the remote backend web server?
What's on the backend?
If it's a fast server with static pages, proxying will slow it (but
a cacheing proxy may not). If it's something slow and heavy, proxying
could substantially accelerate it. Once you reach the point where
the hardware has little to spare, proxying can become a useful part
of a scaling strategy.
You could take a look at esi.org for some background about how some
of the biggest companies use proxying to accelerate their systems
and the internet as a whole.
--
Nick Kew
Nick's manifesto: http://www.htmlhelp.com/~nick/
Thanks for all answers, in our case I think CPU load will matter
because the browser's connection will be over SSL.
About mod_cache, it's available only in 2.0 not in 1.3, right?
Thanks,
Gael
At 03:23 PM 4/29/2004, you wrote:
>Thanks for all answers, in our case I think CPU load will matter
>because the browser's connection will be over SSL.
>
>About mod_cache, it's available only in 2.0 not in 1.3, right?
mod_proxy in 1.3 was a caching proxy.
In 2.0, mod_proxy does the proxy, mod_cache does the cache. We've
split the functions into logical units, in fact mod_cache can cache local
content, and mod_proxy is blissfully unaware of caching.
Gael Marziou wrote:
> Thanks for all answers, in our case I think CPU load will matter
> because the browser's connection will be over SSL.
In this case, you should be focusing on the mod_ssl performance rather
than proxy - it will likely be the biggest bottleneck in your app.
Regards,
Graham
--