Speeding up client/server response times

Published on Jan 10, 2011 by Jamie Munro

In the past 6 months I've switched jobs from being a web developer to being a server side game developer. So far it's been an excellent career shift. I get to focus on my true passions, intelligent back-end code and no longer having to waste my time with frustrating design challenges (there is a separate team that does that).

Having said that, when developing large Facebook virtual worlds, there are a lot of client/server communication. For example, each time someone buys something, each time you buy something, etc... Currently, a lot of games wait for the server to respond, but why should we? There are a lot of server calls that are done for informational purposes; just to keep the database up-to-date. So I ask you, why should the end user wait for the server to catch up? Let's examine a simple approach to alleviate the need for the client to wait.



The scenario below describes a typical client/server/database infrastructure with Flash as the client, PHP/Apache as the server and a Mysql back-end as the database, probably the most typical setup. The example is, a user just purchased a decoration in their virtual store. Several things need to be done:

1. The client (Flash) needs to visually place the item where the user purchased it.

2. The client needs to visually deduct the money spent.

3. The client needs to tell the server (PHP) about the purchase.

4. The server needs to validate that it is a real item.

5. The server needs to validate that the user has enough money.

6. Finally, the server needs to save it in the database for when the user returns next time.

Steps 1-3 do not concern us, as the Flash development team will handle these processes, we care about 4-6. Below is some sample PHP code, that doesn't do real processing, just pretends to:

<?php

// Check if the item exists?

if (!doesItemExist($_REQUEST['item_id'])) {

echo 'ERROR';

exit();

}

// Does the user have enough money?

if (!doesUserHaveEnoughMoney($_REQUEST['item_id'])) {

echo 'ERROR';

exit();

}

// If we get here, let's tell our client it's good and we will

// finish our processing after

echo '1';

flush_buffers();

// Save to the database (we are just faking some processing time)

saveItemForUser($_REQUEST['item_id']);

function flush_buffers(){

ob_end_flush();

ob_flush();

flush();

ob_start();

}


In the above code, we do our basic error checking first, if there is an error we return it right away and the client will display an error to the user. This should never get triggered unless the client and server are out of sync.

If there are no errors, we immediately return 1 to the client so the user can keep playing. We then do our actual processing of saving the information to the database. In other scenarios, if there is no error checking required, we can just return "1" right away and keep processing.

Don't quite understand what this script is doing? Run this sample script to see:

<?php

echo 'Processing...<br/>';

$y = 0;

for ($x = 0; $x < 500; $x++) {

$y++;

}

echo 'Done processing, lets respond<br/>';

echo 'The rest we can do silently....<br/>';

flush_buffers();

for ($x = 0; $x < 50000000; $x++) {

$y++;

}

echo 'Now we are finally done<br/>';

function flush_buffers(){

ob_end_flush();

ob_flush();

flush();

ob_start();

}


What you should see are the first 3 echo statements appear almost immediately, then the page will keep running until our extremely long for loop is done. Once this is done, then the final message will display. Enjoy!

Tags: Optimization | client/server | speed | Theory

Related Posts

blog comments powered by Disqus