[lug] Specing out a server

[Zan Lynx]

On Tue, 2006-07-18 at 12:32 -0400, Gordon Golding wrote:
> I'm specing out a project.  Trying to guess size/expense of hardware
> for 3 different user base sizes 100, 1000, 5000.
> 
> Web-based application
> 100 Gig text database
> Natural Language processing provides interactive text-based sessions
> to help users comprehend the text
> 
> I'm currently using Apache/Tomcat, C and Java with Postgres.
> 
> I'm currently buying Dells, typical machine:
> Pentium 4 Prescott DT, 3.0GHZ, 1 MEGB, 800FSB
> 1 Gig memory
> 1 U4001 HARD DRIVE, 160GB, Serial ATA, 8MB, 7.2K, WD-XL80 
> 
> For 100 Users - this is definitely big enough.
> 
> But what about 1000 or 5000 concurrent users?
> 
> What have people been dealing with for actual concurrent sessions
> involving some processing and database access?
> 
> What are we looking at hardware-wise?

Just generally, for servers I find it is RAM and Disks that make the
difference.  4 GB of RAM, and SCSI RAID with cache RAM and cache battery
backup.  That's the ticket for databases, the battery backup lets the
disk do a committed-to-disk write (fsync, in Unix terms) with instant
return to the OS.

What I think you need to do is come up with stats for an Average User,
and Expected Response Time.

Once you have that, you can simulate various user loads through a
combination of simultaneous sessions and shorter access intervals.

For example, if your Average User makes one request every 5 seconds, you
can simulate 5 users by simply making one request every second.  Then to
get to 500 users, run 100 sessions, each making one request every
second.  How many sessions you can simulate per client computer is
tricky to figure out but watching CPU and network load per system can
give you a good idea.

So once you get a performance test figured out, you can easily decide
how many users any given server can support, AND you can see what
bottlenecks your server is experiencing.

For instance, if vmstat shows a lot of time spent waiting on disk I/O,
that indicates first: more RAM, and second: faster disks.  If CPU load
is high, faster CPUs or more of them.  If the network is saturated, add
more interfaces, or faster interfaces, or upgrade your network switches
to a faster type.
-- 
Zan Lynx <zlynx at acm.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20060718/b02aa65a/attachment.pgp>