PHP Application server - GSoC proposal
After, not so good feedback after present my idea on the PHP Dev maillist (probably for my “English”) so I’ve decide to write a blog post about it, with the main goal of clarify all those dark sides.
Objectives
- Simple principle of work.
- Migration painless process, people should be able to copy existence code and put on the worker and it should work.
- Easy scalability, just add more workers on need.
- Provide a simple and effortless way to deploy application across many servers.
Some concepts
- Client: The client has a list of workers, he chooses one randomly (similar to memcached), and query a function or queue a job.
- Worker: C or C++ application with PHP embed, which listens a TCP port (probably 25887). The worker can accept request from anywhere, but only a single IP (from the master process) can submit and deploy
- Master process: PHP web page, where the sysadmin can upload PHP code and “deploy” (submit to every worker).
System overview

The graphic above show how the system will look like, the clients (PHP scripts that runs on the webserver) can connect to any worker and request a function or queue a procedure. In the case of a function the client expects a response, otherwise it will not. The master process is the only one allowed to submit PHP code to the workers, with this the system has a really easy way to deploy applications.
Advantages
- Single point of source code distributions.
- There is not a central point (aka manager process), the client speaks directly to a worker, this keeps it really simple and fault tolerant. In traditional models if the manager crash, nothing works.
- I am planning to add a Cache layer on the client, to avoid call same functions with same parameters, if the function is cacheable, in order to reduce the network latency.
- It can be used to process large amount of data in parallel, as hadoop does.
Why
The big question, Why should I use this to scale if there are plenty of others well tested method to scale?
Answer this question without fanaticism it’s quite hard, but I will try. Basically my goal it’s provide an easy, painless and efficient way to scale, basically those three words are the differences, in theory you will be able to migrate a site by simple cut-and-paste from your application to the application server (through the master web-admin-page), also the master web-admin-page will be able to generate Proxy functions with the same name as the old name (the function that was cut and pasted on the appserver), so for your application (on the webserver) nothing had changed. Also that proxy function will have cache support, if the function’s return can be cached.
Part of it’s efficient would be the fact that there is not human readable protocol (no json, xml, http), just a method for fast serialization and deserialization, representing in a binary format the data.
Will it be secure, ssl, authentication or something?
The answer is no, part of the simplicity and efficient it’s avoid what is unnecessary since it is supposed that the appserver will run in a secure private network, so why loose CPU cycles checking out security?, of course any function could receive, in example, user and password, and check before execute it, but it’s out of appserver’s scope.
What would be the advantage over similar projects
- Speed, since it will be coded in C with threads and PHP embed
- Fault tolerant, since no central point, no-worker it’s indispensable.
- Add worker on hot, (I still need to figure out how to let know to clients about new workers),.
- Cache on client by the default (If a function it’s configured has return a cacheable object).







