We're at about 80,000 local deliveries and 20,000 remote deliveries daily. Our old machine with 1 heavily fragmented RAID 5 would give "connection refused" responses to new smtp connections very regularly during peak hours. Our new disk optimized machine does not give "connection refused" during peak hours any more... BUT it still will sometimes have a ~10 second delay in responding to new incoming smtp request when processing a mailing list of around 500 remote recipients.
Since nothing is logged, the only way we're able to see the response delays and connection refused is by telnetting to the smtp port when the server is really busy. Now that we've made some TCP tweaks, we'll keep an eye out next week to see if the response delays still occur when emails go out to the larger mailing lists. Bill -----Original Message----- From: Len Conrad Sent: Sat, 23 Aug 2003 21:52:01 +0200 Subject: Re: [IMail Forum] Connection refused errors >http://www.macromedia.com/support/coldfusion/ts/documents/tn17277.htm > >Does anybody know any details about these parameters and if they'd be good >to adjust on an Imail server? > >MaxUserPort, TcpWindowSize, MaxFreeTcbs, MaxHashTableSize, TcpTimedWaitDelay Since I don't remember Win TCP stack tuning discussed much here before, I'd like to hear from the high-volume admins (not their waistlines, their numbers of messages/day), like Ikano, etc. about whether they have tuned TCP and if they ever have IMail connection refused. I know I've seen this problem MANY times with my IMGate clients and it's been real bitch for them to figure out how fix it, usually by throwing $$$ at a new machine, trying to outrun it. If we can come up with a set of "pedal to the metal" Win32 TCP params, it would be of great use all around. Although MS charges you big $$$ for Win Server, you can't count on them out of the box to deliver it with "server TCP params". btw, I'm sure LOTS of Imail boxes are "connection refusing" but since without any external tool to watch it (as IMGate does) people don't know it's happening. And Imail doesn't log such an event, either. Flying at night and without instruments. Watch out for those mountains (of spam). With the TCP stack no longer gagging prematurely, IMail admins can concentrate on the "real" limit, which is disk performance. Len _____________________________________________________________________ http://MenAndMice.com/DNS-training: London; San Jose; Wash DC IMGate.MEIway.com: anti-spam gateway, effective on 1000's of sites, free 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/
