For my use, I had no need to store the messages during testing. I simply wanted to count the number of messages sent and received and the time it took from first send to last receive. So using smtp-source and smtp-sink with time was all that I needed. My goal was to 1) find the optimal configuration of James for our use and 2) compare its performance to other MTAs (Postfix and PowerMTA were the ones I was working with). It sounds like you won't need smtp-source since you are sending from your application. But you might find smtp-sink helpful (it simply listens on the specified port, receives messages, and dumps them to /dev/null).
In terms of the configuration for James, that changed over the time that I was testing. I was trying to find the right buttons to tweak to get the most messages delivered per second. So I played with the number of delivery threads, the number of spool threads, the JVM settings (min/max/init memory), retry schedule, and so on. The conclusions I came to: 1) Set the number of spool threads to match the number of delivery threads for all RemoteDelivery mailets 2) Use 3 layers of RemoteDelivery mailets; when a mailet's queue gets big it gets very inefficient (likely something to do with resource locking) 3) Turning on debugging in the logs has a performance penalty but isn't too much 4) Turning on JMX has little effect on performance 5) Using the -server JVM flag is good (had to set MaxPermSize higher to avoid JVM crashes) 6) Setting the init and max memory in the JVM is good (both set to 1024MB) I hope that helps you get started testing, todd ps I have never used the DB storage for James; I read that it has a performance penalty which is a no-go for our needs. On Wed, Feb 3, 2010 at 11:30 PM, Nitin Gupta <[email protected]>wrote: > Thanks Todd, > > More than James, I actually want to test my application's email sending > capacity. I am making use of James as the SMTP server to which my app > connects to send the emails. By setting up a test env, I actually want to > blast out 1000s+ emails to dummy addresses and want to measure/analyze the > performance. > > In my case, I will probably replace the scripts you mentioned with my > application code. > > So please share how you setup the James finally & how did you set it up > during the text execution. Did you save the emails (during test & prod) on > file system or DB? > > Rgds > n > > -----Original Message----- > From: Todd Wallentine [mailto:[email protected]] > Sent: Wednesday, February 03, 2010 9:32 PM > To: James Users List > Subject: Re: James Load testing tool > > Nitin > > This past summer I performed some load testing on our Apache James setup. I > used the utilities that come with Postfix to make this happen: > 1) smtp-source (http://www.postfix.net/smtp-source.1.html) > 2) smtp-sink (http://www.postfix.net/smtp-sink.1.html) > I could never get Postage setup properly nor Postal ( > http://doc.coker.com.au/projects/postal/). > > I setup a separate machine running CentOS Linux that would perform the > sending and receiving of messages and wrote a couple of little scripts that > made use of the smtp-* commands. My test setup was still a long way from > simulating the real world but it gave me a reasonable test-bed for trying > out different configurations of James (as well as comparing to other MTAs). > > Hope that helps you get started. > todd > > On Wed, Feb 3, 2010 at 10:01 AM, Nitin Gupta > <[email protected]>wrote: > > > Hi All, > > > > > > > > Please suggest on which tool I can use to load test the James server? I > > read > > about Postage on the Wiki but did not found example of working > > scenario/code > > etc. > > > > > > > > Scenario that I want to replicate is: > > > > > > > > From my application I shall send out 1000s of emails to different test > > users. Then I would like to see how would James behave in real-world > > scenario under similar load. I hope I can manage this with Postage tool. > > > > > > > > Regards > > > > Nitin > > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
