Hopefully, someone with more in-depth knowledge of JBoss (like Marc or
Rickard) can
shed some light on some things we are seeing with JBoss and how it runs,
particularly
on a Linux box.
1) When we start JBoss, there are a large number of java processes
started - I'm assuming
that represents all the services, etc. that it needs. Each one of these
processes is reported
as taking 156M of memory!! (More if we up the VM's heap size, etc.)
a. Why so much memory? Is it because they are all running their
own VM??
b. How come JBoss doesn't report the same number of processes or
memory on NT?
2) Somewhere on the JBoss site I found a blurb on benchmarking (at least
I thought I did) that
indicated it outperformed Weblogic. Can someone outline the parameters of
that benchmark
test? Or at least point me to some numbers or info on previous benchmark
tests?
3) This is our real problem: We start up a robot process that is logging
in only 15 users and
it is bringing JBoss to it's knees (in fact it blows up!). These
processes are testing a searching
app that uses four JSP pages and four EJBs. Not a whole lot to it, but we
do know that one of
our beans doesn't utilize memory as good as it can (and it is being
rewritten as you read this).
But there is NO WAY that 15 processes are going to take up 240+ Meg of
memory - as is being
reported by the process monitor under Linux.
Three of the beans are Stateful Session, the fourth Stateless Session. All
are set to a min of 5
and max of 25 for pooling. Initially, the pool for the stateless bean
jumps up (because it is
managing a connection to another box), but eventually they all stay around
the minimum.
We're thinking that maybe we'd get better results if we ran JBoss alone on
one box, then Tomcat
or some other JSP/Servlet/Web container on another box to see if splitting
them apart gives us
better performance. Any ideas on that??
Using version 2.0 final.
TIA -
Robert
ps: Weblogic didn't perform much better, to our relief. Guess that means
that we could go
back to the drawing board and inspect our code.
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
