First, as I said, make sure you have enough RAM. On a Windows machine, 1gb is not unreasonable. On Unix, 256 meg is good for Sparc, 512 is much, much better, especially for Intel. You'll probably see performance increases on the Intel platform up through 1GB if your mother board/bios handles it properly. 512 on a Sparc was almost unheard of a few years ago <G>... but if you think life was good with 128 meg..... :)
Then, as Alex said, move to mod_perl first. (or speedy cgi). That will give a performance increase with the currently available resources.
The caveat is, that apache_mod_perl is _BIG_ its an easy 3-4x as big as apache without mod_perl. That means, you need more RAM, or you start to lose your benefits in using disc cache memory. Figure at least 4 meg of ~RAM in Unix for Apache/mod_perl per process. 25 processes is 100 meg of RAM, otherwise you are swapping. Add a 16 meg MySQL proces and the Unix kernal, and 128 meg of ram starts to look pretty small. Of course, it _will_ work. It will work pretty well. It will just work better with more RAM.
Once you do that, you need to see where your real bottlenecks are. You might need some system management tools or even an analyst to look at your traffic. What you need to do at that point "load balance" between two or more servers, such that each server is doing a fair share of work, without duplicating stuff. For instance, putting the database on one machine, and optimizing that for database serving, having a separate network connection to that machine, and using the front end machine for web serving might be good. Then, again, maybe running fat and thin apache versions (with and without mod_perl) may be better -- depending on what your site is doing.
There is no one answer, and load-balancing and networking is an art, more than a science.
But, first check your RAM and CPU, then move to mod_perl.
The point I'm making is make sure your hardware is up to the job, before you start to try to squeeze every drop of performance out of it. Sometimes, that is a losing battle. After that you'll need to figure out what is taking the most resources, and how best to break up the workload.
PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://pugdog.com/FAQ
Then, as Alex said, move to mod_perl first. (or speedy cgi). That will give a performance increase with the currently available resources.
The caveat is, that apache_mod_perl is _BIG_ its an easy 3-4x as big as apache without mod_perl. That means, you need more RAM, or you start to lose your benefits in using disc cache memory. Figure at least 4 meg of ~RAM in Unix for Apache/mod_perl per process. 25 processes is 100 meg of RAM, otherwise you are swapping. Add a 16 meg MySQL proces and the Unix kernal, and 128 meg of ram starts to look pretty small. Of course, it _will_ work. It will work pretty well. It will just work better with more RAM.
Once you do that, you need to see where your real bottlenecks are. You might need some system management tools or even an analyst to look at your traffic. What you need to do at that point "load balance" between two or more servers, such that each server is doing a fair share of work, without duplicating stuff. For instance, putting the database on one machine, and optimizing that for database serving, having a separate network connection to that machine, and using the front end machine for web serving might be good. Then, again, maybe running fat and thin apache versions (with and without mod_perl) may be better -- depending on what your site is doing.
There is no one answer, and load-balancing and networking is an art, more than a science.
But, first check your RAM and CPU, then move to mod_perl.
The point I'm making is make sure your hardware is up to the job, before you start to try to squeeze every drop of performance out of it. Sometimes, that is a losing battle. After that you'll need to figure out what is taking the most resources, and how best to break up the workload.
PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://pugdog.com/FAQ
