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
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