welcome back Gerald

[hero fish <al...@netherrealm.net>]

Hi Gerald,

Just a quick note to say that I am also very glad to see you back, not only
for my personal reasons (I use Embperl for my band's website) but also
because it's a great piece of software and it would be a big shame if it got
stuck in the past.

-Allen

On Fri, Sep 18, 2009 at 09:10:59AM -0700, Neil Gunton wrote:
> Chris Denman wrote:
> >I made a utility for Twitter that went viral for a week - my server
> >took 30,000 hits in a few hours.  Of course, it crashed.  I went away
> >and tried everything to get it working under this sort of load.  Thing
> >is, the traffic slowed and I'll never know if my new setup with hold
> >up.  Can I expect, say, 200 concurrent users on a Embperl website with
> >only 1Mb of Ram?  If so, what's the best Apache configuration?
> 
> Does every single request need to be handled by Embperl, or could you 
> perhaps cache some of the pages? I use a two level caching reverse proxy 
> Apache configuration on my server. There are basically two installations 
> of Apache - one with mod_proxy, which serves all static content (images 
> mostly). It passes all requests for dynamic content to the "backend" 
> Apache process (running on the same server) which has mod_perl and 
> embperl. The front end apache can be very lightweight, as it doesn't 
> have mod_perl etc it doesn't use much memory, and so you can have a 
> whole bunch of them running. And if you use mod_cache, then you can also 
> cache the results that come from the backend embperl server. So that 
> means that if you're careful about setting expiration times for your 
> embperl content, then you can substantially lighten the load, and still 
> be able to handle a whole bunch of concurrent users without breaking a 
> sweat.
> 
> You usually find that not every single "dynamic" page actually has to be 
> generated anew for every single request. For example, on my community 
> website, there are pages which are "what's new" indexes of content. 
> These are set to have a cache expiry of one minute. So if a whole bunch 
> of people hit that page, most of those requests will be served by the 
> front end, until that version expires (next minute). So the backend is 
> only hit for that page once per minute. It gets a bit more complicated 
> if you have users with cookies, but basically I only set 'no-cache' for 
> those parts of the site that are definitely needing Embperl per-request 
> (e.g. editing forms, user-specific areas etc).
> 
> Caching is how you handle scaling - most websites go down because they 
> handle everything with the dynamic engine, and then one day they get hit 
> by a bunch of people and "bang". Early on I had a couple of my articles 
> go to the front page of slashdot. As soon as I put in the caching 
> architecture, my server was able to handle slashdottings without 
> breaking a sweat. I'd get upward of 40,000 hits within a few hours, and 
> the server was just basically idling along, since most of the hits were 
> effectively being served as static content from cache - even though the 
> article was dynamically generated by embperl.
> 
> >Can't wait for any new versions....!
> 
> Me too - I'm so glad to see Gerald back on the list. I have based my 
> entire website development around Embperl (hundreds of thousands of 
> lines of code now, and going on for ten years of development). I was 
> afraid that Embperl was abandonware, since I'd seen the embperl list 
> traffic dwindle and questions go unanswered. I really hope to see 
> embperl rekindled. If/when my business takes off (of course it will, any 
> day now!) then I hope to be able to send some appreciation Gerald's way.
> 
> Neil
> http://www.neilgunton.com/
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org
> 

-- 

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org