When data is retrieved from the database, we store the info in memory so that we don’t have to ask the database the same question over and over again. Most cache last for about 10 to 30 minutes, then the cache expires, and we query the database again (with exceptions). What ended up happening is that right when the cache expires, there happen to be many people access the same web page (in this case, the store), and if 50 people access that page, we query the database 50 times with the same request. Now the database is running slower, and next came another 50 people, asking the same question. Before you know it, the database is bogged down with 100 identical requests.
What I needed to do was to write a new caching layer which detect when a cache is about to expire, then before it expires, ask one user to fetch the information, and refresh the memory with the new data. This way we will never have more than one identical request happening, and the cache technically never expires and causes slowdowns.
Hopefully we won’t come across another performance issue in the near future. But I’m sure there will be another emergency right around the corner!
While I’m here, I should make a note of the recent bug fixes:
Guild vice captains can now leave the guild on their own accord
Private messaging flood control fixed
Android app now back in the Google Play store, GCash payment finally fixed
Convention page is back
Captcha on journal commenting is fixed
Boku payment exploit fixed
I’ve been busy spending the rest of my time writing new inventory backend to support additional storage containers. Soon you can have many different folders or containers to organize your inventory with. Sorting and filtering options will soon follow.
Lionheart is finally finished with the economy project! Still lots of bugs to fix as we test the feature, hopefully we can have it released in two weeks!
