Is caching important with MongoDB, as with MySQL?

Question

I am writing a C # HTTP request server for my web game and I am using MongoDB for the database. How much more efficient is it to cache everything I can in a C # application? Or faster to execute a MongoDB request for each thing. I expect about a dozen requests to choose per minute for each active player and, possibly, one or two save / update requests per minute.

Answer 1

"A dozen requests per minute per player for each active player" tells us nothing. To have any relation, we need to know the number of active players, the amount of time that each request takes, the table structure, the requests used (including the amount of returned data), server load statistics and others, how do you use the ability of Mongo to outline the database, etc. d.

Regardless, before setting up any type of caching, I highly recommend starting with system profiling. You need to know where your bottlenecks are, if they exist at all. This is not something you can guess, you need hard and real statistics.

With this information you can determine if you need

• make small corrections for your code
• implement some type of caching strategy
• Reach a database server on multiple servers
• backchitect large code snippets
• scaling (purchase of large servers)
• or even fix internal network problems.

Point, don’t start caching things in the hope of getting better performance later. Caching is as likely to increase performance as it kills it, depending on a huge number of factors.

---

One more thing to add here. If you use a web farm to host your query server, the complexity and hardware costs associated with caching data locally on each independent web server increase dramatically.

Hardware costs are increasing due to increased memory requirements on your web server (s) when you try to store data in a cache in memory on these machines.

Difficulty increases when you try to keep synchronized copies in caches so that they do not become obsolete. I would suggest that the game requires information that is 100% current. Sites like facebook and others may allow themselves to be slightly out of sync. When a game server crashes, it can adversely affect usability.

Assuming you are currently deploying only one web server and one database server, adding caching capabilities can now be a huge pain for you if you go to multiple web servers and / or multiple db servers.

Finally, if for some reason you deploy to only one computer that hosts both the database and the web server, caching is completely ridiculous.

Answer 2

I would say, regardless of the database, caching that rarely modifies data on the server is better than making many database calls. Anything that can come from the web server directly through the wire, and not to call the database, and then to send over the wire is good. If these dozens of select queries return the same data, it is best to cache them.

Answer 3

There is something to consider: when your game is small, your database will probably be on the same machine, and the database itself will perform its own caching. Later, if your game is popular, you will have many web servers, and it would be better to use distributed caching, such as memcached, if you intend to use overall memory efficiency.