Hi! Those things I have done although my Apache crashes when having Embperl::Execute() in my startup file ? Any ideas why this could happen ?
Becuase of testing I've commented out anything else really in that file but still I get the crash (Segmentation fault). / Stefan On Mon, 23 Feb 2004, Neil Gunton wrote: > 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] > -- Stefan Cars Snowfall Communications Tel: +46 (0)18 430 80 50 - Direct: +46 (0)18 430 80 51 Mobile: +46 (0)708 44 36 00 - Fax: +46 (0)708 44 36 04 ______________________________________________________________________ SNOWFALL DISCLAIMER: The information contained in this email and in any attachments is confidential and may be privileged. If you are not the intended recipient, please destroy this message and notify the sender immediately. You should not retain, copy or use this email for any purpose, nor disclose all or any part of its content to any other person. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Snowfall Communications. Snowfall Communications monitors the content of emails sent and received via its network for unauthorised use and for other lawful business purposes. The contents of an attachment to this email may contain viruses which could damage your computer system. While Snowfall Communications has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening the attachment. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
