From: Matthew French (mfrench42 at domain yahoo.co.uk)
Date: Wed 08 May 2002 - 17:58:11 IST
> The fact of the matter is I hate Java I think it's a load of crap...
I think Java is wonderful, but that is OT and has been discussed before so I
will not do that today.
And I do not expect C# to give any noticeable benefits over Java. <troll>
<troll> :)
> Anyway this is
> one of those webserver ->
> appserver -> database setups so between them all (when deployed within a
> single VM due to performance reasons (EJB local refs) and when pounded
with
> a couple of hundred client requests it crashes.
>
> This is why I need zillions of threads.
Ah. I suspect your reasoning may be wrong here.
As most people have mentioned, increasing the number of threads is usually
not a solution. Most web containers have mechanisms for handling new
requests that are not immediately assigned to a thread, queuing them
instead. Under load this is normally more effecient because the computer
gets to spend more time handling requests instead of trying to juggle them.
By way of example, it is unlikely you will get much performance improvement
with BEA WebLogic by increasing the number of threads beyond 40[1].
On this note may I recommend:
http://www.amazon.com/exec/obidos/ASIN/1904284000/ref=ase_javaperforman-20/0
02-9004950-8747266
Although I have not read it, I have attended several talks by the one of the
authors (Peter Zadrozny).
Unfortunately performance tuning is always complicated and it is very rare
that a single parameter will give appreciably better performance. If your
criteria is the number of simultaneous threads, then you are definitely
barking up the wrong tree. If, however, you are running proper benchmarks
and have found that the number of threads improves performance, then I would
have to suggest that there is something wrong with the application - or with
the benchmark.
My suspicion is that if you cannot connect to the server, then something
else has gone wrong - such as running out of file descriptors. Otherwise you
have placed an unreasonable load on the server which would also make Windows
or Solaris fall over.
At the end of the day, Linux and Windows should have similar performance,
with Linux being slightly faster in most cases. Context switches should only
account for a small amount of processor time - the Java VM is the one doing
most of the work and these theoretically share the same code base for both
operating systems.
Could you provide more information about the application: which VM, which
web server, which EJB server, how many processors, are you running as root,
how are you benchmarking, how are you generating all the requests, etc. With
this information I may be able to offer some more advice. I would also be
curious to hear if you solve the threading issue.
I should also point out that your math does not add up -> you talk about
creating over 1000 threads but then hitting them with a couple of hundred
pages. It is highly unlikely that you will need more than 1 thread/active
page request as I explained above.
On a parting note, I have found that using Apache to manage the HTTP
requests and then passing them on to the J2EE server can provide a
substantial improvement in perceived performance. Most J2EE servers have
ways of integrating with Apache.
HTH,
- Matthew
[1] Or something even smaller. This is dependant on the number of
processors, the type of application and all sorts of other variables, so it
should not be treated as gospel.
_________________________________________________________
Do You Yahoo!?
Get your free at domain yahoo.com address at http://mail.yahoo.com
This archive was generated by hypermail 2.1.6 : Thu 06 Feb 2003 - 13:16:41 GMT