Peter Doschkinow ha scritto: > 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?
I don't know what is excalibur 4.1 It is from excalibur-thread-impl-2.1.jar, so it should be 2.1. Stefano > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
