In my previous post about performance through the use of a socket server I did a lot of talking, and I can understand perfectly if it leaves you clueless as to how to implement this idea.

Today I'll lay some foundations for an example implementation. First lets set the scene with a sequence diagram. It's probably not going to match the end result a 100%, but its intent is to sketch what we're going to create eventually. Don't worry if not all of it makes sense right away.

What it doesn't show is the client requesting the socket client file. There's nothing really out of the ordinary about that though. Next up, the class (or object) diagram for the Socket package, which is mostly a wrapper around the socket functions.

A while ago, one of the moderators over at phpfreaks.com asked me to write a little about an idea I had: to run an entire PHP application as a daemon. This post is about that idea, how it works, why it works, and why it doesn't work.

The Zend engine is pretty smart when it comes to optimizing, and using PHP as an Apache or FastCGI module increases performance by reducing initialization time for the Zend engine and PHP environment, but it doesn't do much for your "userland" application. With large applications, this can become an issue. Some, like Wikipedia, try to solve this by utilizing memory caching, for example using Memcached. While this definitely increases performance, it leaves something to be desired. A Memchached server is in fact a caching daemon, transferring string data over TCP/IP. This means objects have to be serialized/unserialized, which takes both processing power and time. There is also some network overhead, since one request might entail several calls on the caching daemon.

In addition, parsing time can become an issue if you have a relatively large library.

There is something that is both a recipe for the perfect cake as the ultimate disaster: a PHP application socket server. The base ingredients:

1. An application designed for efficiency and modularity;
2. A socket server bootstrap file;
3. A socket client bootstrap file.

That's it. As you can see it is fact stunningly simple.

Just a quick post about Mock Objects.

If you're interested in learning about them, read these two docs, written by the guys from ThoughtWorks. I found them to provide some valuable insights.

http://www.mockobjects.com/files/endotesting.pdf

http://www.mockobjects.com/files/mockrolesnotobjects.pdf