The company I work for is in the late stages of re-architecting our entire
website using Apache JServ, RedHat Linux 6.0, and MySQL. The code is just
about finished (version 1.0 freezes in the two weeks), and we're trying to
spec the servers we will need for deployment. The problem is that I
really have no idea what class of machine is required.
We are definitely going with a two system architecture. One machine will
have Apache + JServ, and the second will be a dedicated MySQL back-end
machine.
Initially every request to our website will have to hit against the
database to instantiate several objects in order to assemble all data
needed to render a page. However, as these objects are instantiated, we
are caching them in JServ to avoid future database calls. There will
still be a moderate amount of database activity, probably 2 calls every
time someone access a page on our site (vs. ~10 for the initial load of
all required objects).
At present we have about 15,000 hits/day on a different system, but it is
just about at max capacity. The system load is expected to ramp up
dramatically once this new architecture goes into production and gives us
room to grow. We are hoping to be serving out close to a million hits/day
in the next 6-9 months.
Realizing this is a completely abstract term, I would characterize our
database at present as pretty small (~10,000 rows), but as mentioned it is
expected to grow hopefully to several hundred thousand rows by the time we
are serving out a million hits/day.
At the moment, the java process itself eats about 50 megs minimum and
peaks around 64 megs. Since we are caching our objects indefinitely, we
fully expect this to grow at a constant rate with the size of our
database.
Can anyone estimate what kind of horsepower our servers will need to
handle the kind of load I've described?
We are definitely getting a minimum of 512 Megs of RAM on each box, but is
there a need for dual-processors, RAID, etc.? Actually, does anyone know
whether java on linux will utilize dual processors? Is there anything
else we should consider that isn't immediately obvious?
Thanks,
-Tim
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
