perl-embperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Gunton <>
Subject Re: Tuning Embperl
Date Mon, 23 Feb 2004 22:48:51 GMT
Stefan Cars wrote:

> Hi everyone and Gerald!
> Anyone that has any tips on performance tuning Embperl to make stuff go
> faster? Besides loading modules and making sure that we have enough forked
> processes so we don't have to start them later.

If you are talking about just Embperl, then I would say that preloading
modules and Embperl pages is about all you can do in terms of "pure"
Embperl tuning (as far as I am aware). This will maximize your shared
memory, which will in turn reduce the amount of virtual memory paging if
you have a lot of Apache processes.

However, there are other factors, such as the efficiency of the
algorithms you use, and the load on any databases you might be using.

I have found that introducing a lightweight caching reverse proxy
front-end Apache server produces orders of magnitude speed increases, if
configured correctly. This allows the generated pages to be cached by
the proxy. When I benchmarked my application using this setup, I went
from being able to serve about 40 pages per second to over 1000. This is
because once it's generated, the Embperl page is stored by the reverse
proxy, thus making it effectively as fast as serving static text for
subsequent requests to that page (at least, until the page expires from
the cache and has to be regenerated).

This can be a lifesaver if you have a site that needs to be both dynamic
AND fast - for example, my own site recently survived a slashdotting
quite comfortably because of the reverse proxy. The first time this
happened, I didn't have the proxy and the server was in trouble because
each and every request was being served by the "heavy" mod_perl Apache

You do need to be careful with a reverse proxy with regard to page
expiry times, since if you have "personalized" pages that expect to be
customized for each request, that would mean you can't cache these. But
I developed some techniques for which involve
basically adding an "mtime" to the links within the site. This is the
"modification time" for the page, and is used solely to make the URL
look different to the reverse proxy when the page changes. This makes
the proxy request the page anew from the back end. It was quite
involved, and I had to re-design the website to cater to this setup, but
in the end it was worth it because I can now tune pages to have
different expiry times depending on how "dynamic" they are. For example,
the Help pages are quite static and so can have expiry of a day or more,
whereas forms for editing journals are very dynamic and have "no cache"
set. The "What's New" page has an expiry of 1 minute, so that it is
always relatively fresh.

I'll probably write up my experiences implementing all this at some
point, but in the meantime the mod_perl docs has a good intro to setting
up a reverse proxy:

Hope this helps some,


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message