Hi,
Thanks for your reaction, still you seem to have misunderstood the point I am
trying to make, and I will post it again in the list.
There's different architectures that you can go with.
1. Put all your servers into one box.
Mysql
mod_perl
httpd_docs (static)
squid
the lot.
When it boggs down, upgrade it to the limits of modern technology.... Spend over $
10'000,- on serverhardware... And still get bad results.
People used to do this.....
The some very clever people invented client server architecture. Which is what we
use on the web and on unix too. (Hell even Bill Gates is claiming that he's gonna
do it... So it must be ancient)
Then some even MORE clever people invented 3 tier architecture. Which is what I'm
talking about and can seriously improve results, with much smally costs than the
spend cash on one server and still fail method described above.
3 tier architechture means you split up several processes of your computing
solution between diffent machines.
1st you have the client, who will see the data on its screen and can give
instruction to modify or process the data.
in our case, an internet browser.
2nd you have the application server, which does the actual processing of the data
and sends it back to the client.
in our case, a mod_perl enabled apache server.
3rd you have the database server, which stores and retrieves all the data for the
application server.
Now what you can do is you can try to stuff all this into one box, BUT, the 3 tiers
are actually so different in nature, that they produce better results when run on 3
diffent machines, which are configured for their perticular task!
Like the client only has to catch input from the user and display results on the
screen. You might want some fancy high color graphics card in that, so the output
looks better.
Like the application server, in our case needs to process request for information,
fetch the data, proccess it and server it back to the client. What this needs is
lots of RAM and a good network connection.You don't need a fancy graphics card
because you wont ever work on this machine.
The database server, however needs to store all these huge amounts of data, and be
able to retrieve it quickly. So it also needs a fair amount of RAM (for sorting and
stuff) but most important it is to have a very fast disk in this one. You don't
need a very high speed network connection because you only fetch the data you need,
and do any dataprocessing on the database server. You dont need fancy grafic card
and you don't need as much ram and cpu power as you do for the application server.
What that means:
You can get away with:
Client:
P 90 - 16 MB Ram - HIRES Videocard
Application Server:
P 300 - 256 MB Ram - IDE disk
Database server:
P 300 - 128 MB Ram - UW2 SCSI disk
And still get better results than doing it all on a dual PIII 733 with 1 GB Mem and
a UW2 SCSI RAID array.
Why?
Because the different tiers are *NOT* competing for *RECOURCES*
Tom Brown wrote:
> so you've overloaded the memory (10 meg * 20 daemons = 200 meg on a
> machine with 128 Meg) ...
No, you misread me, it said, taking *UPTO* 10 megs each. Not at least 10 MEGS each.
I had no swapping during this benchmark. I kill of the processes when they get too
large. And YES I overloaded the server, I dont expect that kind of traffic on my
machine within the next year or so, just to prove a point. (That if you get lots of
traffic, you should add onther box and put the database on that, instead of
upgrading the server)
> what happens if you take out the 128 meg from
> your slow box and put it in the fast box? hhhmmm?
Like i said, there was no swapping during the test, I added another 128 Megs of
ram, and got the same results. (I could spawn more childeren but this is not
relevant) RAM is the deciding factor when applying mod_perl apache... Nothing else.
You could dump in 1 GB of Memory, when the database is also in the same machine;
Each and every httpd has to wait for the database's IO to finish. (You know that IO
also uses CPU?) Ofcourse you can add lots of high tech stuff, but the point is that
while to you, it might seem that a server is doing over 20 things at the same time,
it is actually doing them one after the other. (even worse it does a little piece a
one process and then a little piece of the other a.s.o.)
So lets see what happens in a single server secenario...
Apache Server gets hit...
Spawns httpd
Excecutes mod_perl script
mod_perl script query's database server
database processes query -> disk IO
mod_perl script processes data
mod_perl script reads html template -> disk I/O
mod_perl script sends data to client
apache writes log entry -> disk I/O
Now Imagine this happening 20 times simultaniously.
Identify the bottlenecks in this setup. (easy, disk I/O is the slowest factor)
so httpd 1 has just queried the database and httpd 2 is just executing...
It also has to query the database, so it has to wait, for httpd 1 to finish. (not
actually how it works but close enough)
Now httpd 1 has the results from the query and is preparing to read the template
from disk.
httpd 2 is now quering the database... Now httpd 1 has to wait for the httpd 2
query to finish, before it can fetch it's template from disk. a.s.o. a.s.o. This,
unfortunately is (still) how pc's work. There's no such thing as paralel processing
in PC architecture.
This example is highly simplyfied. In practise it is a lot worse than I demonstrate
here, because while waiting for the database query to finish, your application
still gets it's share of resources (CPU) so while the load on the machine is over
1.00 it's actually doing nothing for half the time... :( This is true, take a
university course in information technology if ya want to know...
Now imagine this with 20 httpd processes!
Need I go on? I don't have to prove this, this has been proven a long time ago over
and over again.
If you have very little trafic, and only use Mod_perl apache (or something) to
speed up your applications. Go ahead, put everything in one box.
If your trafic increases, buy another box. You don't need an expensive one. A cheap
one will do. Decide what you want each box to do, and put the right components in
the right boxes....
Yours Sincerely,
Marko van der Puil mailto:[EMAIL PROTECTED]
Renesse Web Services http://www.renesse.com
