People often wonder how fast a system based on Xmlrpc-c (or indeed,
anything with the XML-RPC protocol) can run. XML-RPC is known as a
protocol that makes speed a very low priority, but C is known as a way to
write programs that run faster than just about any other kind.
Naturally, there is no simple answer to the question, "how
fast does Xmlrpc-c go"? There are so many variables in any
application that it's almost irresponsible to report any number of
RPCs per second or response time.
Nonetheless, some information is better than no information, so I
ran some measurements and the results are below. I don't give enough
information for you to reproduce the results and it's unlikely your
application is similar to my test. Yet this should make your wild
guess about what you can do with Xmlrpc-c a little less wild.
Also, the numbers are good for comparing a few of the options available
In the test, both client and server use Xmlrpc-c facilities. The
RPCs are trivial, like the "sample_add" examples in the
source tree. There is no significant processing done above the
Xmlrpc-c libraries on either side.
The client and server are on the same machine, so there is no
physical network delay. There is nothing going on in the test besides
computation, so the numbers are primarily applicable to a CPU-bound
The computer is a ca. 1999 personal computing class Linux machine.
Linux says the processing speed is 696 bogomips.
Xmlrpc-c version is about 1.12.
Here, we use true standard XML-RPC and a simple single-thread Abyss
server, like the xmlrpc_loop_server example program in the
Xmlrpc-c source tree. The client uses the Curl XML transport.
Note that in this configuration, there should be HTTP persistent
connections; i.e. 100 RPCs in a row should all use a single TCP
connection. But I didn't verify that it actually happened.
Persistent connections should make a big difference, especially with a
real network involved. See client library documentation for an explanation
of what stars have to align for an RPC to hitch a ride on a pre-existing
Using C, a client program starts (exec()), does 100 RPCs, and exits
in 380 milliseconds. With just one RPC, it's 26 ms. By calculation,
this means the time for just an RPC is about 4 ms, about 280 RPCs per
The 4 ms response time breaks down (from the client's perspective)
to 2ms of CPU time and 2 ms of waiting for the server. The waiting is
presumably CPU time in the server. Remember there is no transit time
in this setup.
Switching to C++ client and server, the 100 RPC run takes 1350 ms
and the single RPC run takes 60, so the marginal RPC response time looks
like 13 ms (triple that for C).
The 13 ms response time breaks down into 1.2 ms of client CPU time
and 12 ms of waiting for the server. (I can't explain why the client
uses less CPU time than in the C case, but the RPCs were actually a
Much of the CPU time involved in XML-RPC is in computing the HTTP
protocol. One thing Xmlrpc-c's packet stream variation on XML-RPC
does is eliminate HTTP.
In this section, we look at a test run using a packet stream client
and server (like the pstream_client and
pstream_inetd_client example programs in the Xmlrpc-c source
tree). There is no Abyss (because Abyss is an HTTP server). We
invoked the server and client with socketexec. (Like the
mentioned example programs, the test programs require a connected TCP
socket as input; the socketexec program is what creates that TCP
connection for it).
The code is C++ (Note that there is no C library for packet stream).
It takes 280 ms elapsed time to run a client program that does 100
RPCs. A run that does 1 RPC takes 68 ms. The run includes starting
and exiting the program, and socketexec.
This appears to mean it takes 2.1 ms elapsed time to do an RPC on
an already existing packet stream connection, i.e. 500 RPCs per second.
I measured the CPU time for one RPC as .7 ms on the client side and
.6 ms on the server side. That adds up to 1.3 ms rather than the 2.1 ms
calculated above, but it's in the same ballpark.
More detailed measurement of the one-RPC run shows that all the
Xmlrpc-c initialization and termination and the one RPC takes 10 ms of
CPU time, so the rest of the 68 mentioned above is running
socketexec and execing the client program.
As described in the manual, it is important to use the TCP_NODELAY
socket option (-tcp_nodelay option on socketexec), and
all the numbers above are with it.
When I failed to do TCP_NODELAY on one side, the throughput went
down to 12 RPCs per second. When I neglected it on both client and
server side, I got 6.