Answers in-line...
----- Original Message -----
From: "Max Paperno" <[EMAIL PROTECTED]>
To: "inFusion Support List" <[EMAIL PROTECTED]>
Sent: Sunday, November 25, 2001 10:10 PM
Subject: [iMS] iMS + load balancing
> Hi,
>
> So we're considering an iMS load-balanced/redundant setup. Mostly because we have
>some high-volume mailing lists hosted (lots of
POST activity), but also because e-mail is the most relied-upon service we offer. I
wanted to run a couple of my theories past you
all, especially Howie :) Please jump in if any of this sounds off-base. I could have
sworn I read about this somewhere before
(specifically re: iMS) but can't find it now.
>
> 1) The actual load-balancing system is somewhat irrelevant to iMS (hardware vs.
>software vs. round-robin DNS). In general terms
I'm talking about 2 "front-end" machines that are linked to a common file server.
>
> 2) Seems to me that the POST queue needs to be machine-specific (one queue per iMS
>instance). Otherwise 2 POST processes might
try to send the same mail (?). Also having the queue on a local disk should speed up
processing due to the many .mail file
interactions going on. However, it'd be cool safety-wise to have a shared queue (for
example one server dies... mail gets stuck in
its queue). Any way to do this?
>
iMS POST Servers cannot currently share a queue. There are enhancements in the works
for the next major release but that will not
be for some time.
> 3) The local mail repository has to be on a shared disk so that either POP server
>can get to it. I would think that having 2 POP
servers shouldn't make any difference in terms of file access/locking, since 1 POP
server can have multiple sessions anyway
(including from the same client). Having the mail repository on a network disk
shouldn't affect performance much though it will
certainly increase network load a bit.
>
Yes, true. I would definitely have at least a 100 Meg Switch (not a hub) in the
network.
> 4) For performance considerations, the SMTP server should use a local drive to spool
>the mail files to as they come in, then the
DATA template can take care of re-writing the file to the shared disk (mine does the
re-writing already). This is probably a minor
point since copying the file will be part of the delivery process anyway. I would
think the real savings come in only when the mail
file doesn't need to be copied over (fwd. acct, bad mail, rcv. timeout, whatever).
>
Yes, true.
> 5) Template directory should be local to iMS machine to increase performance/reduce
>network traffic (although with CF caching the
templates (non-trusted cache) this is probably only a minor savings).
>
True.
> 6) Dedicated Log and Counter folders for each iMS instance would be required. Any
>way to merge counter files?
>
You would need a program to read the files and combine them. There will be
enhancements for the next major release of iMS that will
make statistical analysis much better.
> 7) Get another iMS license!
>
:-)
> Anything else I need to consider (I'm already familiar with load-balancing in
>general, having done it with our Web/application
servers)? How about other ideas to improve reliability/throughput of a mail system?
Any input or resource pointers are
appreciated.
>
If I think of anything then I'll let you know. You seem to have all the bases pretty
much covered...
Regards,
Howie
> TIA,
> -Max
>
==^=======================================================
This list server is Powered by iMS
"The Swiss Army Knife of Mail Servers"
--------------------------------------
To leave this list please complete the form at
http://www.coolfusion.com/iMSSupport.cfm
Need an iMS Developer license? Sign up for a free license here:
http://www.coolfusion.com/iMSDevelopers.cfm
List archives: http://www.mail-archive.com/infusion-email%40eoscape.com/
Note: You are subscribed as [email protected]
==^=======================================================
