Tim,
> 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).
> 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.
Looking at these numbers, and your plans for growth, something doesn't
quite seem right. For one, "caching the objects indefinitely" doesn't
seem to make sense. Why have a database backend if you are using the
frontend application for storing data? There should a timestamp on
all caching, so you are using cache to speed up the process of serving
pages, and the database for storage of user related data.
If you are planning to grow from 10,000 hits and 10,000 records
to 1000,000 records and 1000,000 queries, this would indicate your
system's resource requirements will grow 100 (to 10,000) fold.
What you need is a load balancing system to spread out the tasks
between more than just two machines. I.e. redesign the system to
allow for growth by adding more machines, versus more processing
power (not that there wouldn't be need for that too.)
This will allow you to start with two machines, while providing
for space to grow by simply adding more machines to serve user
requests.
Cheers,
Troy
>
> 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]
>
>
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]