* on my machine xargs -I implies -L1, so you can drop that
* use gnuplot -p or the graphic will disappear immediately after renderingScaling lessons learned at Dropbox, part 1
61–70 of 92 posts
Re: Scaling lessons learned at Dropbox, part 1
#62Great article! Small nitpick from someone who just tried this on his server logs :) * on my machine xargs -I implies -L1, so you can drop that * use gnuplot -p or the graphic will disappear immediately after rendering
A sort -n is also required before the uniq since server logs have the time of the request but are printed when the response is complete so they're not necessarily increasing.
Re: Scaling lessons learned at Dropbox, part 1
#63The idea of running extra load - it sounds good in theory but I can't help thinking that it's a bit like setting your watch forwards to try and stop being late for things. Eventually you know your watch is 5 minutes fast so start compensating for it. I wonder if this strategy starts to have the same effect - putting fixes off because you know you can pull the extra load before it becomes critical. In the same way you…
This is just an adaption of the "margin" system commonly used in systems engineering. Basically you never spec everything out to perfectly match the load it's expected to bare, always leave some headroom. For example if you are designing an aircraft your first design is never perfect. So you when you do the initial design, you do it as if the aircraft has to weight 70% of what it really will. As errors are corrected…
OP's "extra reads" is dumb because he could have had normal metrics for memcached load and planned to only support like 70% capacity or somesuch, and when load hit that number, he would immediately increase capacity. Instead he's running with a handicap. It's just useless.
Re: Scaling lessons learned at Dropbox, part 1
#64:)
I've never seen a shorter description of real-world software development. That's it in a nutshell!
Re: Scaling lessons learned at Dropbox, part 1
#65Earlier quoted context omitted.
Probably most of their logging _is_ meaningful, but deciding how to professionally phrase each and every log message will eventually get you to decision fatigue. The point that he was making with this was that over-logging is a good thing - this probably wasn't something the initial author thought was going to be terribly informative, hence the random string. And yet it ended up diagnosing a real world problem. In a…
I don't know how many new logging statements you commit to production code every day, but I can't imagine it averages out to more than one or two. If you can't take the time to phrase them both professionally and meaningfully then you're doing yourself and your team a disservice.
"FUUUCK" is awfully good at conveying the seriousness of the error, and "aslfkhsdf37" ensures that the string is unique, so you can pinpoint it instantly in your gigantic codebase.
The fact is, it kind of works. Something like "missing record (line 38)" doesn't indicate the severity, there might be 10 different "missing record" error strings in your codebase, and somehow in real life, line numbers and filenames never seem to quite match up like they should (transcompilation, async callbacks, and so on.)
Re: Scaling lessons learned at Dropbox, part 1
#66but I really hate ORM’s and this was just a giant nuisance to deal with I like object relational mapping as a theory (ie. I have an object of type Author which has 1 or more books I can loop over), but I hate ActiveRecord implementations. Eventually, they just end up implementing almost all of SQL but in some arcane bullshit syntax or sequence of method calls that you have to spend a bunch of time learning. I also se…
There are only two hard things in Computer Science:
cache invalidation and naming things.
-- Phil KarltonRe: Scaling lessons learned at Dropbox, part 1
#67Re: Scaling lessons learned at Dropbox, part 1
#68Great post, but this part scares me a bit... I think a lot of services (even banks!) have serious security problems and seem to be able to weather a small PR storm. So figure it out if it really is important to you (are you worth hacking? do you actually care if you’re hacked? is it worth the engineering or product cost?) before you go and lock down everything. Just because you can "afford" to be hacked, doesn't mean…
Re: Scaling lessons learned at Dropbox, part 1
#69I wish he'd left the security advice out. The whole post was excellent, but all the useful points will now be overshadowed by the armchair quarterbacking about security by people who mostly don't understand that ALL security is a compromise, and it is as important to understand and make deliberate decisions about your security as it is to try to make a secure system in the first place.
I'm glad he put the security notes in. It is so hard to get true facts about how things are actually done.
Re: Scaling lessons learned at Dropbox, part 1
#70Earlier quoted context omitted.
This is just an adaption of the "margin" system commonly used in systems engineering. Basically you never spec everything out to perfectly match the load it's expected to bare, always leave some headroom. For example if you are designing an aircraft your first design is never perfect. So you when you do the initial design, you do it as if the aircraft has to weight 70% of what it really will. As errors are corrected…
Can you imagine if they loaded 1000lbs of lead onto an airplane before they took off, just to see if the plane takes off with the headroom filled? "Oh crap, the plane is falling, let's dump the lead." OP's "extra reads" is dumb because he could have had normal metrics for memcached load and planned to only support like 70% capacity or somesuch, and when load hit that number, he would immediately increase capacity. In…