Found 4 results for scalability
Le Cloud Blog
~ INSIDE A CLOUD COMPUTING STARTUP ~
10 notes &
Scalability for Dummies - Part 4: Asynchronism
This 4th part of the series starts with a picture: please imagine that you want to buy bread at your favorite bakery. So you go into the bakery, ask for a bread, but there is no bread there! Instead, you are asked to come back in 2 hours when your ordered bread is ready. That’s annoying, isn’t it?
To avoid such a “please wait a while” - situation, asynchronism needs to be done. And what’s good for a bakery, is maybe also good for your web service or web app.
11 notes &
Scalability for Dummies - Part 3: Cache
After following Part 2 of this series, you now have a scalable database solution. You have no fear of storing terabytes anymore and the world is looking fine. But just for you. Your users still have to suffer under slow page requests when a lot of data is fetched from the database. The solution is the implementation of a cache.
8 notes &
Scalability for Dummies - Part 2: Database
After following Part 1 of this series, your servers can now horizontally scale and you can already serve thousands of concurrent requests. But somewhere down the road your application gets slower and slower and finally breaks down. The reason: your database. It’s MySQL, isn’t it?
Latest now, the required changes are more radical than just adding more cloned servers and may even require some boldness. In the end, you can choose from 2 paths:
12 notes &
Scalability for Dummies - Part 1: Clones
Just recently I was asked what it would take to make a web service massively scalable. My answer was lengthy and maybe it is also for other people interesting. So I share it with you here in my blog and split it into parts to make it easier to read. New parts are released on a regular basis. Have fun and your comments are always welcomed!
The other parts of the series “Scalability for Dummies” you can (soon) find here.
Part 1 - Clones
Public servers of a scalable web service are hidden behind a load balancer. This load balancer evenly distributes load (requests from your users) onto your group/cluster of application servers. That means that if, for example, user Steve interacts with your service, he may be served at his first request by server 2, then with his second request by server 9 and then maybe again by server 2 on his third request.
