Multithreading appears to be most useful at the login & prep stages, but not
as necessary during data transfer, which is fairly contiguous.
This appears to apply to POP3 and SMTP somewhat, but more so to FTP.
If a server getting remote email acts anything like a client, my modem
lights tell me that there are fair time-gaps in the bandwidth (waiting) that
can be filled by another thread. This would optimize throughput and
maximize network pipe usage.
This is precisely the reason why I use 2-3 threads for FTP when I have to
get/put a lot of files. FTP and HTTP have many timeouts and wait-for
operations in the protocol during the get-ready and login process for each
file. (However, some FTP servers only allow 1 concurrent login).
4 threads and network pipe is overloaded --> TCP/IP has a lot of collisions
to handle --> you are over the performance plateau.
I find the same thing with 10Mbps networks. Gigabit may be only limited by
the speed of your box, given the current speed of today's machines. It
depends on a machine's network throughput compared with the speed of the
network pipe I would think.
Any corrections welcome.
Jim Michaels ([EMAIL PROTECTED])
----- Original Message -----
From: "Serge Knystautas" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, June 29, 2001 8:55 AM
Subject: James's throughput and bug
> This is somewhat amusing (in a self-deprecating way), and I thought would
be
> interesting to the list as well.
>
> I had about 800 emails queued in a mail repository (in a database) that
were
> for a former employee. I finally got his new address this morning, and so
> stuck those 800 emails back in the "incoming" repository with his old
> address now aliased to his new address.
>
> Normally I leave spoolmanagerthreads configured at 1 (I had forgotten
why).
> To speed delivery, I had the bright idea to change it to 5 threads.
(note,
> I have it configured for 8 delivery threads, and I believe that is
actually
> per spool manager, given the way it works, so 40 delivery threads).
>
> The bug (and funny part) is that James delivered 1 copy of each message
PER
> SPOOL MANAGER THREAD. So instead of 800 emails, it sent 4000.
>
> The good news, and throughput report is that James, using a database on
> another machine, delivering to a remote server across the Internet, and
> rarely going over 30% CPU usage (on a PIII 400), sent these 4,000 emails
in
> 13 minutes. Regular incoming/outgoing messages were still flowing, and a
> few pop3 connections were open.
>
> This was with the 1.2rc1 release, so it was parsing and instantiating the
> message half a dozen times during processing, and was using Town still
which
> also isn't efficient. I expect to have significantly higher throughput
with
> the new release, but just wanted to share some positive results on James'
> throughput in a real world setting.
>
> Serge Knystautas
> Loki Technologies
> http://www.lokitech.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
