never say anything because you'll find lots of differing religions but
this is my experience and the such...
Oh BTW, recent benchmarking done by Mladen Turk and Remy Mucharat of
JBoss has proven that under certain scenarios (which frankly I thought
were unlikely) using Mladen's extra native stuff for tomcat that it is
actually faster than HTTPD under load. The trick is by reassigning
threads during between Keep Alive pings (it goes into a keep alive
pool). Many sysadmins disable keep alive which then has its own
negative issues. I am actually pessimistic about the result of these
benchmarks because I thought the long pause of the keep alive was an
unlikely scenario, but I do thik the approach is obviously warranted.
The biggest scalability issue as I see it in Tomcat (besides the
clustering which you frankly need to use some other implementation than
the default one that comes with TC) is Jasper (the JSP engine, you don't
need to worry about the compiler since you should always precompile).
Also tomcat creates a lot of garbage when parsing HTTP headers and the
such. These can be somewhat controlled with some of the tuning
settings, but better GC implementations (Sun JDK 1.5, BEA's JRockit).
One major pitfall companies make is the assumption that so-called "Big
Iron" will perform *better* than a PC. Depending on what you mean by
big iron (Say OS/390 boxes or AIX), this is usually not the case. IBM's
VM has fallen behind in GC performance (their benchmarks will always
prove otherwise but I'm only talking REAL applications) and file system
performance is always and issue (efs2 on Linux is actually pretty fast
as file systems go).
So far if you're after a performance target, I've had very good
experiences with:
1. Solaris 9
** on 8 use the Alternate Thread Library
2. JDK 5.0 (1.4.2 has nasty parallel gc bugs especially on solaris, 1.5
is not bugless)
3. 4+ cpu boxes to take full advantage of parallel CPU
4. If you ahve a lot of data consider caching with 64 bit VM allowing a
theoretically ectobyte of heap.
5. Make sure you reduce -XX:+ThreadStackSize and -Xss so that you do not
get 512k-1M stack per thread (generally excessive, but these are the
defaults for -server on 32 and 64bit respectively)
However, that's not a cheap box!
As an alternative:
1. Any Linux Distro But Red Hat. (Red Hat has been habitual about its
special sauce kernels which have had issues with Java, especailly ES
3.0's backport of the 2.6 thread model to 2.4) You can make it work
with Red Hat, but they keep doing this sort of thing.
2. 2.6 kernel -- its the threading (Red Hat's backport of this to 2.4
crashes Java randomly so you have to put LD_ASSUME_KERNEL=2.4.1 which
puts you back to 2.4 thread model -- you know because if you type top
you see 1000 javas)
3. 64-bit AMD (4+ cpu if you can for parrallel gc)
4. Sun JDK 1.5 (there are problems reported with JRockit on AMD, since
Intel actually does most of the JVM authoring this is not suprising
frankly -- However one can assume this will change now that intel has
licensed EMH64)
The above isn't very expensive. You can get that going at intrex probably.
Intel's new Xenon's have licensed x64 tech from AMD, however, benchmarks
seem to come back slower on these with 64-bit vms due probably to the
way pipelining was integrate (IIRC x64 has more). Some benching with
JRockit has not been positive against JDK 5.0 but I'm not really very
confident in those numbers because I've had pretty good experience with
it. Early reports are that hyperthreading is actually advantages
despite all speculation to the contrary (myself included). I've not
seen the kind of long term use of JDK 1.5 on AMD, taht I've seen on
Soalris. On the whole its way more stable than 1.42 at least on
solaris. (the Solaris guys rewrote the GC so duh)
lastly:
OS X...not great for Java servers. Don't get me wrong, I love it on my
laptop and the VM for raw unthreaded performance is great. However the
kernel locking and the such and apple's lag on releases.....likely this
is not a realistic platform for Java servers.
Win64 even Microsoft tends to discourage.
never ever ever use -Xconcurrentio on recent 1.42s on solaris...
-andy
Bryan Kearney wrote:
Keep in mind when load testing what a "user' is. Too many folks will use
a tool like JMeter, create a scenario with 10 steps, and send each URL
one right after the other. A human user will read the pages you send
back (unless it is VCR instructions). So.. create your scenarios with
approriate wait times between pages. 100 concurrent users may only be 10
actual concurrent hits to the tomcat server if you have very dense content.
-- bk
[EMAIL PROTECTED] wrote:
Does anyone know the answers to the following:
1.
What is the rated capacity (concurrent users) for Tomcat on some
average server?
2.
Can Tomcat be in a clustered solution to increase user capacity?
3.
Is there any statistical formulae that help estimate the number of
concurrent users given the overall number of users per hour (or day)
that may login?
-Chris
------------------------------------------------------------------------
_______________________________________________
Juglist mailing list
[email protected]
http://trijug.org/mailman/listinfo/juglist_trijug.org
_______________________________________________
Juglist mailing list
[email protected]
http://trijug.org/mailman/listinfo/juglist_trijug.org
.
_______________________________________________
Juglist mailing list
[email protected]
http://trijug.org/mailman/listinfo/juglist_trijug.org
