-----------------------------
Please read the FAQ!
<http://java.apache.org/faq/>
-----------------------------
Tim Reilly wrote:
> 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?
Okay, just my 2 cents:
It sounds like memory and concurrent database access will be major, if
not your biggest problems. There are several approaches to dealing with
the memory demands - which I'm sure other people will elaborate on (my
ideas are nothing new there) - but in terms of concurrent database access,
I recommend that you write some sort of lightweight database connection
management toolkit and make sure it can scale to the high # of concurrent
connections you'll need. I have no idea if mySQL can handle that kind
of need. Oracle, Informix, etc. definitely support high #s of concurrent
connections, but EVEN THEN you still need to write some sort of pooling
software so that you don't exceed max connections.
I think that if you implement some of your application classes as
distributed objects, you can give yourself flexibility for the future
and use it as a way of improving the scalability of your system so that
the memory/processor demands are not eaten up by one big java processs.
That's pretty unwieldy. Then, again, using distributed objects means
you have to pay for marshalling, etc. But, I think if you implement
your caches right, you can avoid excessive marshalling and still
distribute the work.
::: Greg Barish ([EMAIL PROTECTED]) :::::::::::::::::::::::::::::::::::::::::
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
