You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rpc-dev@xml.apache.org by "Tellman, Ed" <EC...@dolby.com> on 2002/12/02 19:37:32 UTC
TCP no-delay option
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
ect@dolby.com
--------------------
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.
Re: TCP no-delay option
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Tellman, Ed" <EC...@dolby.com> writes:
> I recently downloaded the Apache XML-RPC package and found it to be
> very functional and useful.
Great, always good to hear. :)
...
> 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.
...
Apache httpd does the same thing. I responded in a separate message
with the commit log of the change you prompted.
> 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.
Sounds like a good change. Up to writing a second patch? Look in the
xml-rpc/xdocs/ directory for the appropriate XML document to tweak.
- Dan
Re: TCP no-delay option
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Tellman, Ed" <EC...@dolby.com> writes:
> I recently downloaded the Apache XML-RPC package and found it to be
> very functional and useful.
Great, always good to hear. :)
...
> 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.
...
Apache httpd does the same thing. I responded in a separate message
with the commit log of the change you prompted.
> 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.
Sounds like a good change. Up to writing a second patch? Look in the
xml-rpc/xdocs/ directory for the appropriate XML document to tweak.
- Dan