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 processes. 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 crazyguyonabike.com 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: http://perl.apache.org/docs/1.0/guide/strategy.html http://perl.apache.org/docs/1.0/guide/scenario.html Hope this helps some, -Neil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
