>>> Kevin McEntee <[EMAIL PROTECTED]> 12-Jan-00 5:27:56 PM >>> >I've searched the web for this sort of criteria and objective >comparing but I have not found anything worthwhile. Testing web systems is difficult. Essentially you have to tailor the test to match your circumstances. There is work going on to understand how web systems might be quantified but components like servlets are far in advance of such work. The biggest problem is always the contention that sits at the heart of all web based systems (except the single thread model which is inherently inefficient). >Here are some of my criteria off the top of my head: >* Speed of database intensive pages >* Speed of computational intensive pages This is fine but how do you define intensive for your 2 categories? >* Speed of static pages or images >There are a lot of pages that contain several images. I suspect >that many servlet engines with built in http servers overlook the >optimization of serving static resources. This is not such a big deal because getLastModified() really kicks in with static stuff but despite that quite a lot of work has been done by servlet engine producers. I've just been testing JRUN (for example) at image serving and it's damn quick. >* Stability Again... what does stability mean? IMHO stability is not such a big deal with most pure Java engines... I've never seen one that worked but was flaky. What stability problems do you refer to? >* Ease of administration >This is very open ended. Indeed. There follow some of my thoughts on this testing lark... *Test with your application* It's my view that servlet engines are a part of the new way we deal with finding solutions to IT problems. We are more professional by and large, and the IT commmunity has met that professionalism with flexibility. We design our applications more than we ever used to, we think about the way they're going to work and then we find a tool that fits that method. This is partly because of the sheer number of solutions available (eg: should we use CGI, mod_perl or servlets?) and partly because we do now have the ability to get hold of the solutions in order to test them. We can get hold of them because the free software movement forces even the big boys to make their toys available for download for a trial period. I would recommend anyone who is designing an application around servlets to obtain trials of a large number of servlet engines and test them with their finished app. In addition you may find that your developers work with one engine but you host on another (perhaps purely because of ease of use). No problem here either, I know quite a few developers working with Apache Jserv and hosting on JRUN (or something else). I myself work on GNU-Paperclips but host on JRUN. *Use OO code* This is so often stated but so rarely done. Many programmers and designers claim to build OO apps which in the end are procedural apps written in Java or C++. With a proper OO layer you can take the web out of the equation and just test your OO code in a scientific manner. In a nice language like Java it's fairly easy to setup some test scripts which kick off 100 or so threads and test your objects inside them, thus creating some form of emulation of the contention environment of an HTTP server. *Use a web based tool for testing* A web based tool like Apache's JMeter can help, it's never going to give data for scientific analysis like a conventional test tool but it does give you a finger in the wind. Other, very expensive test tools are available and these are nice if you can afford them (I'm aware of a project to provide a free, scriptable test tool - that will really be something). *Release your app to "beta" for test purposes* There's nothing like getting the public to do some testing for you. Put timers into yuor code and measure the specific operations your worried about. Then get the public to use your tool. Hey presto! data! Hope this is food for thought for some people. Nic Ferrier ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
