Let's assume that you have two different sets of scripts/code which
have a little or nothing in common at all (different modules, no base
code sharing), the basic mod_perl process before the code have been
loaded of three Mbytes and each code base adds ten Mbytes when
loaded. Which makes each process 23Mb in size when all the code gets
loaded.
Assuming that we have 230 Mb of RAM available to the mod_perl server,
the memory limitation allows us to run ten mod_perl servers
(23Mb*10=230Mb).
Now consider this practical decision. Since we have recognized that
the code sets are very distinct in nature and there is no significant
memory sharing in place, the wise thing to do is to split the two code
sets between two mod_perl servers (a single mod_perl server actually
is a set of the parent process and a number of the child
processes). So instead of running everything on one server, now we
move the second code set onto another mod_perl server. At this point
we are talking about a single machine.
Let's look at the figures again. After the split we will have five
servers of 13Mb and another five servers of 13Mb. A total of 130Mb
memory required. But, hey, we have 230Mb of memory. We've got 100Mb
memory freed up. So we can run about eight more servers using the same
memory size. We have almost doubled the number of servers without
changing machine's hardware (13Mb*18=234Mb).
Moreover this new setup allows us to fine tune the two code sets,
since in reality the smaller in size code base might have a higher
hit rate, so we can benefit even more.
Let's assume that based on the usage statistics we know that the first
code set deployed in 70% of requests and the other 30% are used by the
second set. Now we assume that the first code set requires only
6Mbytes of RAM over the basic mod_perl server size, and the second set
needs 14Mbytes (we try to make the comparisons against the same
original setup where there were ten processes of 23Mbytes in size
each).
So now the first mod_perl server running the first code set will have
all its processes of 9Mbytes in size (3Mb+6Mb), and the second of 17Mb
(3Mb+14Mb). Given that we have a 70:30 hits relation and that we have
230Mbytes of available memory, we have to solve this equation:
0.7*X * 9 + 0.3*X * 17 = 230
where X is the total number of the processes that can be run using the
230Mbytes of available memory, and 0.7 and 0.3 reflect the 70:30 hits
relation, 9 and 17 are the respective sizes of the two servers and
with their code sets in use.
When we solve this simple equation, we get that X equals 20 and
therefore, we need 14 processes for the first code set and 6 processes
for the second.
If we compare this findings with the initial setup we have doubled the
number of the servers from 10 to 20.
The hits rate optimized solution allowed us to run two more servers in
total and gave us five more servers (14 versus 9) for the most wanted code
base, relative to the simple 50:50 split as in the first example.
Of course if you can identify more than two distinct sets of code and
your hits rate statistics may require more complicated decisions. You
ought to make even more splits and run three and more mod_perl
servers.
Remember that having too many running processes doesn't necessarily
means a better performance because of all of them will fight over CPU
time slices. The more processes are running the less CPU time each
gets the slower the overall performance will be. Therefore after
hitting a certain load you might want to start spreading servers over
different machine.
______________________________________________________________________
Stas Bekman | JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ | mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] | http://perl.org http://stason.org/TULARC/
http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org
----------------------------------------------------------------------
