Talk:Darkcanuck/RRServer/Roadmap

Why Re-Create Battles?

I think "delete all my battles & re-load all battles from ABC's server" should definitely be on the list of next steps. It might even encourage my contribution to world peace. --Simonton 16:46, 26 September 2008 (UTC)

I didn't realize that all battles were available on the old server architecture. For some reason, I thought it only kept summaries, but if I can import all that data, that would be great! I won't be deleting any battles from the new server though -- almost all of the data submitted has also been relayed to ABC's server, so his server should be a superset of the two. For an import I would just pull in all of ABC's data (plus the Elo rankings, it would be nice not to have to recalculate those) and there's a duplicate checker which would throw away duplicated results (bot, challenger, timestamp + user IP determine uniqueness). But if you want to contribute to both, just upload your results to mine and they'll also be relayed to ABC's. And keep your "remove old" and "ratings" URLs pointed at ABC's server if you want to flesh out the pairings over there, my clients will keep the pairings here in line. -- Darkcanuck 17:01, 26 September 2008 (UTC)

The old server never deletes battles, it keeps a (huge) log of all of them. That's actually what led to the first file corruption problems, disk space usage can grow a lot when you leave it running for years. Keep that in mind when you design your battles table, it can easily grow into the millions of rows. BTW, in my server I did a backup/reset of that log somewhere around 100 battles per bot, you should download the battles_* files form the backup dir and append the ones in the main dir. --ABC 17:22, 26 September 2008 (UTC)

Cool. I had a look at those files, it should be straightforward to create an import script, the format is simple. But weren't there some issues with bad results early on? Did you remove all of them by hand, or do I need to filter them out? Also need to figure out how to keep the two systems relatively in sync. Duplicate checker or not, if all that data gets imported and we want to import some updates later on, it might crush the server to keep having to re-import a 40MB battle log.

Storage space is something I've kept in mind. I've tried to keep the battle results limited to fixed-width binary fields and have some more space-saving plans in the works. Should be much more compact in a database than in plain text files. But I'll probably periodically archive retired bots' results to keep the table lean & mean. -- Darkcanuck 18:24, 27 September 2008 (UTC)

I removed all of the bad results (and some good ones in the process), those files are clean. The battle timestamp field should be enough for avoiding a full re-import. We should also discuss what to do about the future, do we merge efforts or keep 2 separate servers running? --ABC 18:53, 27 September 2008 (UTC)

I'll give my perspective as somewhat of a bystander: I think it would be really cool to have a RR server both with some of the features Darkcanuck has been working on at the same time as some of the features ABC has been working on (real neat graphs!). That said, I'd prefer to sitck with having ABC's separate server until this new codebase has proven itself stable. I'd also be tempted to say that I would try to help with a merged effort, however currently I don't think I have time to devote to that, due to a combination of coursework and addiction to working on my next bot. --Rednaxela 19:20, 27 September 2008 (UTC)

If I had known you were going to enhance the old server code when you set up the temporary server, I might not have started this. :) But I think merging the two efforts is better in the long-term, it doesn't make sense to have different rumble servers all over the place. In the meantime, you could try relaying your results over to my server -- if we both check the referrer field (I'm sending "http://darkcanuck.net/rumble") we can avoid endless relay loops.

My new problem, much to my chagrin, is that the relay wasn't working 100%. Which means I have results that you don't. It's fixed now (and slower, yay) and the relay confirmation is now also sent to the client. I've disabled relaying for melee because it's far too slow and I don't think you're set up for melee? -- Darkcanuck 19:32, 27 September 2008 (UTC)

I'm guessing that each time your server gets a result, it uploads it to ABC's server and then only once it gets a confirmation from there it sends the confirmation back to the client? How about going multi-threaded, and for each result start a new thread that uploads the result to ABC and then terminates if it is successful? You can send confirmation to the client immediately and the client can immediately upload the next result. This should be significantly quicker. While we're on the topic of multi-threaded, I always wondered why the client didn't do this, ie. simply upload the result after every battle in a separate thread. Another option would be to zip the results into one file and upload them all together at the end of each iteration. --Skilgannon 22:09, 27 September 2008 (UTC)

Speeeed

You just made a comment about this, but let me reiterate it. Submitting results is really slow. I just did some timings: it took 7:42 to run 30 battles, and then 2:28 to upload the results. That's alomst 25% of the time uploading results. The solution is in the use of threads, but really it would be best for those threads to be on the client side, to avoid overwhelming the server. However, nobody has been working on the client, so that's why I bring it up here. Any thoughts, ideas? --Simonton 22:28, 27 September 2008 (UTC)

You're right, it's the relay that's causing most of the delay. Uploading melee results (no relay) is fairly zippy. I had a faster version running prior to today but it wasn't always submitting 100%. Basically the relay would open the http connection, post the data and then close without waiting for a response. It was working initially, but I double-checked some results this morning and they weren't going through, hence the revised slow relay.

I don't want to multi-thread the server (not sure if I could even do that). I wonder if this is something that could be fixed on the old/current server? But yes, I would like to see changes to the client -- it's in the "How you can help" section. :) My priority is to get things working ok with the current client and then make some incremental tweaks to improve performance, data integrity, pairing completion and add new game types. --Darkcanuck 00:09, 28 September 2008 (UTC)

As far as the relaying, as I understand, while you can't thread directly in PHP, there are some ways to do parallelism via spawning another process (see this for a PHP class that simulates thread-ish activity with processes). As far as the client, I'd agree client improvements would be good. Since threads are pretty easy in Java as I understand, I'd say that in the long-term anyways, relaying should be abandoned in favor of making the clients able to upload to multiple servers at once and do it in the background while more battles are running. Which reminds me: the ITERATE option in the client also should be fixed (it currently breaks the proper selection of enemies) but that's another topic and I have reported that bug. --Rednaxela 00:27, 28 September 2008 (UTC)

Hmm... even without the relay, uploading seems quite slow. Also viewing the results/details page seems slower on the server-side than I think it used to be. Is there any reason it may be slower lately or is this just an error in my perception? Either way, what is probably the main source of slowness now that we aren't relaying? --Rednaxela 23:15, 23 November 2008 (UTC)

Haven't worked on the server recently, but when I tested performance previously, the pairing query used to generate new scores was the bottleneck. It's a very big table and each query returns 600+ rows so lots of potential for slowness in the shared hosting environment I'm using. There's also table-locking going on, which slows down page views when there are many uploaders. I plan to move to a transactional model soon, just don't have the time to properly test it right now. Unfortunately I can't tune MySQL better for our needs... --Darkcanuck 04:13, 24 November 2008 (UTC)

Lost Features

One utility on the old server that I really liked, but which is not on the new server, is being able to 'diff' one bot against another. Additionally, being able to diff against bots that are no longer listed in the rumble would be VERY useful, ie. for comparing results with old versions. --Skilgannon 12:55, 16 November 2008 (UTC)

I second that request. Those features are absolutely essential. --ABC 22:58, 17 November 2008 (UTC)

I'd third that one. I used that feature of the old server extensively when I made new releases before. Additionally I think it would be nice if in the details page of a bot, there could be a links or a dropdown to compare to other versions so that manual URL fiddling like in the past isn't needed. Not a necessary addition to the old feature, but a nice-to-have thing. --Rednaxela 23:30, 17 November 2008 (UTC)

Hmm, never used that feature but I see how it could be useful. I'll add it to the short list -- not much server development recently, I've been focusing on other things, including targeting. --Darkcanuck 06:07, 19 November 2008 (UTC)

Page to bulk upload result

I'd like to suggest this feature, for a one who running overnight battle without internet. Uploading through the client uploader are very awful, it's really slow. If you can create a web page which allowed us (or only me?) to bulk upload the result (from resultsxxx.txt) directly to server, it would be good. The problem is the server didn't know codesize of each robot... » Nat | Talk » 14:43, 16 May 2009 (UTC)

The server can only process so many uploads at one time and it's much better if results are uploaded in small bursts over time rather than at once in one big chunk. A bulk upload function is definitely not going to be implemented. There are already too many problems related to the client storing results for long periods: what happens when bots are removed while your client is offline? what happens when you upgrade/downgrade the client? I'm glad that you're submitting battles, but keep in mind that this is not a competition. Quality over quantity please -- I want to spend my free time programming robots, not repairing tables and purging bad results. --Darkcanuck 06:24, 17 May 2009 (UTC)

I understand, both about the server load and the competitions thing. But I hate seeing my client spent 3 hours each morning uploading result =) Did client check the participant list before upload? » Nat | Talk » 06:33, 17 May 2009 (UTC)

No, the client just blindly uploads whatever is in the results file, which is why sometimes bots get added & removed several times. I've added a few tweaks on the server side to reduce the add/remove thrashing, but there's only so much I can do when the clients control who gets added or removed. --Darkcanuck 07:59, 17 May 2009 (UTC)