[imp] Permformance issue
tomc@teamics.com
tomc@teamics.com
Tue, 16 Jul 2002 10:04:55 -0500
My 2c:
We did the math and decided that the front end web server needed to sustain
100http connects per second, 15 SMTP connects/sec, and memory to sustain
1500 sessions at a time. The IMAP server needed bulk storage of 140GB with
a 'sustained' (NOT PEAK - peak is a sales scam - sustained is all that
matters) sustained throughput of 18MBytes/sec continuous IO. Using a 2MB
attachment limit with virus scanning, we calculated the IMAP server should
have 2GB working RAM.
No web server or SQL server should be uniprocessor in a production setting.
Clock speed means nothing. The key speed determinant for complex web apps
(not static content) is, "how wide is your channel to memory?" . So we
went with IBM because of the (yes, I know it's IBM) proprietary memory
hardware architecture which really cranked up the number of sustainable
concurrent connections.
The IMAP server calculations showed us that our key challenge was
sustaining the fairly high IO levels over the long haul.
We finally decided it was more cost effective to go with two machines, one
which was a serious IO monster, the other which was a dual xeon with 4gb
ram and etherchannel capable network cards. Place a private 100baseT
between the two machines, and good to go. Backups run on the IMAP server.
We also liked the split configuration because the performance/capacity
calculations indicate that should we double the number of clients, we only
need to add another web front end, because the incremental load on the imap
server does not increase as rapidly as the http in relation to the number
of active accounts.
We watch the performance and latency on the link between the two machines,
because that could present latency problems for imap.
Certainly your mileage will vary, and there are probably hundreds of other
'correct' answers given the same inputs.
tc
Eric Rostetter
<eric.rostetter@physics.u To: Andrew Morgan <morgan@orst.edu>
texas.edu> cc: Terry Poperszky <Terry.Poperszky@SosStaffing.com>,
Sent by: imp@lists.horde.org
imp-bounces@lists.horde.o Subject: RE: [imp] Permformance issue
rg
07/15/02 09:09 PM
Quoting Andrew Morgan <morgan@orst.edu>:
> My personal opinion is that you are better off installing IMP on a
> separate machine. No matter where you install IMP, it will make an IMAP
> or POP connection to your mail server. In one case this happens locally
> by connecting to localhost and in the other case it happens across the
> network.
That doesn't mean that localhost vs network access perform equally, or have
the
same security.
> If for some reason you have a really slow network between the two
> machines, then running it locally would make sense. Otherwise, I'd
rather
> have the extra horsepower of a second machine.
Unless you already have too much horsepower already, and/or cost is a
concern.
> IMP, especially using SSL
> connections, does take some horsepower to run, so why not take that load
> off of your mail server. Let your mail server just handle IMAP/POP
> connections.
To be secure, you would then need ssl for the imap/pop connection, so
basically
you've doubled the amount of encryption on your web server now (https and
simap/spop3) and haven't decreased the amount of encryption on the mail
server (roughly, not an exact science here).
> Where possible, I prefer to dedicate servers to separate services rather
> than running it all on one big machine.
I can't disagree with that from a management point of view. But that is
not the same issue as performance.
For example, when I split my IMP installation from one machine to two,
management became 100% better, but performance died (average request now
takes about twice as long as before). But we did the split for management
reasons, and we're willing to eat the performance loss.
The performance hit we saw is completely explainable and we knew it would
happen. But we desired it none-the-less. Other setups would of course
be different, and hence the outcome different.
> Hope this helps,
> Andy
--
Eric Rostetter
The Department of Physics
The University of Texas at Austin
"TAD (Technology Attachment Disorder) is an unshakable, impractical
devotion
to a brand, platform, product line, or programming language. It's
relatively
harmless among the rank and file, but when management is afflicted the
damage
can be measured in dollars. It's also contagious -- someone with sufficient
political clout can infect an entire organization."
--"Enterprise Strategies" columnist Tom Yager.
--
IMP mailing list
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: imp-unsubscribe@lists.horde.org