Sorry for taking a while to answer - was on holiday and fully offline :-)

David Luu wrote:
Thanks for the response Ken. Sorry, guess I wasn't too clear about my question, part of my question is also about the lifecycle of the XML-RPC server. Your response was rather generic in terms of PHP and not XML-RPC "server" via PHP.

With other languages where the HTTP server is bundled/built into the XML-RPC server, the lifecycle is you start up server, that's the instance of the server and it ends when you shut down the server. During its lifecycle/operation, all requests to the server go through the same XML-RPC server instance.

From your response and a re-looking at the code, I'm using these as reference
PHP XML-RPC server doc:

It appears the lifecycle is the "XML-RPC server" is initialized on an HTTP request to any PHP page that invokes the "XML-RPC server" (whether directly in the page code or via code in include file), and that the server sorta stops after it completes the HTTP response back to the requesting client? Because otherwise, the PHP module on the HTTP server would keep spawning XML-RPC server instances if its lifecycle didn't end with the response being sent back (memory leak, etc.), unless of course the PHP module knew to reuse the server on subsequent requests.

You are correct. The lifecycle of the xmlrpc server is (by default) as long as 
1 http request.
It's not a "server" in the way one normally envision it, ie. a long-running 
It does not have "start" and "stop" methods either.
It just does its job when asked to, leaving lifecycle management to the php+webserver engine. Start webserver => xmlrpc ready to be used, stop the webserver => no more xmlrpc endpoint available. Otoh a single xphpxmlrpc server object could serve many xmlrpc requests if the php code which uses it was developed in such a way - it's just not the default way of using it.

Long story:

This is the standard execution model of php: all objects are instantiated on every "page" request, and die with it (there are a few exceptions such as persistent db connections, but those are normally handled by C code from php extensions).
They are also not shared between different http requests (so 10 concurrent 
requests will each get its own xmlrpc server object).
This seems wasteful from a processing standpoint (both cpu and ram), and it actually is - but it comes with a major advantage: developers never have to worry about memory allocation and proper freeing of resources - as all memory allocated by the script and other used resources are automatically deallocated / torn-down by the language engine itself. And real-life has shown that in 90% of real-life usage, the time spent in creating / destroying php objects is extremely small compared to the time spent doing the actual computation (eg. querying a database and waiting for results).

Side note: a big performance booster for php is a so called "opcode cache", such as apc, xcache or eaccelerator. Those will hook into the php engine and avoid the compilation of the php script itself (into internal engine opcodes), which by default happens on every single http invocation as well (brrr, scary! but it makes developers lives easier by avoiding them to hit the "compile" button). If you have many lines of php code executing, this can give you a speedup of a factor of 10.

There are of course other execution / programming models available:

a) a php script might serialize objects and store them in between http requests, eg. in a memcache pool. This is of course only useful when object instantiation takes longer than access to memcache + object deserialization. It also introduces opportunities for locks, races, and all kind of hard-to-debug stuff

b) instead of using the "standard php on a webserver" installation, run a standalone php script which listens to http requests on its own. This way php objects can stay in memory for ever, and behave like they would in a JVM. You will get faster execution times (possibly, it's not 100% sure as all http parsing will now be probably handled by php code instead of C code), and a bigger risk of memory leaks. Look for a project called "nano" for a webserver-written-in-php. Or use php 5.4 which has a built-in webserver (but so far all php core devs recommend using it only for testing, not for prod). There are probably other projects available in this space as well (maybe the hiphop stuff from facebook or other "alternative php engines")

I would have to dig into the phpxmlrpc test suite to find out if it is factually correct, but iirc in the past I tested the phpxmlrpc server object to make sure it could work in the "single, long-running script" scenario, and there where no memory leaks of its own.

Hope it helps


On Tue, Dec 25, 2012 at 3:35 AM, Ken Almond < 
<>> wrote:


    Apache (when configured) loads a module -- so PHP is 'loaded' (ready 
to go) as part of apache startup.

    Yes, when HTTP hits Apache, the server.php file is loaded (on each HTTP 
request).     Since module is already running as part of apache startup 
    its 'very fast' BUT you do want to keep server.php files smaller (1,000(s) 
of lines) instead of 50,000(s) of lines. We used a URL name space to have
    multiple server.php files -- e.g. http://host/login.php (login.php is a 
server.php file), http://host/accounts.php, etc. -  e.g. 1 'server.php' for
    grouping of web services.   The login.php and account.php, and x.php and 
y.php can call into shared library.php(s) but again, overall, keep the #includes
    smaller so each server.php is not 'too large'.     We achieved average 10ms 
(where php called MSSQL inside) response time for 1,000(s) of simultaneous
    users on single apache server.

    Bonus tip

    We put 1^st apache server in DNZ zone (publically available for URL) and 
then used apache reverse proxy over to internal apache that that actually called
    the server.php(s) for very strong protection.    Worked very well.     Then 
as we grew, we used the reverse proxy to load balance -- but apache also has
    other forms of load balance.

    Good Luck


    <>] *On Behalf Of *David Luu
    *Sent:* Monday, December 24, 2012 10:35 PM
    *To:* <>
    *Subject:* [phpxmlrpc] How to start/stop XML-RPC server?

    I'm just looking into XML-RPC server with PHP, so have not much idea about 
its implementation and design.

    With other language implementations, it's easy to understand, as you can 
start/stop the server from command line (or other interface like UI, XML-RPC 
    for stop, etc.) as all the server functionality can be combined with the 
XML-RPC server itself as a single self contained binary/application.

    With PHP, the PHP code is served by a web/application server. So wanted 
some clarification:

    * how do you start the server? Start up the web/application server (Apache, 
IIS, etc.), then hit the URL to the PHP script that creates the server
    instance? Are the XML-RPC requests (different XML-RPC method calls) going 
to same URL or different one?

    * how do you stop the PHP XML-RPC server? Stop the web/application server 
itself? (e.g. Apache, IIS, etc.) Or is there a way to stop it w/o turning off
    the whole web/application server or say killing PHP.


phpxmlrpc mailing list

phpxmlrpc mailing list

Reply via email to