3 ms·

People surprised by the 100 days requirement have presumably never seen the type of infrastructure required by a top-100 website or had to deal with user-time i

by ig1 13y ago

People surprised by the 100 days requirement have presumably never seen the type of infrastructure required by a top-100 website or had to deal with user-time issues. Having an independent clock means turning off caching, which is a big deal when you're serving millions of page requests. Not to mention having to deal with timezone issues, daylight saving, latency, etc. This stuff is hard.

mcgoooo 13y ago
i agree, i've actually worked at the bbc and the infrastructure that goes into these things is unbelievable and necessary.
- rasur 13y ago
  same here. It's absolutely not a couple of servers and a bit of node, kids!
  - brador 13y ago
    Then what is it?
    - rasur 13y ago
      Well, I haven't worked there since about 2006, so numbers may have changed, but it was at least 10000 servers of various types (redhat, solaris, windows were the usual suspects I had to build out) of which I was aware (between maidenhead, the various colo's i had some responsibility for, tv center, white-city). software? i know there was a lot of perl, ruby was gaining some traction, a few different CMS's.. etc, i've (thankfully) forgotten most of the details, but diverse ecosystem is an appropriate phrase here. undoubtedly things have changed between then and now, but i'd guess it's something similar hardware-wise. My penultimate day of work was racking up ~300 servers for the i-player farm (i was a system engineer) at red-bus in docklands. My back has only really just started to recover. :/
adrinavarro 13y ago
I just hope they're not going to get rid of caching, but instead, implement a time server and sync through JS, or something alike.
relix 13y ago
Just add some javascript to load the time from a different server after the cached version is rendered. Build a simple service in node.js, ruby or java to return a json datetime, use that as the endpoint to load the time from. This is not rocket science and should not take 3 months to build, even with all the caching involved. Edit: I just checked the headers that are sent along with any request to bbc.co.uk, and the response already includes the current datetime. So basically they don't even need to implement a time server anymore, but just do an Ajax request to document.location, and read the Date header on the result, to get the accurate time. They can just upscale their servers a bit to handle the extra requests (or implement an empty-response URL). Why would this take 100 days again? Edit2: Sample code here: https://news.ycombinator.com/item?id=5825319 https://news.ycombinator.com/item?id=5825319
- JonnieCache 13y ago
  This is the BBC, not some startup in a garage with a couple of EC2 instances. It's the busiest website in europe, and it's publicly funded. If they just threw up external node services whenever they felt like it there would be chaos. For example, whenever there's a major news story they see traffic spikes that would make you weep. Internally on the other hand, where the stakes aren't so high, they make heavy use of rails, node, go and all that cool stuff. They know what they're doing. Check out this list of some of their machines, from part of their monitoring system which is for some reason left open: http://support.bbc.co.uk/support/rrd http://support.bbc.co.uk/support/rrd Here's is some data about their peering: http://support.bbc.co.uk/support/peering/ http://support.bbc.co.uk/support/peering/ Yeah that's right. Peering. EDIT: you're right that they could probably implement this quite easily, but the point is they can't just throw up an agile solution at the scale of the BBC, even if it seems safe.
  - relix 13y ago
    The point is that this could be solved by a solution that is completely external to their current infrastructure, meaning they don't even have to mess with any integration or legacy code. Agile in this case seems perfectly suitable because they can easily have a fallback when the server doesn't respond to a "time"-request, that falls back to the current state (i.e. use client-side time). So we've got the perfect storm of no integration with current systems, tiny overhead on requests (it's basically an ECHO server), unimportant feature and easy fallback. In fact I have an enterprise plan to sell them that does exactly this if they would like to externalise this problem.
webjunkie 13y ago
" timezone issues, daylight saving, latency, etc" Didn't it say "time in the UK"?
- dalore 13y ago
  We do have daylight savings so timezones do change.
  - antihero 13y ago
    It literally just has to be an ajax call that spits out a bit of JSON with the current time on the server. Set server to Europe/London and switch on NTP and bam, done.
  - webjunkie 13y ago
    uh, no. Applying DST or not does not change the time zone I am in.
    - dalore 13y ago
      In Britain, British Summer Time is considered a different timezone.

by ig1 13y ago

mcgoooo 13y ago

i agree, i've actually worked at the bbc and the infrastructure that goes into these things is unbelievable and necessary.

rasur 13y ago
same here. It's absolutely not a couple of servers and a bit of node, kids!
- brador 13y ago
  Then what is it?
  - rasur 13y ago
    Well, I haven't worked there since about 2006, so numbers may have changed, but it was at least 10000 servers of various types (redhat, solaris, windows were the usual suspects I had to build out) of which I was aware (between maidenhead, the various colo's i had some responsibility for, tv center, white-city). software? i know there was a lot of perl, ruby was gaining some traction, a few different CMS's.. etc, i've (thankfully) forgotten most of the details, but diverse ecosystem is an appropriate phrase here. undoubtedly things have changed between then and now, but i'd guess it's something similar hardware-wise. My penultimate day of work was racking up ~300 servers for the i-player farm (i was a system engineer) at red-bus in docklands. My back has only really just started to recover. :/

adrinavarro 13y ago

I just hope they're not going to get rid of caching, but instead, implement a time server and sync through JS, or something alike.

relix 13y ago

Just add some javascript to load the time from a different server after the cached version is rendered. Build a simple service in node.js, ruby or java to return a json datetime, use that as the endpoint to load the time from. This is not rocket science and should not take 3 months to build, even with all the caching involved. Edit: I just checked the headers that are sent along with any request to bbc.co.uk, and the response already includes the current datetime. So basically they don't even need to implement a time server anymore, but just do an Ajax request to document.location, and read the Date header on the result, to get the accurate time. They can just upscale their servers a bit to handle the extra requests (or implement an empty-response URL). Why would this take 100 days again? Edit2: Sample code here: https://news.ycombinator.com/item?id=5825319 https://news.ycombinator.com/item?id=5825319

JonnieCache 13y ago
This is the BBC, not some startup in a garage with a couple of EC2 instances. It's the busiest website in europe, and it's publicly funded. If they just threw up external node services whenever they felt like it there would be chaos. For example, whenever there's a major news story they see traffic spikes that would make you weep. Internally on the other hand, where the stakes aren't so high, they make heavy use of rails, node, go and all that cool stuff. They know what they're doing. Check out this list of some of their machines, from part of their monitoring system which is for some reason left open: http://support.bbc.co.uk/support/rrd http://support.bbc.co.uk/support/rrd Here's is some data about their peering: http://support.bbc.co.uk/support/peering/ http://support.bbc.co.uk/support/peering/ Yeah that's right. Peering. EDIT: you're right that they could probably implement this quite easily, but the point is they can't just throw up an agile solution at the scale of the BBC, even if it seems safe.
- relix 13y ago
  The point is that this could be solved by a solution that is completely external to their current infrastructure, meaning they don't even have to mess with any integration or legacy code. Agile in this case seems perfectly suitable because they can easily have a fallback when the server doesn't respond to a "time"-request, that falls back to the current state (i.e. use client-side time). So we've got the perfect storm of no integration with current systems, tiny overhead on requests (it's basically an ECHO server), unimportant feature and easy fallback. In fact I have an enterprise plan to sell them that does exactly this if they would like to externalise this problem.

webjunkie 13y ago

" timezone issues, daylight saving, latency, etc" Didn't it say "time in the UK"?

dalore 13y ago
We do have daylight savings so timezones do change.
- antihero 13y ago
  It literally just has to be an ajax call that spits out a bit of JSON with the current time on the server. Set server to Europe/London and switch on NTP and bam, done.
- webjunkie 13y ago
  uh, no. Applying DST or not does not change the time zone I am in.
  - dalore 13y ago
    In Britain, British Summer Time is considered a different timezone.