Re: Re: [PEPr] Comment on HTTP::HTTP_SessionServer

From: Date: Sun, 17 Oct 2004 21:45:44 +0000
Subject: Re: Re: [PEPr] Comment on HTTP::HTTP_SessionServer
References: 1 2 3 4 5  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-33913@lists.php.net to get a copy of this message
Hi, Olivier Guilyardi wrote:
But, as far as I googled, there really seem to be nothing standardized. Each, platform (websphere, etc...) has its own backend, accessed through a standardized "HttpSession" interface. I don't know what exists for .net, but I found this interesting Java-oriented article : http://www-106.ibm.com/developerworks/java/library/j-jtp07294.html Looks like this article uses a different approach. They do not store the session data in one central location, but use replication to copy the session data to all servers in a cluster. When mixing programming languages, this will get messy.
I only took a quick glance at this article, so if I got something wrong, please don't hit me. In the environment I'm working, my application has basically two sessions. One standard PHP session and one that I'm using when interchanging data with other applications, that are built in any programming language. This provides a lot of freedom for the individual application, but still allows features like a single sign-on.
"[...] A more common approach is to combine load balancing with session affinity -- the load balancer is able to associate connections with sessions and route subsequent requests within a session to the same server. This feature is supported by numerous hardware and software load balancers and means that replicated session information is only accessed when the primary connection host fails and the session needs to be failed over to another server." That's correct, we are using techniques like these in the company I'm working at, in fact we also use load-balancing for the session servers and the session-id already contains information about the IP of the host that stores the session data, so balancing is only used when starting a new session.
But this is something very specialized, that we implemented to use in our own enviroment.
Well, it's not exactly a matter of buying a server, you still need the bandwidth pipe :-). Many people can only afford shared hosting, as opposed to a dedicated server. Is load-balancing forbidden to them ? Of course, they could get a faster shared hosting account... Some may still want to do load-balancing in this situation though, for fun :-) Then they will have to live with an XML-RPC-based interface, but this is really totally different from the SessionServer I implemented. I would not want to include this and encourage people to use a technique that should not be used. Parsing and creating XML is something you do not want to do on every request.
I'd rather just serialize the session data and put it in RAW_POST_DATA to store session data via HTTP. To read session data, just append the SID to the URL and return the session-data in a serialized format. The session server for this basically would be: <?php $sessionFile = '/tmp/session/'.$_GET['sid']; if (isset($HTTP_RAW_POST_DATA)) { file_put_contents($sessionFile, $HTTP_RAW_POST_DATA); } else { echo file_get_contents($sessionFile); } ?> This is faster (but still not as fast as using a simple protocol and a simple daemon) but still makes the session data accessible via HTTP. There's no need for raping webservices :) But you still need one apache process for each request (that is one on the webserver and one on the session server) and this will lead to problems. At least the number of Apache processes is a problem in several of my projects as they require a lot of memory). A simple session server has a significantly smaller memory footprint, thus more processes can be run at the same time. Just my 2 cts. Stephan

« previous php.pear.dev (#33913) next »