Let's play master and servant
Oct. 7th, 2013 12:51 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
ventaYesterday was the annual F5-fest of Glastonbury tickets going on sale. Which was made considerably more protracted because Seetickets were having "technical issues" for the first 30 minutes of the sale period.
I was also watching #glastonbury on the twitters. Lots of people berated Seetickets for their poor timing in having "technical issues" the day Glasto tickets go on sale. Er, y'know? I don't think it's coincidental. I think we, the Glastonbury punters, pretty much are the technical issues.
From the numbers I've seen, there were a million people registered to buy 135,000 tickets. That means a lot of disappointed people. And that's not Seetickets' fault. Once the issues were resolved, Seetickets were churning through 3000 ticket sales a minute on servers that were being hit by many times more people than that. Servers really aren't my specialist area, but I'm pretty sure that's not a trivial problem to solve. Compared to a decade ago, the ticket sales are incredibly smoothly handled.
However! One thing did baffle me. ChrisC and I sat on the sofa with three laptops between us, all hooked to the same wi-fi signal. His two laptops fairly consistently loaded the holding page which auto-reloaded itself and (eventually) popped you through to the actual payment page. My laptop consistently failed with the "connection to server was reset" message.
For an hour.
At one point I had two browser tabs open, and they both simultaneously loaded the holding page. They both auto-refreshed after ten seconds, and returned to the "connection reset" error. That was the only time I saw an actual page load on my machine.
Needless to say, ChrisC bought the tickets. I'm just confused as to how it's possible. Some sort of glitch in the server load-balancing software? Does it send (say) machines with differing IP addresses through different routes? I remember an incident at my old workplace where someone was trying to access a server whose load-balancing algorithm routed machines based on IP address parity (and the server handling "even" addresses was down). But I assume Seetickets are a bit more clueful than that.
I was also watching #glastonbury on the twitters. Lots of people berated Seetickets for their poor timing in having "technical issues" the day Glasto tickets go on sale. Er, y'know? I don't think it's coincidental. I think we, the Glastonbury punters, pretty much are the technical issues.
From the numbers I've seen, there were a million people registered to buy 135,000 tickets. That means a lot of disappointed people. And that's not Seetickets' fault. Once the issues were resolved, Seetickets were churning through 3000 ticket sales a minute on servers that were being hit by many times more people than that. Servers really aren't my specialist area, but I'm pretty sure that's not a trivial problem to solve. Compared to a decade ago, the ticket sales are incredibly smoothly handled.
However! One thing did baffle me. ChrisC and I sat on the sofa with three laptops between us, all hooked to the same wi-fi signal. His two laptops fairly consistently loaded the holding page which auto-reloaded itself and (eventually) popped you through to the actual payment page. My laptop consistently failed with the "connection to server was reset" message.
For an hour.
At one point I had two browser tabs open, and they both simultaneously loaded the holding page. They both auto-refreshed after ten seconds, and returned to the "connection reset" error. That was the only time I saw an actual page load on my machine.
Needless to say, ChrisC bought the tickets. I'm just confused as to how it's possible. Some sort of glitch in the server load-balancing software? Does it send (say) machines with differing IP addresses through different routes? I remember an incident at my old workplace where someone was trying to access a server whose load-balancing algorithm routed machines based on IP address parity (and the server handling "even" addresses was down). But I assume Seetickets are a bit more clueful than that.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2013-10-07 02:00 pm (UTC)All bets are of course off if you're coming from a non-NATted (or only partially NATted) network, but most residential customers will only have the one external IP. We have two but only because we've got a backup ISP -- I had my phone on that connection and didn't see even a holding page :(
There have certainly been suggestions that some ISPs were having more trouble than others yesterday, and that some of the problems may have been DNS-related (and therefore, yeah, possibly involving caching to servers which weren't reachable)