I recently downloaded the Apache XML-RPC package and found it to be very
functional and useful.  

I am using Windows 2000, jdk 1.4.1.

I wrote a simple performance test which repeatedly makes an XML-RPC call, to
see how many calls I could make each second.

I was surprised to find that in my system enabling HTTP keep alive
dramatically reduced the performance, instead of improving it as I expected.
I did a bit of experimenting, and found that setting the TCP no-delay option
on the socket helped quite a bit.  After I did this, the performance with
keep alive was about twice as good as the performance without it.

The change I made involved adding a single line to WebServer.java:

Index: WebServer.java
===================================================================
RCS file:
/home/cvspublic/xml-rpc/src/java/org/apache/xmlrpc/WebServer.java,v
retrieving revision 1.21
diff -u -r1.21 WebServer.java
--- WebServer.java      10 Oct 2002 00:24:12 -0000      1.21
+++ WebServer.java      2 Dec 2002 18:18:24 -0000
@@ -482,6 +482,7 @@
                 try
                 {
                     Socket socket = serverSocket.accept();
+                    socket.setTcpNoDelay(true);
                     if (allowConnection(socket))
                     {
                         Runner runner = getRunner();


I was wondering if there is a good reason not to set TcpNoDelay some of the
time.  If there is, perhaps it could be an option (XmlRpc.setTcpNoDelay(),
for example).

I also noticed with my JVM and operating system XmlRpcClient seems to be
about twice as fast as XmlRpcClientLite.  Perhaps the documentation could be
modified to indicate that you should try both and use the one that works
best in your environment.

Thanks,
--Ed Tellman
[EMAIL PROTECTED]






--------------------
This message (including any attachments) may contain confidential
information intended for a specific individual and purpose. If you are not
the intended recipient, delete this message. If you are not the intended
recipient, disclosing, copying, distributing, or taking any action based on
this message is strictly prohibited.

Reply via email to