[encoderer]

Let me preface this with a full disclosure: I've also waded into the depths of many of the PHP APIs that the OP has used to produce this project. I've created a general-purpose PHP daemon library (http://shaneharter.github.com/PHP-Daemon/).

There is no question that the PHP implementation of these APIs (think: Socket, SystemV, POSIX, etc) is very underwhelming compared to something you'd get in Python, Java, or nearly any language. And it's partly because of that that I felt it would be irresponsible for me not to include a disclaimer at the top of my github readme:

For many reasons PHP is not an optimal language choice for creating servers or daemons. I created this library so if you must use PHP for these things, you can do it with ease and produce great results. But if you have the choice, Java, Python, Ruby, etc, are all better suited for this.

So that being said:

With a general-purpose daemon library, there's a 3rd use-case to what you described: People who need to create daemons/servers/etc that use a large existing codebase: maybe it needs to share the 80 models that run your primary website. Maybe you've written a large domain-specific library. That sort of thing.

While it's a little more difficult for me to apply those reasons to a Tornado port, I'd like to hear from the developers first before I dismissed their work.

[hinathan]

This was exactly the situation for us at PBworks when I wrote my version of OP's system — huge existing business logic and object model in php but with new requirements and performance demands. Move the business logic into a stateful backend REST daemon instead of the frontend web servers, without throwing away all of the existing codebase. In one move you get the ability to load balance more naturally and persist data in-thread instead of e.g. huge memcache traffic for each user request.

[ma2rten]

The idea is pretty cool actually, but I am wondering: Is the advantage is really that huge over just running a normal PHP stack on the backend server in combination with local memcache?

[hinathan]

It is if you need to consider so many objects during a request that the memcached request and deserialization becomes too much time per API operation (requests like visible object ids in an unbounded folder with acls/permissions applied per item)