Hi Stefano,
many thanks for your explanations which sound quit plausible to me.
Nevertheless I would like to investigate a bit more if james scales good
enough for a use cases where heavy email encription/signing is applied.
How can I tell the proper version of e.g.
org.apache.excalibur.thread.impl.WorkerThread.java
which is obviously bundled with james 2.3.1, is it from excalibur 4.1?
Thanks and best regards
Peter
Stefano Bagnara schrieb:
Peter Doschkinow ha scritto:
Hi Stefano,
thanks for your fast reply! I swithched now to james 2.3.1 but I am
seeing only minimal improvements, maybe 5%.
What I observe is still too many threads waiting - at the OS level I see
that the LWPs(the light weight processes that the java threads from
james are mapped on) spend most of their time waiting on user
locks(around 80-100%), spending only max 8-12% in user time...
Asuming that the OS is distributing the java thread well among the
available 40 hardware treads, what would be the best configuration for a
load test on say 25 concurrent smtp client connections in terms of
number of spool threads and max. thread number in the default thread
pool? Can I get somehow rid of the impact of the watchdog-threads?
I spool around 1 million/mail per day on a small shared server using 50
threads, CPU usage is always very low, but disk/network usage is high.
In my experience the JVM version and the OS change the performance a
lot. I'm on linux 2.6 and the latest jvm 6 now.
There is not too much you can "tweak" in james spooling unless you write
your own spoolmanager object.
And there is not a generic rules for number of threads. Keep in mind
that the real world scenario is different from a load test. If you want
to make a good load test try to add a lot of
wait/sleep/timeout/unexpectedclose in your test connections.
E.g: In my server dns lookups are one of the most used resources.
Furthermore spooling is disk and network intensive rather than
cpu/thread intensive: don't expect to see the cpu to go high unless you
have a fast disk/cache and a fast network.
Stefano
---------------------------------------------------------------------
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]
