SimYard runs on a webserver with eight cores. The games themselves run as a PHP script on this machine. Recently, the game hit the maximum speed because the PHP script was running as fast as it can and couldn’t keep up. The solution was to make it multithreaded, and so the adventure begins.
The script used to work this way. It would start up every hour and only run for an hour before shutting down. It would start by loading all of the games that are in-progress. Then it would process one at-bat for each of those games and look for new games to start. Every at-bat was followed by saving the changed records to the database. Anyone watching a game has an AJAX script which runs checking for new at-bats and refreshes when they are available.
This script wasn’t using up 1/8th of the CPU power on the webserver, though. The time that the script was taking was split between actually calculating the results of the at-bat (which uses CPU) and saving the results to the database (which takes none on the webserver). So I had a situation where the game was pegged out and couldn’t run faster, yet the server was only running at about 10-15% capacity.
After making a couple modifications to the way the data updates to ensure that these games could actually run multithreaded, I changed the way this logic works. Now, the script starts every five minutes. It runs for five minutes, starting by loading up any abandoned games which have not been active for at least five minutes. Then, it enters the same loop where it looks for new games to start and runs them. The difference is that once the five minutes are up, it stops adding new games. It just continues to run the current games it has. Once all those games are finished, the script exits.
This is working well. It’s resulting in a return to the fast gaming before SimYard got busy. And it’s much more scalable.




Filed under: