Ok the point is that a factor of 10 or so is indicative of a non-optimized run and thus a poor packaging that trip the classloaders.
The poor setup comes from confusion in the classes in the war and ear or duplication of the classes and what not. Just the simple test you mention david runs 10 times faster. BTW the line I was talking in the ContainerInvoker that I removed for JBoss 3.0 is the one that is making his tests fail and I wanted to remove it for _exactly_ this reason. Guys setup the supposedly integrated stacks, then the classes are not the same in teh different classloaders or are not present in the EJB package or go figure what he runs and it runs non-optimized as a result. Bottom line he trolls crying about performance. (no offense man we just had this discussion on why this particular category of problem appears). So next he will see "classcast exception" and won't worry about perf. Then running Resin outside stack is just the non-optimized run and tells you exactly what you need to know :) that the throughput when you serialize everything is 25 (minor gain over NON optimized tomcat). If the throughput was optimized you would see at least a factor of ten depending on the payload of his invocations which seems heavy anyhow hence a real native pointer stack would run above that. Are we clear? the goal is get the classes PACKAGING right, make sure the classes you reference are the one and same marcf PS: Also david you can see that advanced classloaders here would really help, we would get rid of this packaging nightmare and non-sense once and for all. THIS CLASS OF PROBLEM WOULD BE GONE, NO USER LIBERTY TO SCREW IT. To be honest I am not even sure I know on the top of my head how to package the stuff sure-fire so that you run always invm and since that test masks the problem he is fucked, he can't tell easily as we silently run with un=proper package. Let the engine blow. Running Resin is also brain-dead he is always running out of VM. Also here Orion uses the same classloaders when running INVM through and through hence running optimized even if the packaging is funky, we don't have that luxury today due to 3rd party integration that will be gone with the above and/or integration of stacks cl ala jetty. Bottom line the simplest in this case is to run 1- good package 2- same package on forthcoming 3.0 :) |-----Original Message----- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks |Sent: Tuesday, November 27, 2001 3:13 PM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-user] Redux of Performance Issues | | |I haven't looked on the forums in a day or two, so I'm not sure if you've |asked there as well. You may get more response. | |Have you run the testsuite and made sure it runs at a reasonable speed (= |very fast;-)? I'm mostly familiar with the 3.0 testsuite, but I would |start by running multithreaded tests like banktest with hypersonic |datasource and your production datasource. Try with different numbers of |threads-- I think in 2.4.x you have to go inside the tests and change |hardcoded numbers. I'm not sure where there is comparison info, but if you |get numbers that seem slow ask. If they are slow, there's something wrong |with your setup. If they are fast, then there may be something wrong with |your app or tomcat integration or ???. But start simple. | |david jencks | |On 2001.11.27 14:09:15 -0500 [EMAIL PROTECTED] wrote: |> 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 _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
