I have been writing a session engine (finished) for xml-rpc. My test was to write a file txfer program and nail the server with as many concurrent requests as possible.

As expected, the jvm on the server made the biggest impact, the second was the RPC server. What I did not expect, was that jserv, tomcat and iPlanet performed about 1/2-1/4 as good as the stand-alone Webserver class in XML-RPC library. I attribute this result to the webserver's throttling the thread usage and thunking overhead.

My tests transfered a 600mb file from 4x machines (1 macos10.2.1, 2 sparc 10's, 1 netra X1, and 1 win2k) over a 100mbs link, with 200+ sessions total. I did say nail right? With one session active, I could txfer 1mbs wth the Webserver class and 256kish using the others.

I noticed that thread and cpu usage was way up on the Webserver class (assuming lots of activity was being processed), while the others would only give about 25% of a load.

If you want unbridled performance (relative, I guess) , use the Webserver class. If you need a speed governor or prevent a runnaway, use a servlet engine.

On Tuesday, October 29, 2002, at 01:46 PM, Danny Angus wrote:

I would think so.
Some people might suggest you look at resin too..
d.

-----Original Message-----
From: Martin Redington [mailto:m.redington@;ucl.ac.uk]
Sent: 29 October 2002 18:34
To: [EMAIL PROTECTED]
Subject: standalone server versus embedding in tomcat



My app will receive a significant, but not a massive load. I expect to
receive batched requests (batched from the client, unless XML-RPC
supports batched requests ... I haven't seen any documentation for it),
in small batches of four or five.

The application is a digital assets management application. I expect 10
to 20 concurrent users in my first installation, but I would like to be
able to scale to hundreds or thousands of concurrent users.

Am I right in thinking that I am better off using a heavy-weight
container, such as tomcat, rather than using the standalone servers?

cheers,
Martin




Reply via email to