Glastonbury online ticket sales fiasco

Seemed to work ok

I don't think it's fair to say that the system couldn't cope, just one part of it - the "busy site page".

As I see it seetickets.com seemd to have a load balancer set to shed all connections above their preset limit from www.seetickets.com to busy.seetickets.com

Everytime I loaded www. I would see redirect happening within about 2-3 seconds, so their initial gateway seemed to be fine.

When anyone I know got through to the next stage they had no performance problems so the servers at way-ahead carrying out the transactions seemed to be fine too.

It was only when directed to busy.seetickets.com that I encountered problems

As I didn't particularly want to see the busy page I wasn't too bothered about that as I watched the status bar for the switch from www. to busy. then reloaded the page.

Predicting that there was a chance of it being a sticky load balancer (which did seem to be the case in 2005 as well) we knew there was a chance that once one person got through we could all relay our details through to them to purchase tickets for us as their session to the servers would remain open until they closed their web browser.

Then again to anyone without much knowledge of possibel configurations it did look like the servers couldn't cope.

The banner add for easyjet on the busy page also couldn't have helped much with the bandwidth woes of that page though.

Coded by monkies?

Apparently the site wasn't clever enough to keep a successful connection open by IP address or cookies - it simply redirected a percentage of visitors to the index page of www.seetickets.com to busy.seetickets.com, but if you had a direct link to a page other than the index page on the www server, you could get in every time.

Apparently, many forums had links to pages other than the index page of the site and people got in fine through there every time.

Coded by monkeys indeed

Well, the system was marginally better than in 2004 when seetickets thought that a grand total of apparently THREE IIS webservers running a seemingly inefficient ASP application would withstand an obviously excessive traffic spike:

http://www.theregister.co.uk/2004/04/02/glastonbury_online_ticket_sales_fiasco/

While there is always going to be a huge spike, there is still much seetickets could have done to improve the system:

- Pages should have used CSS layout and heavily optimised HTML

- Pages still had debugging javascript in;

- 'Server busy' redirected the user to a different subdomain, complicating the process of retrying;

- All the traffic seemed to go to one subdomain; perhaps having the front page separate to the submission side might have meant submitting worked more efficiently.

- The server busy URL included a gif web banner. Nice use of valuable bandwidth...

- The choice of 'no coach' or 'coach' tickets had to be made up-front rather than at the booking stage, so the pot-luck of which form you could actually get through to meant that many people have ended up with a type of ticket they didn't actually ideally want.

- wayahead-secure.co.uk served pages (the same pages) could be reached directly rather than all equivalent domains being redirected to the official one.

These monkeys should get in some consultants who know what they're doing and know how to optimise things, and perhaps switch to Linux while they're at it.. :)

This year's system did indeed seem to give you success if you got the cookie. But, yet again, much of the frustration could have been avoided.

Always like this in Denmark

Here in Denmark, it is always like this whenever there is a big gig going on.

Be it Billetnet (Ticketmaster) or Billetlugen, the two major sales agencies, the sites cannot cope with the load of those major events. Every time they claim before opening up sales that this time there will be no problems – and every time they have to come up with excuses as to why problems had not been solved after all. On a good day, they will even claim that there were no problems, even though reports in the media clearly contradict that claim.

Just over a year ago, Citrix proudly announced that they had delivered a new, intelligent load balancing solution (Netscaler) that would make sure that such problems would never hit Billetlugen again. After the next major event, they were remarkably quiet about delivering that solution. :-)

Useless

Using Windows servers for a service which they know or suspect will be heavily oversubscribed is tantamount to criminal negligence IMHO.

Lest anybody forgets, though, the Glastonbury Festival has been going a lot longer than the Internet. So how did we manage to survive the ordeal of buying our festival tickets in Ye Olden Days before computers?

Well, Back In The Days, we had what was called a "distributed-load system" for ticket sales, which eliminated single points of failure. If you wanted a ticket for the Glastonbury Festival, you simply went to your local indie record shop (remember records?), theatre box office or tourist information centre and bought one from there. Then, while you were still in Town, you popped into the local bus station and booked yourself a coach ticket.

If you were unlucky enough not to get a ticket from the first place you tried, you phoned around a few other outlets. If you still had no joy, you watched the small adverts in the local paper in the hope that someone would have a ticket for sale.

There was no single point of failure (unless you count the initial distribution of tickets to record shops, but this was all done in advance before the rush started). I don't even remember there being stampedes in the record shops when tickets went on sale; it was all a lot more civilised (especially so, if you knew someone who worked there .....)

What was actually wrong with that system, anyway?

what was wrong with that system?

A J, essentially that older system was fine until the internet made ticket touting ridiculously easy and profitable. Kudos to Glastonbury I say, for actually making a decent attempt to solve the problem. Obviously there are still some problems with the tech of handling so many requests (which could basically be solved by having more servers, more bandwidth, and switch to Linux), but it seems to have gone off pretty well overall.

Fiasco indeed

I can't belive the b*llsh*t that i have been through for this.

I woke on sunday with the mother of all hangovers, with my little bro on the phone asking me for my bank details. He had got through, but there were no real tickets, only coach tickets, and not from birmingham - where i live - but from gloucester.

I obliged, extra £30 just to make him go away so i coudl go back to sleep - and it went through, all ok.

So i thought.

9 days later (READ: twice as long as it takes for a checque to clear in this country) i get an email saying that funds have not cleared no specific reason, and a link that when clicked dubiously filled my details in and asked me for £60 - with a note saying this is for the outstanding amounts ONLY.

WTF? Ok, so two tickets, @ £150 + 2 coach tickets @ £30 + £4 booking fee is £364, not £60???

I had heard that the coach tickets were inseperable from the main festy tickets, and i woudl not be able to pick up my festival ticket until half way through the coach journey, to ensure i dont mess up the local's 'park-in-a-field-for-a-tenner' policy this year. But no - its taken 9 days, and they have decided that they woudl take the £300 for the festival tickets, and fail the payment for some fraud reason, and tell me the funds havent cleared?

Having spoken to someone on the phone, i am still non-plussed about the whole fiasco, and 9 days after 'paying for my ticket' i still dont know if i have 'paid for my ticket'

If the £60 doesn't go through, what are they gonna do? charge me £300 and NOT let me go by car? WTF?