Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.5.0, 1.5.1, 1.5.2
-
Fix Version/s: 1.7.0
-
Component/s: Zend_XmlRpc_Server
-
Labels:None
Description
[From matthew@zend.com]
– David Goodwin <david@palepurple.co.uk> wrote
(on Thursday, 15 May 2008, 10:43 PM +0100):
> > I've written a (relatively) small Zend_XmlRpc_Server service and I'm
> > pleased with the architecture of the code itself; however, I now need to
> > see if I can boost performance.
> >
> > The documentation [1] covers how the server definition can be cached
> > using Zend_XmlRpc_Server_Cache; unfortunately when I implemented this,
> > calling 1000 method calls goes from taking 1 minute 40s to 2m 40
> > seconds. Hardly a performance improvement!
> >
> > Has anyone else here used the Zend_XmlRpc_Server_Cache functionality,
> > and/or have any numbers to report back re "before and after"
> > implementing it?
Unfortunately, the server cache does not do what I intended it to when I
originally coded it. The problem with performance is due to the fact
that it must both re-instantiate objects as well as perform reflection
on all of them – but in reverse order (reflection objects are what are
cached).
I would like to address this in the future; would you be willing to put
an issue in the tracker, so it doesn't get lost, but also so that I can
ping you about testing?
In the meantime, you have a couple of options:
- First, don't use the server cache
- Make sure you are using an opcode cache
- Consider setting up functionality to cache read-only methods, so
that the XML-RPC server can be bypassed entirely for such calls.
Resolved in trunk. Usage remains the same. However, the server now stores the internal method mapping definition without requiring the Reflection objects used to generate it. This now nets a gain in performance when using Zend_XmlRpc_Server_Cache.