Hydlide.nl - KeepAlive changes on reason experts

KeepAlive changes on reason experts

Posted on 26 Jan 2012
Posted by Hydlide

Optimization of today would be something called bandwidth usage. Currently this is not an issue (by far), however I would like to limit the amount of bandwidth in procedures where it does not need to send back and forth complete information.
On the current design of the website reasonexperts.com I have implemented a feature which is called 'keep alive'. This keep alive sends back and forth information about the amount of users, posts, articles posted and so forth. However, this information is usually pretty small to begin with.

Theres one specific point where I already had done a similar improvement, which was the chatroom. Basically the http return values are usually pretty empty to start with. By returning no results what so ever, I can solve 2 issues at the same time. First of all, the connection does not reset after a request had failed (since it would return an empty result too), and second the amount of bandwidth would be rather limited to the chat.

The only thing that would require a bit more resources would be on the server side. Since everything is being stored on a server side session level. And with resources, I mean storage... since in a way, a session is nothing more then storing a textfile in array format (serialized) on a harddisk.

So to solve the keep alive issue, i took a similar method of the ajax chat method I already implemented. In the following scheme you might see what has been altered here:
 

 

The script had to change on two different levels here. First of all the javascript that would handle all the traffic. Since eventually the javascript would execute a page refresh on every http request that would take place from keepalive.

By adding a simple 'storage entry' in javascript, I can compare the previous request with the next one. If the next one would be empty, nothing has to change on the screen.

By storing the session (server side), I can return an empty http request when the previous request is the same as the next one. Yeah, theres where it gets complicated more or less. One change is server side and the other one is client side. But since its a constant interaction between the two, it needs to be modified on both sides.

Even while the new modification looks more complicated (from a coding point of view), it should eventually add some performance issues on the client side of things. Since normally the screen needs to be updated everytime something gets returned (which is not the case anymore).

 

Post comments

Please post your comment

Name:
Comment:

Recent comments

no comments posted yet