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 03:42 pm (UTC)no subject
Date: 2013-10-07 03:44 pm (UTC)I never got to find out what the error page would have looked like on an iPhone ;) All I got there was "could not connect".