I suppose I am after a few things. Initially my thought was a standard simple test that will permit a company to test it against several servers to see which one fits the bill for performance, price, etc. You mention a test suite that does this, I didn't even think about that.
My second thought is a tool that like the big boys, can simulate virtual users, run nodes on each "client" machine to simulate them, and aggregate data, as well as have nodes on the server side, maybe even the DB side to monitor things like cpu utilization, request/response timing, and so forth. All of that data is aggregated to the central client where you control various nodes, configure them, etc. I know tools from Mercury Interactive and others can do this, but at astronomical costs they are not feasible to a small company. But that is more or less what I am after. --- Jon Barnett <[EMAIL PROTECTED]> wrote: > Just my two bits worth again - > > I guess fully built applications are fine for > exercising the entire app > server or as much as you can make it exercise the > entire app server, and > perhaps I focus on the micro-level a bit too much > but: > > The high level testing view doesn't tell you > individual breaking points - > at what request rate does my stateless session bean > container degrade in > response performance, at what request rate does my > stateful session bean > container degrade in response performance, etc. What > characteristics can I > expect for each of these in single and clustered > mode? e.g. What is the > response curve? > > With high level testing, you get an idea overall > perhaps - but because > things will most likely break at different points, a > specific application > may self-destruct before or after a general test > application breaks. The > natural bottlenecks in a general application may > hide problems in an area > of concern because other circumstances prevent a > particular sub-system > from reaching a critical state. > > SpecJ2002 does provide you a framework for cluster > testing - I think the > test results for a HP cluster just came out. All > well and good in the > general testing category - but what if my > application has a critical > reliance on JMS? How do I know when that will break? > What if the > application server doesn't support it? How do I > exclude that testing > category? > > It depends on where you want to take your test suite > and whether you want > to benchmark specifics or general operation. > > Mine's a mechanic's view point. I'm not with JBoss > Group - but the code is > open source. So I'd like the analysis tools to send > 240V 3-phase through > some JBoss sub-system and determine the output > response. If there's > roll-off when I vary the input, I'd like to know why > so it can be fixed. > ;) And obviously I'd want the controls to vary the > input. At the moment, > I'm pretty much creating the tools as I need them > since none come to hand. > ECperf doesn't have the granularity of control and > ease of use to perform > any diagnostics on things when they break. It > probably gives purchasers > the warm-fuzzies and I believe that is the sole > intention of it. But other > than that, it has all the finesse of a chainsaw when > trying to perform > microsurgery. :) > > If your suite is intended for multiple app servers, > using xDoclet would be > nice. SpecJ2002, at first glance, seems to have > progressed from ECperf 1.1 > in that the coding is neater but it still has those > pre-built XML > deployment descriptors so it's still a roll your own > in that department - > just a little painful. I've got to dig deeper yet. > > Remember - none of this is meant as a criticism. I'm > just interested in > seeing where you're going so I know whether we > overlap or we don't in what > we are doing. :) > > JonB. > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > Behalf Of Kevin Duffey > > Sent: Saturday, 26 July 2003 12:26 AM > > 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. > > ATTACHMENT part 2 application/x-pkcs7-signature name=smime.p7s __________________________________ 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
