Brown trousers time :~
Lyle - CosmicPerl.com
perl at cosmicperl.com
Mon Oct 8 21:06:15 BST 2007
Dirk Koopman wrote:
> You need to understand, intimately, how to speed up webserving perl
> (or other scripting languages du jour). Personally: I would avoid
> using mod_perl (or even apache) like the plague (except, possibly, as
> front end cache machines). I much prefer any of the small
> threaded/select based webservers (eg lighttpd, litespeed, thttpd etc)
> with a FastCGI back end.
I'll look into this...
> The mod_perl site does have a number of extremely important articles
> about how to go about planning something like this. Don't do
> *anything* until you have read and *understood* what is there.
Thanks for the link :)
> One of things that you really, really should try to achieve is to make
> as much static as possible. Even if that means using (and reusing)
> acres of disc space - just for html cache. Most so called "dynamic"
> sites aren't at all. Take a shopping site, the only things that change
> on a product page are the price (and possibly things like stock
> levels). But these don't change that often. You can generate the page,
> on demand, and then cache it, you have a system that invalidates the
> page when something on it changes. It is rather web 1.0 but it works
> and is as quick as you can serve that html page.
Good point. I remember updating my first directory software to be as
static as possible, the benefits were overwhelming...
> Windows? Do you really want to do this in perl? (sorry to be
> controversial). You would be much better off taking the M$ 10 cents
> and doing it whatever is the "M$ way" this week.
Trying to make a single piece of software that's os independent (mostly).
> Realtime+many requests/sec = Big Bucks for Big Iron. Avoid, you almost
> certainly don't need Real realtime.
> Prepare yourself for a sore head, once with the learning and again
> with the banging on the office wall.
I can feel it already :~
More information about the london.pm