response to your post on LJ re zeroconf-based
Ryan T. Dean
Thu, 9 Oct 2003 11:57:08 -0400
Content-Type: text/plain; charset=us-ascii
On Thu, Oct 09, 2003 at 11:03:10AM -0400, Justin Matlock wrote:
> This sounds like a great idea, from a very high level. But I can't think=
> a way to make this work with the PHP API, simply because it's completely
> stateless. There's not really any easy platform independent way to store
> data from one PHP script to the next, much less between different PHP
> processes running under different Apache threads. I guess shared memory
> would work, but... I see some issues there, as well (Windows doesn't have
> shared memory, being one).
> It would suck to have to 'rediscover' all of the memcached servers every
> time a script starts up.
> One way this could happen is maybe have a "master" memcached server, that
> used multicast to find other memcached servers. Have the clients contact
> that master server at script start up, get the list, and use it to spread
> the load.... but that's still a network call. Or, use shared memory on =
> web server, and have it 'expire' every 10 minutes... when that 10 minutes=
> up, it just fetches a new list from a master server? Or, simply have
> memcached write a temporary file (actually a script) that is just included
> with every script (this, of course, opens up all sorts of scary security
> implications -- I know I wouldn't want my sites creating 'scripts on the
> fly', especially since my webservers are AFS mounted read only).
> I dunno... it's just something to keep in mind... I don't know how mod_pe=
> is -- but PHP is completely stateless... when a script ends, any
> variables/etc are gone.
I can't think of any easy ways to store a server list from request to=20
request. The only ways I can think of, off the top of my head, are...
a) shared memory, be it through the sysvshm functionality or the=20
b) writing out a .php file that gets include()'d
c) writing out a text file (to the filesystem or to a memory-based=20
disk) and parsing it out on every run.
Aside from that, I can't think of a way to hold the variables between=20
script executions. The limited functionality PHP has for inter-module=20
communication (apache_note(), apache_setenv(), setenv()) all keep track=20
of what was done and un-does it at the end of script execution.
Of all of the options above, b is probably the least secure, and a is=20
probably the fastest. b and c could (theoretically, at least) work on=20
multiple webservers at once (using the same file shared via nfs or afs),=20
while using a you would have a shared memory segment on every webserver.
Then, of course, is discovery. Do we hard-code a master server that we=20
can do a lookup on to find all the other clients? Do we broadcast a=20
multicast packet (assuming this is even possibly in PHP, I'll have to=20
check) and find all of the servers? Or just a server, and then we poll=20
it for all the available servers?
I could maybe see downloading the server list every time from a master=20
server - LJ does this from MySQL, doesn't it? For all its MySQL=20
servers? - that might not be too expensive. But we still need a server=20
to poll from, which means hard coded or broadcast discovery.
As to memcached server(s) answering a request on what servers are=20
available, I imagine a flag could be added to memcached which takes a=20
ip:port argument, and then the server on startup would connect there and=20
announce its availability. It could then download a copy of the current=20
server list, or the 'master server' could push it out onto all of the=20
slaves... Alternatively, there is of course multicast traffic for=20
discovery. But thats more out of my area. :)
In any case, thats what I've got for the moment.
-Ryan T. Dean
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
-----END PGP SIGNATURE-----