31–40 of 46 posts
It was a great article but this sentence had me a bit confused: "Well, a typical machine at the end of 2012 has 24 GB of memory, you’ll need an overhead of 4-5 GB for the OS, another couple, at least, to handle requests, and a tweet id is 8 bytes." My Desktop has like 40 chrome processes, is running GeoServer on Tomcat (currently idle, but whatever), and the entire Unity desktop environment. I'm currently at 2.7GB. W…
God, I wish I'd known this sooner.
> Implement backpressure throughout your system. This is perhaps a point one cannot get to theoretically just sort of thinking about. This realization comes after observing the effects in practice. It is interesting to observe distributed systems, especially the ones that rely on asynchronous messages, thing go wrong and queues start filling up. Or even weirder machines start to synchronize for some reason. Like the…
If I synchronously hit some service then I need to build facilities into the service to say that it's too heavily loaded, and perhaps handle those responses on the client.
If I pop some job onto a message queue or asynchronous endpoint, things will just slow down for a while. Which is normally as good a way as any as soaking up load.
> Implement backpressure throughout your system. This is perhaps a point one cannot get to theoretically just sort of thinking about. This realization comes after observing the effects in practice. It is interesting to observe distributed systems, especially the ones that rely on asynchronous messages, thing go wrong and queues start filling up. Or even weirder machines start to synchronize for some reason. Like the…
I view this the opposite way around. Message queues and asynchronicity are an alternative to backpressure as described. If I synchronously hit some service then I need to build facilities into the service to say that it's too heavily loaded, and perhaps handle those responses on the client. If I pop some job onto a message queue or asynchronous endpoint, things will just slow down for a while. Which is normally as go…
There's a growing area where I see a lot of people starting to get involved with distributed system who didn't have to deal with it before: rich in-browser apps with their own permanent storage. Once you have a Javascript application with state speaking over one or more APIs to your backend services, you're in the domain of distributed system design. Especially if you use the application cache and support offline ope…
curious question: how do you get people to even click "ALLOW" when the popup says "do you want to allow this website to use localStorage"
I wrote up some notes on this, though they're about a year old now and the browser UIs continue to evolve: http://tech-blog.clericare.com/2012/02/choosing-right-browse...
For someone building a consumer web app that needs to painlessly convert users in volume, I can see where it would still be a pain. For me, it's not so bad -- my app is B2B, and having an install step as simple as clicking "Allow this app to use up to 500MB on your computer?" is actually a huge improvement over the "enterprise" junk we compete with.
> Implement backpressure throughout your system. This is perhaps a point one cannot get to theoretically just sort of thinking about. This realization comes after observing the effects in practice. It is interesting to observe distributed systems, especially the ones that rely on asynchronous messages, thing go wrong and queues start filling up. Or even weirder machines start to synchronize for some reason. Like the…
I view this the opposite way around. Message queues and asynchronicity are an alternative to backpressure as described. If I synchronously hit some service then I need to build facilities into the service to say that it's too heavily loaded, and perhaps handle those responses on the client. If I pop some job onto a message queue or asynchronous endpoint, things will just slow down for a while. Which is normally as go…
> If I synchronously hit some service then I need to build facilities into the service to say that it's too heavily loaded, and perhaps handle those responses on the client.
Most of the time, you have to have timeouts when there is a synchronous API across the network.
In a large system ideally you'd want to reflect the level of loading back to the input source so the source can slow down sending the data. Think of TCP, tcp works this way on a small scale. One way to fix the problem is to leverage that to actually open a TCP stream and send data that way. The sender will slow down accordingly.
Now if you know that your load is not constant, so there are periods of high activity when inputs are generated then you can try and absorb (and amortize) those high volume peaks using asynchronous queues.
[1] [http://techblog.netflix.com/2012/07/chaos-monkey-released-in...]
It was a great article but this sentence had me a bit confused: "Well, a typical machine at the end of 2012 has 24 GB of memory, you’ll need an overhead of 4-5 GB for the OS, another couple, at least, to handle requests, and a tweet id is 8 bytes." My Desktop has like 40 chrome processes, is running GeoServer on Tomcat (currently idle, but whatever), and the entire Unity desktop environment. I'm currently at 2.7GB. W…
One that has buffers.
there are only 2 problems in computer science. 0. naming things 1. cache invalidation 2. off-by-one errors