Brown trousers time :~

[Lyle - CosmicPerl.com]

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.
>
> http://perl.apache.org/docs/tutorials/index.html
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 :~


Lyle