Hardcore Performance Through Socket Servers, part 2
Posted by John Kleijn • Sunday, December 30. 2007 • Category: PHPIn 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.
Notice: the design of this package has changed since the first publishing of this post. The class diagram and accompanying text have been updated.
The bootstrap files are illustrated as objects and represent the global space. It illustrates the association between a multitude of client global spaces with a single server global space. Socket_Socket is a wrapper around the socket resources, providing the interface for server and client to work with them.
For this to work, we need a couple more components. In fact we need a whole application, but that's a little much to layout in a single post (or a whole series for that matter). You'll just have to imagine a large, hefty MVC application for this exercise. For testing, we'll be using some simple stubs for some of the key components. It has a controller package with a Request type and a Front Controller, that's all that is required to know right now.
Our first consideration is how to aggregate the data to send over the virtual wire, and which data we need. The most appropriate solution is to use Transfer Object (Alur et al, Core J2EE Patterns- page 415). Transfer Object is one those stunningly simple patterns that applies to many situations. Its intent is to create a representation of the state of one or several objects, suitable to serialize and send across different tiers of your application, which are potentially remote. In this case, we know for a fact that our destination is remote ("remote" meaning "outside of the execution environment").
That's probably a little more introduction than it deserves, given it's simplicity. Anyway. Here's the Transfer Object we'll use*:
class Request_Http_TransferObject {
private $data;
public function __construct(Array $data){
$this->data = $data;
}
public function getData(){
return $this->data;
}
public function squash(){
return serialize($this);
}
}
* A note about code examples: as a rule, they are heavily simplified and often incomplete, for the sake of brevity and focus.
That's it for now, I'll continue with this example in the coming posts.
ShareThis
