Shared publicly  - 
"First come, first served"? The Google I/O registration page was polling the waiting list every 25E3+1E4*Math.random() milliseconds. The Ajax calls were returning the json '{status:waiting}'.

(1E4*Math.random()) - 1E4 is 1000 and Math.random() will randomly give you a decimal number, such as 0.5347112524323165 or 0.0210017969366163. 25E3 is 25000. So it was doing the ajax call every 25 seconds + (0 - 10 seconds).

I changed the code in the Chrome Developer Tools for a.setTimeout() to be 1000ms and I was polling much faster, but always returned '{status:waiting}'. The calls were returning very very fast, the server was not under much load. Oh well, maybe next year.

For you geeks, the code is below:

//General is for general admission, vs. academic
devsite.registration.setStatusCheck(window, 'general');

devsite.registration.setStatusCheck=function(a,b) {

devsite.registration.checkWaitListStatus=function(a) {
var b="/events/register/waitlist/status/"+devsite.registration.waitListKey+"/";
$.get(b, function(b) {
var d=b.status;
"waiting"== d ? a.setTimeout(devsite.registration.checkWaitListStatus,25E3+1E4*Math.random(),a) : devsite.location.href="fulfilled" == d ? b.details_page:"/events/io/register/noticket"}
RJ Lindelof's profile photoMike Wesner's profile photoJeremiah Bengtson (Deveration)'s profile photoJason Hsu's profile photo
Awesome digging into this, but some of your math is wrong, specifically.. order of operations! its really 25E3+(1E4*Math.random()).. so.. that's 2.5 seconds plus some random fraction of a second... so, this means that each browser was randomly hitting the site between 2.5 and 3.5 seconds.

But it does indicate that the front end was able to respond quickly, but I suspect that there was a bottleneck on the back end system that couldn't provide enough tickets (or they were slowly released over the course of 30 minutes, which doesn't make much sense to me either)
Actually, the math would be 25 seconds + (0 - 10 seconds). Meaning the refresh would be a random number between 25 and 35 seconds. Not that it really matters, because we didn't get in :)
Multiplication has a higher precedence then addition! So, to be clear, its 25E3+(1E4*Math.random()) not (25E3+1E4)*Math.random().*Math.random() will prove this... it will always return a number between 25000 and 35000. Your version is a number between 0 and 35000.

I completely agree with everything else you said.. just being a bit nit-picky (and hopefully helping you from introducing another problem in your other work). I got shut out too.
They probably placed the request in some kind of server side queue (like a JMX queue). Then the client can poll for his status randomly as you said. Once a ticket is available (like when someone couldn't pull the trigger with google wallet), the server can take the next request from the queue to match with a ticket. By the time the ajax call comes around, it'll be pulling something that'd already happened on the server.
I/O registration was run on Google App Engine this year. The calls would return at the same speed no matter the load. They did 6000+ requests per second during the registration.
Hmm interesting. So what I don't understand is why so many including myself got the noticket response. If the request was sitting in some sort of a queue on the server side and the ajax call fired at some random point after 25 to 35 seconds to check where in the queue the waitListKey is then how come a noticket response was issued when the status from the ajax call came back as waiting? I could understand implementing a server side queue and then continually have the browser query where in the queue the user is. Dispatch tickets one by one while everybody else keeps firing ajax requests until all tickets are gone. They could have even echoed where in the queue somebody is. Just doesn't make sense to return a noticket response and force the user to start another search, basically putting the user at the back of the queue again. A true server side queue without forcing the user to issue another request would have been much more like first come first serve.
+Marc Wangenheim I agree. I truly think there was some sort of mistake or defect in the server side code. Within 2 minutes I was told there were no tickets and I had to search again. I did that 7 times until...well, I failed. The more times I tried, the more times I got pissed off, which is why I started inspecting/debugging their code. We may never know what happened on the server side. I am totally bummed that I cannot attend this year.
I have no idea how they set it up, but I agree the user experience was bad. It should not have said "no tickets" in that case. It was better than last year though. 5xx errors are worse. It is an interesting problem. Might be fun to learn how they did it and maybe try to write a more UX friendly way.
This doesn't make anything better, if anything this just makes me more sad and depressed. I had to get the ball rolling on this back in november to get my company to put in POs. This is just pure ridiculousness.
+RJ Lindelof Many people did get their ticket on their third, fourth, fifth ticket searches.

It seems pretty clear from the way it worked that the system was not designed to just queue everyone in order of server request at 7:00AM PST. If they wanted to do it that way, no doubt they could have done so with either their own app engine backend or a third party trade show registration solution (Comic Con used EPIC to register their 2012 show, at one point queueing 60k users with no noticeable loss of registration server responsiveness).

Vic noted that one minute in they were averaging 6k requests per second. If they wanted to simply process everything in a queue, they could have, but then it seems likely that they would have sold out all available tickets in one minute rather than 20.
Add a comment...