Well if you want to learn xdoclet, the Xpetstore is the place to start. I recommend you download the source and get stuck in. It's quite simple.
The xpetstore is actually split up into two implementations of the same web-app. One uses ejbs with struts as a front-end, the other uses hibernate with webwork as a front-end. I recommend you look at the ejb implementation (contained in the xpetstore-ejb folder). Xdoclet is used to auto-generate all the xml configuration files for you, and the reason the xpetstore can deploy on each of the server is that xdoclet "tags" for each application server are placed within the ejbs. If you have any problems understanding any of it, give me a shout. I'd love to see a basic app working with clustering too, and some performance stats. Brian -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Duffey Sent: 25 July 2003 15:26 To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Parallel thread performance: A JBoss client example Great idea. You know, first I don't know what the heck this xdoclet is. I see it being used in JBoss and other places, but it's one more darn thing I gotta learn! Second, I am hoping that clustering works out of the box, with very little changes to the server, to support clustering. I know JBoss is thus far the easiest to configure. I am hoping that Orion is similar (still). I did it back in the early 1.x days, so I am not sure how their 2.0 version clusters. WebLogic, well, that's a pipe dream that I'll have test on that, too much darn money, unless they have a free trial version but even then I recall they charge more for their clusterable version than they do for single jvm version. --- Brian McSweeney <[EMAIL PROTECTED]> wrote: > Hi Kevin, > > This sounds like it would be a brilliant thing to > do. > As a suggestion, if you want it to run a standard > app > on multiple app servers as the test, it might be > possible to use a current sourceforge project. > > The xpetstore project deploys on JBoss, Orion > and Weblogic by using xdoclet tags. > > Perhaps this app could be changed to handle > clustering > rather than having to write an entire app from > scratch? > > Just a suggestion, > > Brian > > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Kevin > Duffey > Sent: 25 July 2003 06:53 > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-user] Parallel thread > performance: A JBoss client > example > > For me, I want a comprehensive suite of tests to > run. > I want to measure the response times between a > client > and the server, the time a server gets a request > until > the time it goes back, the number of threads > running, > the number of simultaneous requests going at one > time. > I want to see reports on the scaling capabilities of > JBoss. One node, two nodes with round robin, two > nodes > with first available, three nodes, two partitions, > etc. I want to see how close to linear scaling > occurs > when adding more nodes, more partitions, etc. I want > to see for myself that my idea of a good cluster > architecture is indeed good, or maybe another way is > better. I want to do these tests for stateless ejb > and > statefull ejb, and while my specific needs to not > entail a web application, I would also like to see > the > performance with things like a client sending web > service requests, which in turn hit the ejb server, > and so forth. > > Ideally, it would be very strong for JBoss to have > these and many more test results available. > Realistically, we both know that no one app is going > to certify JBoss, every app will no doubt have > different characteristics, and thus results. But it > would be great to provide a client/j2ee type of tool > that can be used/deployed in any J2ee server to see > the various results. Running Orion, Jonas, JBoss and > Primatti side by side (one at a time of course) on > the > same hardware with the same test data and same setup > would be very nice, to see which one supports better > load, better clustering, better scaling, and so > forth. > These are the types of results I am after. > > --- Jon Barnett <[EMAIL PROTECTED]> wrote: > > Kevin, Bela; > > > > First thanks for the offer of help, Bela. Being > > downunder, sometimes you > > feel a bit isolated - where is the Australian > JBoss > > user community? ;) > > Anyway, I'm not sure where things are headed with > > testing but help is > > always appreciated. > > > > The testing question is a big one. It depends on > > what you are trying to > > achieve. > > > > If it is steady state operation, I would say that > a > > cluster of JMeter > > clients can generate a reasonable load that you > can > > tune. Based on the > > threading issues discovered here, I wouldn't have > > the client on the same > > machine under test if you are using Linux. There > > would be too many > > questions on client load versus server load. One > of > > the nice things about > > hindsight is that the free-running client load > > testing told us something > > about what to expect when looking at the > > JBoss-client results. So for > > completeness, you would probably want a > calibration > > sample of your test > > rig with the minimal JBoss interaction as we had > > done in the JBoss-client > > test. Then you can look at responsiveness under a > > certain load > > characteristic - for example 50 requests per > second > > what is the average > > response time, what are the maxima and minima. > Dial > > it up and check again. > > As long as the test rig can generate the requested > > load level (calibration > > will tell you when things might start to deform in > > the test generator), > > you will be reasonably certain about the > performance > > of the system under > > test. > > > > If you are just stress testing the system to check > > raw throughput, then > > you can adopt the load and transmit operation we > > employed for this test. > > Except we were hoping for less parallel thread > > coupling effects. You were > > able to see from these results for example, that > the > > name server and the > > EJB invocation were not unduly stressed with an 8 > > client-load continually > > making requests for an extended period (for the > IBM > > SDK). The predominant > > response characteristic was that of the client > > system. > > > > We haven't looked at your particular idea but any > > measurement is better > > than no measurement at all. Besides, I think there > > needs to be something > > beyond the ECperf-type tests. They tell you how > the > > big picture is > > supposed to work but don't help you work out where > > things fall apart. > > > > I would suggest that measurement data if possible, > > is not transmitted from > > the server during testing (unless you can > guarantee > > its affect would be > > minimal to the testing results). > > > > I think the best thing is to flesh out what you > want > > to come away with > > from the testing. I'm sure there are others here > in > > the forum with good > > test and measurement experience who can contribute > > to the cause. An > > example of things to think about - do you want to > > test solely EJB > > performance? Do you want to couple it with a DB? > How > > do you separate DB > > from Server issues? > > > > Some nice things to see on the cluster testing is > > the impact of the load > > distribution algorithm. Is there a step-over > point? > > How would you test it? > > I think it is a matter of asking what you want to > > observe and then > > determining a test scenario that would allow you > to > > see it. > > > > Now if some Australian company can donate a Sun > > multi-CPU Blade server for > > testing, I could check the performance of the Java > > thread implementation > > on a Sun system. :) > > > > Anyway, that's a starter for discussions. I know I > === message truncated === __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
