Yes, sir, I can boogie!

[venta]

It's Friday! It's about three o'clock! It's time to Boogie At Your Desk!

Friday afternoons need a little something. I think they need a Top Tune. Something to make you shuffle in your seat and, if possible, Boogie At Your Desk. I'll be endeavouring to fill this gap some Fridays this year.

I'm not claiming that any track provided to enable At-Desk Boogying is one of the world's best or most profound pieces of music. It will, however, be one of the tunes which make me smile, and which have at some stage made me surreptitiously Boogie At My Desk.

Desks are not compulsory, of course. Feel free to boogie through your office, in your bedroom, round your lab, across your classroom, on the train - wherever you find yourself on a Friday afternoon.

If you like the track, go out and buy the album it belongs to - I'll try and recommend a suitable CD to purchase for any BAYD track.

This link will expire when I leave work this evening. Unless broadmeadow is willing to leave it up for a bit longer, as some people tell me they like a sneaky post-work boogie of a Friday evening.

Today you were invited to Boogie At Your Desk to:

Dropkick Murphys - Heroes From Our Past


Nearly a year ago, I went to see the Dropkick Murhpys in London. Despite them being a little patchy live, it still remains (I think) the most enthusiastic gig I've ever been to.

Ideal for a bit of at-desk boogying, I think.

And if nothing else, you can all have a good giggle at the idea of someone singing, in a punk-stylee, "When we think back to our ancestors respectfully we hark...". Woah, yeah, man, it's anarchy! Smash the system, but with due respect to the ancestors.

I only own one Dropkick Murphys CD, which is Sing Loud, Sing Proud!. And if you want seven slightly drunken blokes (plus bagpipes) cheerfully yelling their way through the occasional traditional (mostly Irish) folk song, and some original compositions (including the remarkably good The New American Way), then you want this CD.

I certainly wouldn't unconditionally recommend this band, CD, or indeed track. It's easy to have too much of them, and I'm sure some people will loathe them on hearing. But for a bit of simple, singalong fun, they're a damn good bet. I prescribe buying an album, then occasionally plonking a couple of tracks onto a late-night driving compilation.

Comments

Re: And better yet!

[broadmeadow.livejournal.com]

This also happens with ISP et-al own caches, of course - so often you'd see this effect anyway.

Re: And better yet!

[wimble.livejournal.com]

Depending on their expectations: my server is my home PC, so NTL don't provide a machine to cache my content (it being in the opposite direction to their normal traffic).

And venta's hosting seems to apply a 5Kb/s limit, shared amongst all the clients. So a 75 fold upgrade, with no client limits "might not be an entirely unwelcome" thing (which will require venta to start downloading the file her self at about 2.45, in order to get it into the cache...

Re: And better yet!

[broadmeadow.livejournal.com]

I was thinking of the case where people access your server and _their_ ISP caches the content. It should be the case, for example, that no many how many people here at Tao accessed the file it was only downloaded from PlusNet to Tao once.

For this same reason, getting a faster throughput when you access a slow server on the second transfer (which is what I was referring to, but didn't make clear) might be expected anyway: on the first transfer the data is (slowly) downloaded from the host site and cached by your ISP; on the second you are simply retrieving it from your ISP's cache.

Re: And better yet!

[wimble.livejournal.com]

Ah. Of course: that didn't occur to me. Brookes doesn't run a web cache, on the grounds that, for the most part, 15000 users hitting the internet (mostly) at random doesn't make it economically viable. So my changes weren't due to a local cache.

The CoralCDN cache is still worthwhile, as it'll serve N ISP proxies, rather than each ISP having to fetch their own copy from the source server.

Re: And better yet!

[onebyone.livejournal.com]

15000 users hitting the internet (mostly) at random doesn't make it economically viable

Ooh, now you've got me thinking about viable strategies for a smallish cheapish cache in such an environment (e.g, only cache once the frequency of hits to a particular URL passes a certain threshold across a certain time, discard cached objects according to the product of their size and frequency of hits, and some kind of load monitoring so that you can just bypass the cache when its load tops out).

Re: And better yet!

[wimble.livejournal.com]

Does that really work? If you only cache once the frequency of hits crosses a threshold, you run the risk that you're going to put it in the cache at the moment when nobody else is going to be interested (and you've just missed a number of interested users).

'course, I haven't thought about it any further than that, so I dunno...

Re: And better yet!

[onebyone.livejournal.com]

Yes, you're going to run that risk, but you can do a likelihood estimate (either statically when configuring the cache, or dynamically whenever the cache feels like it) which looks at whether we reckon there's going to be another hit by considering what usually happens when URLs get hit particular numbers of times.

For example, if it's incredibly common for pages (or pages on a particular site) to be hit exactly 27 times per day, then don't set the threshold (for that site) to "27 in one day". 12 is looking good, though.

If the distribution is quite smooth, then it probably doesn't matter that sometimes you'll cache at the wrong moment, because usually you won't. Just pick the value that would have given the most hits on average based on your past traffic - the good thing about having 15000 people acting randomly is the Central Limit Theorem.

I'm also guessing that the cache operation itself is quite cheap except for the opportunity cost it incurs by pushing something else out. So if you get even one hit on an object during its life in the cache (i.e. before it expires or is pushed out), then you probably win. The question then is how to get the number of wins above the point where it's worth the price of the server.

I'm sure all these issues are quite thoroughly studied, though, because the trivial cache strategy "save everything and discard the oldest" has its own problems, namely that large rare downloads will keep emptying your entire cache but then not getting hit.