What makes your web app faster? (part 2, caching)

If you are looking to boost performance of you web application, then do read part 1 of this series.

So in last part i left you after saying;

“Best way to use database is, not using it at all.”

Reading database is nothing but reading a well organised file (that is why they are persistent, duh). With use of some amazing algorithms, they are queried, read and written.

But reading a file comes with a cost in terms of cpu utilization and delay to serve those requests. This does not seem big problem when you are serving 4–5 requests per second, but as you reach something like 20–30 requests per second your database starts to show some strange behaviour in serving those requests.

Suppose you run a web app like twitter (which serves 143,199 tweets per sec and for read let's multiply that with 0.2 of 313M Monthly active users which comes close to 8964257.4M reads per sec), It is not possible to query database for every new request, so, solution to this problem is in-memory databases.

in-memory database

Server today do not have any boundaries (not literally), they have huge processing power, petabytes of petabytes of storage and some terabytes of RAM. With this amazing specs we get liberty to do a lot of operations in runtime and store a lot of things in memory.

Reading and writing to memory is faster than anything else, with this idea came concept of in-memory databases.

There are 2 major solutions for in-memory database:

1. Redis
2. Memcached

There are more but these are the famous once, and that's what i care about.

Memcached is a little part of Redis, redis is much more than a in-memory key pair database, it has powerful data types, transactions with optimistic locking, fast message channels and much more.

Twitter also uses redis, let me tell how:

1. Tweets made are stored in redis with an associated key.
2. Tweets are then pushed to users unique timeline which is also stored in redis (this could be the reason why you cannot update your tweet).
3. There are more questions like what happens to timeline when user follows another user or unfollows a user, but this is how they give you amazing response time.

So, key points to note here:

1. Anything which has a large read request but less write request can be stored in a in-memory database.
2. They can be blog, post or something like a tweet but not who liked post, comments of a post (these generally have a direct access with URL like /postid, /videoid).

If RAM is not a problem then there is no reason to not use a in-memory database.

---

Some more things that can be done on server side:

1. Choose a good server side language, because implementation to handle requests are done by those things, they handle your threads and all sorts of other stuff.
2. Choose a language that can take proper advantage of your server capabilities. That means, it should use 64 bit data bus if provided, use all 8 or 16 cpu cores if provided.
3. Here as well, you can use distributed system to form a cluster of servers use it as a load balancer.

Now, some more golden words by me:

“Not everything has to be done on server.”

Our server is stronger than ever so does our users devices, we will see how to use its power for some more performance boost with our client app in next chapter → Client App.