Re: [PEPr] -1 for XML::XML_RPC2

From: Date: Mon, 16 May 2005 17:02:07 +0000
Subject: Re: [PEPr] -1 for XML::XML_RPC2
References: 1 2 3 4 5 6 7 8 9 10 11 12 13  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-37680@lists.php.net to get a copy of this message
Sergio Carvalho wrote:
Greg Beaver wrote:
Sergio Carvalho wrote:
- Performance hit: I've proved it didn't affect performance. Get some numbers like I did.
We've been using the client as an example, but the client is never where the performance matters in XML-RPC. The performance hit I would like to measure is on the server end where script startup time becomes significant due to the need to accept hundreds/thousands of requests per minute on high volume sites.
It'd be the same. Where the bulk of time in the client is in the HTTP request, the bulk of time in the server will be DB/disk access. The setup times will be similar (it's the same code), so will go around the 5ms (for my laptop) value. This is one or two orders of magnitude lower than the response time of a datastore (filesystem or database).
I took the time to design a server-side test for a hello world function, and have some numbers. The test I designed is something like this: <?php $HTTP_RAW_POST_DATA = xmlrpc_encode_request('test', 'Greg'); require_once 'XML/RPC2/Server.php'; class myserver {
    /**
     * @param string
     * @return string
     */
    public static function test($a)
    {
        return "Hello, $a";
    }
} $server = XML_RPC2_Server::create('myserver'); for($i = 0; $i < 100; $i++) { $server->handleCall(); } ?> As you can see, the test minimizes the effects of load time and smooths out erratic compiler cache timing differences (before the loop, I would get differences of 47 ms to 190 ms in run time). I designed 3 tests, one using xmlrpc-epi, one using XML_RPC2, and one using Chiara_XML_RPC5. The fastest one, by far, is the xmlrpc-epi. It ran in 143 ms. Next was Chiara_XML_RPC5, which ran in 877 ms, and then XML_RPC2, which ran in 1531 ms. I ran the tests several times to make sure that the values stayed the same. Profiling was done by Zend Profiler inside ZDE. In other words, XML_RPC2's XML_RPC2_Value_* code is just under twice as slow as Chiara_XML_RPC5, and about 12 times slower than xmlrpc extension-based code. Chiara_XML_RPC5 is around 6 times slower than xmlrpc extension-based code. We can argue about whether an inefficiency is significant until we are blue in the face, but the fact remains that XML_RPC2 is doing twice as much unnecessary work as Chiara_XML_RPC5 in decoding a simple single-parameter function and returning the value. I'd be happy to provide numbers on decoding a 266-element array like that returned from release.listLatestReleases from pear.php.net, if that would be useful. The point here is that each tiny unnecessary inefficiency adds up in complex projects. Certainly an application with heavy database usage/filesystem usage will want to focus on this aspect of the code, no question. I simply don't see any real design benefit for the use XML_RPC2_Values for everything, they do not make the code easier to understand or easier to debug, and they certainly do not make it faster. If it would be helpful, I can happily provide code that allows the classes to still exist without forcing their use. Greg

« previous php.pear.dev (#37680) next »