Thread history
Viewing a history listing
| Time | User | Activity | Comment |
|---|---|---|---|
| 08:02, 5 April 2013 | Skilgannon (talk | contribs) | New thread created | |
| 15:57, 5 April 2013 | MN (talk | contribs) | New reply created | (Reply to LiteRumble Statistics) |
| 16:01, 5 April 2013 | Skilgannon (talk | contribs) | New reply created | (Reply to LiteRumble Statistics) |
| 17:17, 5 April 2013 | MN (talk | contribs) | New reply created | (Reply to LiteRumble Statistics) |
| 17:40, 5 April 2013 | Skilgannon (talk | contribs) | New reply created | (Reply to LiteRumble Statistics) |
| 18:04, 5 April 2013 | MN (talk | contribs) | New reply created | (Reply to LiteRumble Statistics) |
| 21:43, 5 April 2013 | Skilgannon (talk | contribs) | New reply created | (Reply to LiteRumble Statistics) |
| 21:48, 5 April 2013 | Skilgannon (talk | contribs) | Comment text edited | (add task queue quota info) |
If you refresh your LiteRumble home page, you'll see a link at the bottom which takes you to the all-new LiteRumble Statistics page. This page is updated once an hour, on the hour, and contains the latest contributor information as well as how big the queue is and the expected processing backlog based on how many were processed in the last minute.
I also improved the OverQuotaError handling so that from now on your rumble client will see a regular server response and won't go crazy with the uploading errors. Also, from now on, when the queue is full it doesn't give an OverQuotaError, but instead waits half a second and sends a nice message back to the client saying that the upload was discarded.
Enjoy!
Yes. Because of this it doesn't have pure FIFO behaviour, sometimes new items get run before old ones, but for the most part it is FIFO.
Is the upload queue size the amount of battles which still needs to be processed?
Which means while the queue size is greater than zero, we can stop uploading battles and the server still has work to do?
Exactly. The amount of time it is estimated the work will take is the Queue Delay, but this is only based on the average speed in the last minute so it fluctuates a lot.
Did the queue replace the older cache? No more evicted battles?
Also, I know there is a quota for task queues, of about 100,000 messages/day.
No, the older cache is still there. It serves two purposes, 1) I don't have to write to the datastore every single pairing, which is slow, and 2) often a single bot gets lots of battles all in a row (eg just released) and in this case my database writes will be cut almost in half if I am caching them. There are virtually 0 evicted battles now that I keep just two queues for 1v1/melee, instead of 1 queue per rumble with a minimum of 5 unsaved battles before a bot was written and a minimum of 10 bots needing to be written.
I think that was the old quota for task queues and it has now been increased. In the control panel I see a quota of 1,000,000,000 and I'm less than 1% of that.
