Live data from Hacker News

Scaling lessons learned at Dropbox (2012)

eranki.tumblr.com

11–20 of 32 posts

Re: Scaling lessons learned at Dropbox (2012)

#11
post #5
post #4

This may be from 2012, but it's surprising just how much of the specific advice still applies. Grep, sed, awk, xargs etc are still the canonical list of shell tools for debugging, and have been for decades. Makes you realise, learning Unix tools will likely be a better long term time investment than the latest trendy framework. I wish I could go back in time and tell that to my younger self...

Couldn't agree more! When I am forced to use a Windows environment I find myself reaching out to these evergreen tools in many situations and is frustrated by having to find workarounds to these tools that should be ubiquitous tools in any OS. Everything I learned almost 30 years ago still holds true today when it comes to the basics. And yes I know of Cygwin, MKS toolkit etc, but trying to convince corporate IT in a…

Sometimes nothing beats grep, but using a Windows environment I usually just go to Python to create a quick script to handle this stuff.

Lots of times it is really nice to have all your "debugging scripts" in a repo anyway. Once you have that it isn't hard to set up a basic Python environment and have your scripts there.

Re: Scaling lessons learned at Dropbox (2012)

#12
post #8

"One technique we repeatedly used was creating artificial extra load in the live site. For example, we would do a lot more memcached reads than necessary. Then when memcached broke, we could quickly switch off the duplicate queries and have time to come up with a solution." As much as I want to hate this, it's actually genius and elegant in its simplicity.

I do something similar with disk usage. Create a dummy file with XX GB and delete it when you are running out of space

Re: Scaling lessons learned at Dropbox (2012)

#13
post #4

This may be from 2012, but it's surprising just how much of the specific advice still applies. Grep, sed, awk, xargs etc are still the canonical list of shell tools for debugging, and have been for decades. Makes you realise, learning Unix tools will likely be a better long term time investment than the latest trendy framework. I wish I could go back in time and tell that to my younger self...

What are some outstanding resources to learn from?

https://www.oreilly.com/library/view/unix-power-tools/059600...

I used this a great deal, when I first started out on serious UNIX tasks (1996+)

Re: Scaling lessons learned at Dropbox (2012)

#14
post #8

"One technique we repeatedly used was creating artificial extra load in the live site. For example, we would do a lot more memcached reads than necessary. Then when memcached broke, we could quickly switch off the duplicate queries and have time to come up with a solution." As much as I want to hate this, it's actually genius and elegant in its simplicity.

Are load tests not a standard thing people do any more?

Re: Scaling lessons learned at Dropbox (2012)

#15
post #14
post #8

"One technique we repeatedly used was creating artificial extra load in the live site. For example, we would do a lot more memcached reads than necessary. Then when memcached broke, we could quickly switch off the duplicate queries and have time to come up with a solution." As much as I want to hate this, it's actually genius and elegant in its simplicity.

Are load tests not a standard thing people do any more?

When unexpected load causes a production outage, it's often something you wouldn't have predicted using a load test.

Re: Scaling lessons learned at Dropbox (2012)

#16
post #4

This may be from 2012, but it's surprising just how much of the specific advice still applies. Grep, sed, awk, xargs etc are still the canonical list of shell tools for debugging, and have been for decades. Makes you realise, learning Unix tools will likely be a better long term time investment than the latest trendy framework. I wish I could go back in time and tell that to my younger self...

This is a fun read on the topic: https://adamdrake.com/command-line-tools-can-be-235x-faster-...

Re: Scaling lessons learned at Dropbox (2012)

#18
post #5
post #4

This may be from 2012, but it's surprising just how much of the specific advice still applies. Grep, sed, awk, xargs etc are still the canonical list of shell tools for debugging, and have been for decades. Makes you realise, learning Unix tools will likely be a better long term time investment than the latest trendy framework. I wish I could go back in time and tell that to my younger self...

Couldn't agree more! When I am forced to use a Windows environment I find myself reaching out to these evergreen tools in many situations and is frustrated by having to find workarounds to these tools that should be ubiquitous tools in any OS. Everything I learned almost 30 years ago still holds true today when it comes to the basics. And yes I know of Cygwin, MKS toolkit etc, but trying to convince corporate IT in a…

Eh, forcing people to use Windows in big corps is such PITA :(

Re: Scaling lessons learned at Dropbox (2012)

#19
post #4

This may be from 2012, but it's surprising just how much of the specific advice still applies. Grep, sed, awk, xargs etc are still the canonical list of shell tools for debugging, and have been for decades. Makes you realise, learning Unix tools will likely be a better long term time investment than the latest trendy framework. I wish I could go back in time and tell that to my younger self...

What are some outstanding resources to learn from?

I liked the Missing Semester by MIT. It provides a first principle style for learning some of the foundational tools. https://www.youtube.com/playlist?list=PLyzOVJj3bHQuloKGG59rS....

Re: Scaling lessons learned at Dropbox (2012)

#20
post #8

"One technique we repeatedly used was creating artificial extra load in the live site. For example, we would do a lot more memcached reads than necessary. Then when memcached broke, we could quickly switch off the duplicate queries and have time to come up with a solution." As much as I want to hate this, it's actually genius and elegant in its simplicity.

I do something similar with disk usage. Create a dummy file with XX GB and delete it when you are running out of space

IIRC ext4 does this already. Saved me a couple of times.
Post reply on HN