Sign in / up

back to article Tube data feed shut for being popular

Transport for London has been forced to temporarily close its much-hyped London Underground departure times data feed due to overwhelming interest in the service. Application coders flooded the system after TfL tweaked its terms and conditions for using its datasets, allowing developers to access London's tube, bus and river …

COMMENTS

House rules Send corrections
This topic is closed for new posts.
  1. Jimmy Floyd

    Not all are down

    'London Tube Status' on the Android still works, but it's been around for a while and maybe pre-dates the free-for-all that came about last month?

    0 0
  2. Anonymous Coward
    Alert

    Free data is great...

    ...but this just proves that it doesn't come for free - there's a cost to it all.

    3 0
    1. Doshu
      Reply Icon

      yup

      as in most cases

      0 0
  3. Anonymous Coward
    Joke

    How hard can it be?

    Surely the only messages the TfL feed has to display are...

    Non-Summer schedule: "Sorry...if your service is even running, it'll be running late"

    Summer/Tourist schedule: " We on strike until we get extra caviar with our lunches. Try walking."

    3 3
  4. jonathan rowe
    Thumb Up

    Hunger for data

    Show's the hunger for the data, other government departments and organisations - TAKE NOTE - we want our data!

    1 0
  5. JaitcH
    WTF?

    Governmental IT at work

    Why is the UK government, and it's agencies, so incompetent?

    They should simply acquire copies of software from Canada or Seoul, Korea (by far the better) and dispense with those less than adequate characters that populate computer rooms at present.

    0 1
  6. Rogerborg

    Classy response

    No data is better than slow data.

    We had to destroy the user experience in order to save it.

    0 0
  7. David Edwards

    Capacity Planning on Open Data

    Its a headache, if live data is open to all without any registration etc trying to do any meaningful capacity planning is a nightmare. Simply saying the government should respond is demonstrating a lack of understanding.

    How are they expected to estimate capacity

    Should they just keep adding as usage goes up

    Do they just cough up for capacity costs and assume its "for the good of the public"

    How do they know if an app/site is to be launched with huge fanfare etc.

    How do you account for badly written code that hammers the service unnecessarily

    How do you cope with DOS type issues

    Possibly ie suggest some form of threshold based scheme, anything over X requests per day/hour/min whatever requires registration including capacity estimate (and they get better service e.g. emails re downtime, advice on new facilities, request to add data etc). Unregistered requests over that threshold could be blocked or throttled. (that assumes they can detect it e.g. from a server hosting the mash up, not the client)

    1 0
  8. Anonymous Coward
    Anonymous Coward

    Why?

    Why is every useful web service provided by the public sector always either massively undespecced? And why is every pointless web service provided by the public sectore massively overspecced?

    0 0
  9. Anonymous Coward
    Coat

    Having run some very high load public-facing stuff..

    The way to do is is to not let the public bang on your non-scaling servers. You have the vulnerable boxes behind a wall of public facing machines. The back-end machines push the data (or it's pulled from them) once per N seconds. Then the front end machines, nice fast web servers, serve the data up in a flat file stylee, and can handle millions of requests (depending on the size of the server farm).

    You use load balancing on the front end servers (round robin dns is fine, nowt expensive like wanky expensive arrowpoint-style stuff needed), and you can server a hell of a lot of users without breaking the bank, and gaining fault tolerance into the bargain (if you build it properly).

    End of lecture.

    1 0
  10. OffBeatMammal

    why not serve via someone who can scale

    surely the answer is to push their non-scaling data to a cloud service - Azure or AppEngine spring to mind- and/or issue a per-app key and rate limit that key to encourage developers to cache and/or reduce their poll times to something managable, and finally tune the API so it returns as much of the data in one hit as possible vs requiring multiple hits for common functionality

    Granted, I suspect the scale of the problem here is that the Tube shifts more people every hour than some countries entire rail systems so it's not a little problem.

    If they are attempting to dynamically fill every request rather than using agressive caching then whoever designed this needs a pat on the head

    0 0
  11. Anonymous Coward
    Anonymous Coward

    one word....

    BitTorrent. they seed one copy and drop a delta update every n-seconds. problem solved.

    send my fee to .....

    0 0
This topic is closed for new posts.