[phpxmlrpc] How to start/stop XML-RPC server?

[Gaetano Giunta]

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
>
> http://phpxmlrpc.sourceforge.net/server.php?showSource=TRUE
> PHP XML-RPC server doc: http://phpxmlrpc.sourceforge.net/doc-2/ch07s05.html
>
> 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 process.
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
Gaetano

>
> David
>
> On Tue, Dec 25, 2012 at 3:35 AM, Ken Almond <ken at almondenterprises.com <mailto:ken at almondenterprises.com>> wrote:
>
>     Hi
>
>     Apache (when configured) loads a php.so 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 php.so 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
>
>     Ken
>
>     *From:*phpxmlrpc-bounces at lists.usefulinc.com <mailto:phpxmlrpc-bounces at lists.usefulinc.com> [mailto:phpxmlrpc-bounces at lists.usefulinc.com
>     <mailto:phpxmlrpc-bounces at lists.usefulinc.com>] *On Behalf Of *David Luu
>     *Sent:* Monday, December 24, 2012 10:35 PM
>     *To:* phpxmlrpc at lists.usefulinc.com <mailto:phpxmlrpc at lists.usefulinc.com>
>     *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 call
>     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.
>
>     David
>
>
>
>
> _______________________________________________
> phpxmlrpc mailing list
> phpxmlrpc at lists.usefulinc.com
> http://lists.usefulinc.com/cgi-bin/mailman/listinfo/phpxmlrpc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.usefulinc.com/pipermail/phpxmlrpc/attachments/20130102/13e16d61/attachment.html>