[EMAIL PROTECTED] wrote:
Hi,
Hi, how's life back over that side of the pond? (I'm from Edinburgh myself)
I am looking to use Apache and Tomcat in my company's production web
site.
Before I can convince management that this is a good idea I need some
information so I am confident. If anyone can help I'll be very
grateful.
We have used Apache+JServ in anger for some time now, and it is good stuff.
We have load tested it to the limit, and it both degrades and recovers
very gracefully. My only concern would be how robust the Tomcat code base
is by comparison, given its youth.
First of all I'll give you a picture of the overall architecture that
I want to
create:
1) For fault-tolerance and scaleability we want to have several
instances of
Apache running over a number of machines. These will be load
balanced by a pair
of Cisco Local Director boxes, because we already own a couple of them.
>From a
brief look through the operating manual on Cisco's web site I get the
impression
that Local Director cannot support "sticky" load-balancing. Please
correct me
if I'm wrong.
Most of these products do support sticky load balancing, and I am pretty
sure that LocalDirector does. Beware - some of the cheaper systems do it
with cookies, thus are dependent on the browser accepting them. The better
ones use a hashtable of client IP's, much like a network switch does with
MAC addresses.
We don't use one of these, we just use round robin DNS across web servers
with real IP's, and so far it suffices to get pretty even load balancing.
The problem with a single LocalDirector is it's a single point of failure;
it could also in theory be a performance bottleneck if you have a LOT of
traffic twin LD's sounds better.
Even with a fair amount of our app being served via SSL, the web server
load is pretty small.
One minus point of JServ vs. a commercial appserver like BEA Weblogic
is that JServ relies on random distribution of new sessions for load balancing,
whereas WebLogic will react dynamically to appserver loads. You could of
course implement load management externally by using the jserv_shm file
to throttle new session allocations.
2) We will run several instances of Tomcat (version 3.2.1 most
likely) on our
back-end servers. These are a couple of Sun E1s with 32 processors
each.
These are partitioned up into domains, so that we end up with 12 processors
on
each machine dedicated to running Tomcat. Each domain has 2GB
of RAM. There
are other domains dedicated to databases, etc...
That's pretty serious iron (speaking as a former Cray sysadmin :-)
We just use a bunch of twin Pentium rackmount boxes running Linux for
the appservers, and use Oracle on Sun's for the DB only. E10k's are pretty
reliable, but I'd hate to lose half the appserver capacity in one go.
Of course, I'm a Scotsman, and your hardware probably cost more than
we raised in our first venture capital round :-)
3) Each instance of Apache will be using mod_jk in a "sticky"
load-balanced
configuration. Every instance of Apache (and so mod_jk) will
have workers
defined for every instance of Tomcat on both E1s. In other
words, a Tomcat
instance may receive a request from any instance of Apache.
The things I need to know :)
1) Each request to our site will be assigned seemingly at random
to one of the
Apache instances by the Cisco boxes. Can the "sticky" part of
mod_jk cope with
this? i.e. Will mod_jk pass the request to the correct
Tomcat instance even
though it does not share context information with the other Apache
instances?
Yes (at least, it works in mod_jserv) as long as they all use the same
route labels
2) What is the best way of running Tomcat on the large E1s?
Should I have
just a few very large processes (say 2 x 800MB max heap) for Tomcat
or should I
run many smaller processes (say 16 x 100MB max heap)? Has anyone
got any
experience with making Tomcat (or any Java based server) scale to machines
of
this size and power? I want to get good performance, but I don't
want to
compromise stability.
Java VM's can have trouble garbage collecting efficiently on very large
memory sizes. The conventional wisdom in the Java 1.1 days was to run appservers
in green threads VM's, which meant one VM per CPU (minimum). Solaris nowadays
has wonderful threading, so native threads in Java are very useable. Items
to consider, in no particular order:
- what are the characteristics of your app? What is the memory footprint
of a session? Are requests little or large (in terms of server CPU resources)?
What rate will a typical user make requests at? (the public on the web
will have a much slower pageview rate than telesales users on the LAN who
know their app like the back of their hand). How many sessions will be
active at once? Lots of light users and lots of little requests -> more,
smaller VMs; a few power users -> less, larger VMs
- number of filehandles and I/O sockets each VM can (efficiently) handle;
we found this was a limit on Linux wi
