It is currently Sat Aug 19, 2017 4:42 pm Advanced search

Technical notes from the contest

Place where the Contest Admins can talk about the running of the contest.

Technical notes from the contest

Postby Janzert » Sat Dec 04, 2010 6:07 pm

This is just a post where I want to try and list some of things from the backend of the contest that might help whoever runs future contests. I'm sure not everything will come to mind right now so I will probably update this over time as I think of other items to add.

Several hard to fix problems were caused because we used a rather old OS version (Ubuntu 8.04) for the servers, newer language versions being available, known stability problems when running under EC2 and mono runtime semaphore leaks to name a few.

The primary performance bottleneck especially toward the end of the contest was the database. Certainly a larger main server with more RAM would help this. Also taking care in the system design to not use the database unnecessarily would help a great deal. Probably the biggest and quite easy change from the current system would be to store gameplay data directly in the filesystem. The current database table of playback data is over 50GB in size. It would be a double benefit if the change also made it so the web server could serve this data directly without going through contest code at all.

The initial compilation test should be extended to include some simple tests that the bot actually functions (there is some indication in the code that this was intended for this contest but never implemented). This not only keeps the crash bots out of the contest but also gives the bot author immediate useful feedback on the problem. These can also be extended during the early phases of the contest to catch some common errors such as the division by zero when the opponent has no planets left that was seen in planetwars.

It would be nice to extend the worker instances to not only play the games but also do the initial compilation test. This way the main server does not have to be kept up with any new languages added. Also the compilation test will be done in exactly the same environment they will eventually play under.

The use of Ec2 instances for workers was really nice for several reasons. One possibly non-obvious benefit is that when changes are made effecting the workers all the instances can simply be shutdown and new ones brought up that then load the new changes. Automating this in some way would be nice.

Janzert
Janzert
Contest Organizer
 
Posts: 271
Joined: Sun Feb 07, 2010 1:59 am

Return to Behind the Scenes

Who is online

Users browsing this forum: No registered users and 1 guest

cron