Yes, in fact, the actual processing of the message was virtually
instantaneous... there was rarely more than 3 or 4 messages not yet
processed despite the fact that we were sending in over 100 messages per
second. I love raid :)
Right now, we've been doing tests sending out to servers inside the
office. We've been experimenting with 20kb messages (as the real world
messages will be close to that size), sending them to Microsoft SMTP
servers (which do no processing). We wrote a mail eater that will monitor
the ms smtp server's queue and eat everything in it, keeping track of how
fast mail is coming in. For a good idea of how impressive this all really
is... one workstation running ms smtp was receiving from qmail at ~8
messages per second. Not too impressive. So, we added 4 more servers
receiving and then send equal messages to all of them. They recieved at 8
per second too. The catch? Concurrencyremote was set to the default 20.
Once we finished that test, I increaeed it to 255. Then, each server
started receiving ~30 messages per second. That mean qmail is sending 150
messages per second. Memory usage is pretty high (255 qmails after all)
but processor usage is almot negligible (with logging OFF). These results
are very entertaining because we couldn't even fill the queue that fast :)
(we're currently filling the queue with qmail-send off as it seems to be
faster that way). We currently believe that our bottleneck is disk access,
so we're going to increase the writeback cache on the raid controller to
256mb. We're also going to put in 4 network cards as I mentioned before,
each with its own qmail. Once this is complete, we're going to take all
the computers in our part of the building and set them to eat mail. We
believe we can acheive maximum utilization out of the network, without
pushing our raid or memory/cpu. This should allow us to send an incredible
500 messages per second on a machine that costs about 10% of the NT server
that couldn't send faster than 30 messages on a lan (and 5 messages
externally). I'll report back more when we try this benchmark. I expect
we'll have incredible results.
Cris Daniluk
MicroStrategy
(ps excuse all my missing s's, its sticking on my laptop and you can only
fix it so many times! :)
On Fri, 6 Aug 1999, Mark Delany wrote:
> At 03:38 PM Friday 8/6/99, Jim Arnott wrote:
>
> >Wow, thats very impressive throughput.
> >-jim
>
>
> I just hope that the queue was actually processed at that rate. Sure you can
> invoke qmail-inject and have all the messages in todo, but they really need
> to be processed by qmail-send before you can say the queue injection is
> complete.
>
> Cris? Did you actually check the output of qmail-qstat at the end of that
> test to ensure that
>
> "messages in queue but not yet preprocessed" was zero?
>
>
> Mark.
>
>
>
> > >
> > > Well, we're starting into our testing of qmail so that we can transition
> > > away from the garbage-polluted ms smtp server that we had such a long
> > thread
> > > about earlier this week.
> > >
> > > Basically, we constructed a temporary system for benchmarking. It is a dual
> > > p2 400 with a dpt smartraid5 controller and 64mb cache. We put in 2 9.1gb
> > > cheetahs on a raid 0 stripe. The system has 160mb ram.
> > >
> > > The first benchmark we ran was to see how fast we could populate the queue.
> > > I made a script to sequentially fill the queue with 20kb messages. It was
> > > able to do 2000 20kb messages in approximately 16 seconds (precision was
> > > only to the second, so 15.1-16.9 are valid ranges). 125 messages per second
> > > is more than adequate for our needs. I was very impressed by the fact that
> > > qmail could populate the queue so quickly. I think that definitely goes to
> > > show the scalability of qmail.
> > >
> > > The next test we're going to do is to use it as a mail relay, relaying from
> > > the message generator machines out to the net. For the short term, we are
> > > going to run 4 separate qmails with 4 separate queues. Each instance
> > will be
> > > on a separate ip, though. What needs to be done to qmail to make it bind to
> > > a specific IP? This is pretty vital that we bind to separate ips because
> > > eventually we will be putting in 4 network cards (one for each queue).
> > >
> > > To further increase our hardware aresenal, once we find the optimal
> > > performance setup, we're going to build 5 of them. We'll have 5 machines
> > > generating mail, 5 sending, and we hope to be able to send upward of 10
> > > million or more per day. At that time we'll also have a 256mb cache on the
> > > raid controller so that the queue can run much more efficiently.
> > >
> > > I think that everyone on the qmail list deserves a big thanks from all
> > of us
> > > for the valuable information and insight. It appears that qmail will be a
> > > successful solution for us, and ironically, thousands of dollars cheaper
> > > than the Big Hardware Big Software microsoft solution that we were using
> > > before.
> > >
> > > Once we get the network cards in and binded, we'll be on our way to a
> > > wonderful solution...
> > >
> > > Cris Daniluk
> > > MicroStrategy
> > >
> >
>
>
