As you all probably already know, z-trening data is kept in a (mysql) database.
Until few days ago, whenever a page was loaded, all the data was obtained from the database - every time multiple queries would be run to get user info, solved problems, task info, etc... etc...
As you can imagine this is not very efficient. Calling mysql every time means you have to run a mysql query on a database that is stored on a hard drive.
So, few days ago, I've started using cache support. More specifically, each of the two z-training web servers share 1GB of their RAM for cache. Now, instead of calling mysql you call the cache service and get the results A LOT faster!
The obvious problem here is clearing the cache! every time the database is updated, the cache has to be cleared (when user solves a problem, his info cache has to be cleared (or updated) And when implementing this, I've probably missed a lot of places where the clearing should be done. So please report this cases, and I will fix them soon.
Now, having cache also helps the following thing a lot:
For example we want to get the last 100 submissions, or 10 fastest submissions. If we use mysql, we can do this in the following two ways.
1. We can write a complicated query that will get 100 submissions from the submissions database, and connect it with user database to get the user info, and again connect it with the task database to get the task info. This approach requires writing a complicated query (but that is not the biggest problem) we also have to worry about creating indexes on the database so that the query runs fast. And finally, if we want to restructure any of the databases, we have to be careful not to break any of the complicated queries over there!
2. We can do the following thing:
- get 100 submissions from the submission database.
- for each submission get all user info from user database, and all task info from the task database.
This is obviously really bad, we would have to call mysql 200 times! for just one page - and that will take a lot of time, and overload our database server.
Now, most websites use the first approach, and when their servers get overloaded, they buy more servers.
However, z-trening is poor, so we have to do something else.
For that we use the approach similar to the second one described above. But instead getting all the info from mysql, we first try to get it from cache. As you can imagine, the data is not changing very often, so most of the time we will have the data in cache. To be more accurate, currently z-trening has 99% cache hits, which means that only 1% of the time the data has to be obtained from the database. Which makes this approach a LOT faster then both approaches above - so the two z-trening servers can support a lot of users at the same time.
This was very important for the chat. Each user that has open chat sends a request to z-trening every 1 or 2 seconds for chat updates. This means that if there are 100 users using the chat at the same time (that's 50 users per server), each server gets 50 requests per second. That means that the server has at most 20 milliseconds to respond, and in that case will have 100% load. The bigger problem would be the mysql server that would get at least 100 requests per second (or possibly more - we want to get the chat details, user data.. ).
Using caching for this makes it possible for z-trening to have a chat. the chat requests are processed in on average 2 milliseconds! that means z-trening can support 1000 users using the chat!
Until few days ago, whenever a page was loaded, all the data was obtained from the database - every time multiple queries would be run to get user info, solved problems, task info, etc... etc...
As you can imagine this is not very efficient. Calling mysql every time means you have to run a mysql query on a database that is stored on a hard drive.
So, few days ago, I've started using cache support. More specifically, each of the two z-training web servers share 1GB of their RAM for cache. Now, instead of calling mysql you call the cache service and get the results A LOT faster!
The obvious problem here is clearing the cache! every time the database is updated, the cache has to be cleared (when user solves a problem, his info cache has to be cleared (or updated) And when implementing this, I've probably missed a lot of places where the clearing should be done. So please report this cases, and I will fix them soon.
Now, having cache also helps the following thing a lot:
For example we want to get the last 100 submissions, or 10 fastest submissions. If we use mysql, we can do this in the following two ways.
1. We can write a complicated query that will get 100 submissions from the submissions database, and connect it with user database to get the user info, and again connect it with the task database to get the task info. This approach requires writing a complicated query (but that is not the biggest problem) we also have to worry about creating indexes on the database so that the query runs fast. And finally, if we want to restructure any of the databases, we have to be careful not to break any of the complicated queries over there!
2. We can do the following thing:
- get 100 submissions from the submission database.
- for each submission get all user info from user database, and all task info from the task database.
This is obviously really bad, we would have to call mysql 200 times! for just one page - and that will take a lot of time, and overload our database server.
Now, most websites use the first approach, and when their servers get overloaded, they buy more servers.
However, z-trening is poor, so we have to do something else.
For that we use the approach similar to the second one described above. But instead getting all the info from mysql, we first try to get it from cache. As you can imagine, the data is not changing very often, so most of the time we will have the data in cache. To be more accurate, currently z-trening has 99% cache hits, which means that only 1% of the time the data has to be obtained from the database. Which makes this approach a LOT faster then both approaches above - so the two z-trening servers can support a lot of users at the same time.
This was very important for the chat. Each user that has open chat sends a request to z-trening every 1 or 2 seconds for chat updates. This means that if there are 100 users using the chat at the same time (that's 50 users per server), each server gets 50 requests per second. That means that the server has at most 20 milliseconds to respond, and in that case will have 100% load. The bigger problem would be the mysql server that would get at least 100 requests per second (or possibly more - we want to get the chat details, user data.. ).
Using caching for this makes it possible for z-trening to have a chat. the chat requests are processed in on average 2 milliseconds! that means z-trening can support 1000 users using the chat!