The Disk I/O may be a sore point. I asked them and got an answer that there
was just a single IDE drive. Ouch. But I am new guy here so I don't want to
piss everyone off the first week on the job. I will make sure to
diplomatically bring the point across though.
Thank you for the comments.
Andrey
-----Original Message-----
From: Sanford Whiteman [mailto:[EMAIL PROTECTED]
Sent: Friday, January 30, 2004 3:19 PM
To: Fyodorov, Andrey FTL
Subject: Re: [IMail Forum] industry grade front-end SMTP solutions
> Hey all. What do you guys see out there that most companies use to
> process SMTP traffic at the front-end?
Never mind what "most" companies use. What's important is which
deloyments, worldwide, are actually up to their respective tasks--i.e. are
not continually disappointing their end users at one level or another.
For example, you're using Solaris, a secure OS very popular with, for
example, huge financial enterprises. Exim is highly configurable--then
again, so are most *nix-based MTAs compared to Windows-based MTAs--and also
has the customary advocacy from the Slashdot set. Yet your servers
are choking, likely because they are not rightsized for their load. You
mention CPUs and memory, but not disk I/O; I hope the "pretty bright"
guys did not similarly ignore the importance of DASD and cache (CPU and
RAM are important on boxes also doing content scanning, but disk is
_always_ important). Just goes to show you--the architect makes the system,
not the other way 'round.
> Is it mostly UNIX-based solutions or Linux-based?
There are many more messages received at *nix-based MXs worldwide than at
Windows-based MXs. But that doesn't mean that just throwing a new OS and
MTA on the same box solves anything--witness your current issues.
Chances are, you should move for PostFix or qmail on fresh or improved
hardware, since your admins will likely gravitate toward a *nix in any
case.
> Are Windows-based solutions popular too?
Again, "popular" is a difficult word. My feeling is that many, many
more MS deployments at the MX are _accidental_ than *nix MX
deployments--in the sense that what drives the deployment is an issue far
removed from MX performance, such as "We need Exchange for collabo and our
admin/architect didn't realize that it's a database server on top of an
MTA" or "Our <name of Windows-based mailbox suite> has essential hosting
functions built-in and with easy config, and I don't know how much of my
vital resources are being sucked up by loss-leader webmail, causing the
box to delay or drop SMTP transmissions, so I fiddle with other stuff" or
"We're a small Windows shop experiencing mailbox server slowdowns, so so we
turned on MS SMTP on our web server and made that our MX." Etc, etc.
So, if that made any sense, my point is that the number of Windows MX
deployments sized deliberately for the MX function is a small fraction of
the overall Windows MX deployments. The "popularity" of Windows at the MX
could thus be said to be very, very low. But in the right hands and on the
right hardware, even if if PostFix and qmail code is tighter, MS SMTP
and other Windows-based MTAs can really cruise. But this is probably not
worth bringing up to Solaris folks, since they tend to be in a partsan
league of their own (IME, arguing with those that defend Sun as if
they're not demonstrably as predatory as you-know-who is more painful
and head-spinning than arguing with open-source fanatics).
--Sandy
------------------------------------
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.
e-mail: [EMAIL PROTECTED]
SpamAssassin plugs into Declude!
http://www.mailmage.com/download/software/freeutils/SPAMC32/Release/
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
