look dude,

get the integrated jboss-tomcat stack you are running non-optimized out of
stack, period.

come back when you have set it up, or don't we don't care,

marcf

|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of
|[EMAIL PROTECTED]
|Sent: Tuesday, November 27, 2001 2:09 PM
|To: [EMAIL PROTECTED]
|Subject: [JBoss-user] Redux of Performance Issues
|
|
|For reasons unknown, this message hasn't been going out to the
|list.  Trying
|again.
|
|--
|
|Okay, I've clearly managed to piss off a few people by my concerns about
|JBoss performance.
|
|Let me start out by saying that I'd be more than happy to get my
|application
|working speedily under JBoss.  Orion's documentation is poor at best, and
|JBoss is fully open-source.  I have a great deal of respect for some of
|JBoss's technology (the verifier and deployer are probably the best I've
|seen), and where it's coming from.  I chose JBoss for the initial
|development because of its reputation and my own interests.
|
|That said, if the performance I'm getting out of JBoss is the best I can
|expect, or, at least, the best I can manage to get, then I
|absolutely cannot
|use it.  Not because I think it 'sucks rocks', because it doesn't, but
|simply because it will not support the user load I need it to in
|any sort of
|cost-effective manner.  Some of you would probably be just as happy to see
|me go somewhere else, from the tone of your emails, but I'd personally
|rather find a way to get the performance out of JBoss, for this or other
|projects.
|
|And, ultimately, it seems as if the performance I'm asking for is
|relatively
|reasonable.  I expect a certain amount of overhead in EJB performance, and
|I'm not asking to duplicate the speed of a bean-only implementation.  But
|supporting a maximum of 25 concurrent users on a decent (if not maxed-out)
|server seems ... suspiciously slow.
|
|It may be that I've missed some settings to speed things up.  It
|may be that
|our application's architecture is better suited to Orion than to JBoss.
|Whatever it is, I'd like to find out.  So I've joined the JBoss list, and
|I'm here to ask some questions.  I'm not trying to promote Orion, or insult
|JBoss.  I like bits of both of them, and the reasons for that, I can get
|into another day.  Ultimately, however, I'd rather support JBoss as an
|open-source appserver, if I can.
|
|--
|
|Now, on to the details.  Some of you pointed out, and rightly so, that I
|hadn't provided much in the way of details of what I've tried, which is
|true.  I wanted to start off by finding out if the kind of numbers I was
|talking about seemed realistic or not, based on the experience of people
|who'd spent more time with JBoss than I have, but it's probably fair to say
|that you couldn't really say without knowing a lot more about my
|application.  So let's get into a few details.
|
|Let's start with versions.  I did some of my original EJB
|experimentation on
|JBoss-2.4.1.  We started developing a project on JBoss-2.4.1a w/ Embedded
|Tomcat, which was the latest JBoss/Tomcat grouping at the time.  We started
|noticing performance concerns then.  When Tomcat 4 came out, we moved to
|JBoss-2.4.3 w/ Embedded Catalina, so that we could try a few things, and
|found it not to be slower, so we stayed with it.
|
|After we reached a point where we needed to see better performance, we did
|some optimizing of our app with a profiler, and tried JBoss 2.4.3 w/ Resin,
|which we already knew to be fast.  That gave us a minor speed
|boost, but not
|very much, leading me to believe that JBoss might be the cause of some of
|our performance.  By comparison, Orion 1.5.2 seems to be very much faster.
|
|All of this is running on Windows 2000.  The versions of Tomcat are 3.2.3
|and 4.0, as far as I know.  The version of Resin is the latest
|version as of
|a few weeks ago, I'd have to go check.  If it's important, I will.
|
|Processor speed depended, but developers are working, largely, on
|PIII-700MHzs, and we did most of our load-testing on a Ghz P4.
|
|Tuned updates are on, jaws debug is off, and logging was set as low as we
|really could expect it to be.
|
|Our performance numbers were derived in several ways - by using the
|Microsoft Web Application Stress tool (since we've used that in the past,
|and haven't yet found a better alternative; if you have suggestions, I'm
|happy to hear them), watching memory/processor load on the box
|being tested,
|junit test times and subjective experience.
|
|Our initial concerns came out of JUnit test times.  Our EJB tests
|(which are
|pretty thorough, I'll admit) are taking several seconds, whereas the time
|required to test a hand-rolled bean solution was usually well, well under a
|second.  HttpUnit tests are taking tens of seconds, instead of seconds.
|This began to concern me, but we didn't need performance at an early stage,
|and I knew I could replace Tomcat and/or JBoss if necessary.
|
|Once we started to use the Web Application Stress Tool, though, we started
|to get really concerned.  After some profiling to speed a few things up, we
|were unable to get more than about 20 simultaneous users on the application
|without slowing things down significantly, getting Time To Last
|Byte on some
|of the more intense pages up past ten seconds, which is far too long.  Even
|running Resin and JBoss together was getting us only up to 25.  The
|processor usage on the server while the load test was running was
|practically solid at 100% for the bulk of the test and the JVM doesn't seem
|to be using up all the memory it has already, so we didn't increase the JVM
|memory space.
|
|By comparison, under Orion, I can get 350 users on the same
|application, and
|the processor load is only up around 65%.
|
|This concerns me.  The application is going to be used by quite
|probably 200
|users at once, possibly double or triple that, on a regular basis, and
|perhaps up to 2000 users under peak loads.  That's not a
|massively-heavy web
|application, in my mind.  Not being able to get past 25 users
|under JBoss is
|just not going to cut it, so if I have to put up with poor documentation,
|closed source, and shelling out for an orion deployment license to get the
|speed I need, I will.
|
|But if you all can recommend alternatives to get speed out of JBoss, I'd
|love to hear it.
|
|--
|
|There's been a number of suggestions to try JBoss/Jetty.  I'll give it a
|shot, although I don't know much about Jetty.  I'd also like to throw
|together a simple performance test that I could use to demonstrate my issue
|a lot better than the existing application, but I don't know if
|I'm going to
|have time to do that, particularly since I also want to evaluate the
|newly-free HP-AS to get some feeling for it in comparison to both JBoss and
|Orion.  It may turn out that we go with Orion for this project simply to
|save time figuring out our other options.  If we can get acceptable
|performance out of Orion in the near term, it may be more cost-effective
|than spending time diagnosing our JBoss issues.
|
|If there are suggestions on how we can increase our performance,
|or requests
|for more information, I'm open to hear them.  Even if I don't have time to
|implement them on this project, I'd love to know how I could make use of
|JBoss on future projects without encountering this kind of performance
|issue.
|
|Thanks in advance,
|
|       - Geoffrey
|
|__________________________________________________________
|Geoffrey Wiseman: Internet Applications Manager
|Medium One
|t. 416.977.2101 x. 529
|http://www.mediumone.com/
|__________________________________________________________
|Think it.  Build it.  Work it.
|
|
|
|_______________________________________________
|JBoss-user mailing list
|[EMAIL PROTECTED]
|https://lists.sourceforge.net/lists/listinfo/jboss-user


_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user

Reply via email to