Too many maps? Not a bad problem to have. (Read 3007 times)

Every so often, instead of working on adding new features, I would re-architect the code. What this means is moving things around so that they would make more sense conceptually. It's akin to reorganizing the fridge so that the perishables are closer to the front, while freeing up room so you can put more stuff into it. The end result is that the software becomes easier to maintain while allowing me to add new features with less effort. Back in August of last year, I did a code reorganization to create more automation in the code. One of the things I added during that time was better error handling. As much as I tried, it is nearly impossible to create bug free code. This bit of code will handle any error condition that I didn't anticipate. Occasionally, you would receive a message saying that an error has occurred and the administrator has been notified. Instead of requiring you to report the error to me, the software will tell me when something needs fixing. For every error that occurred, I get an email. It contains details that may help me figure out the problem. After installing this piece of code, I get about an email a week. Most of the time, I can figure out what's wrong pretty quickly and put out a fix. In the last month or so, I received thousands of these emails, all caused by the same problem. Before you lose confidence in me, let me explain. The problem occurred in the show maps page, but I don't know what was causing it. I haven't uploaded any new changes for a couple of months before the problem started occurring. I traced through the code and everything worked properly. In the mean time, the emails kept piling up. Trent posted a support request tonight and so I went and did another investigation. The clue was the maps took "FOREVER" to come up. I looked at the code that fetches the maps from the database and it seemed ok. I ran a query against the database and asked it to describe how it went about retrieving the database and that didn't reveal anything glaringly wrong. When I queried the database directly for maps, it took "a while" (81 seconds) to return the results. To help the database do its job more efficiently, I have to tell it to sort the data in a certain way. For example, the phone book is sorted by last names. If you want to find everyone whose first name is "Bob", you have no choice but to go through each phone book entry and find the name manually. Obviously, this is a painfully slow process. It turned out that one of the data fields in the database wasn't sorted. The database was in effect going through the maps one by one! The solution was to tell the database to sort the data so that it can search faster. It took several minutes to complete. As I waited, I remembered that I really shouldn't be doing this kind of work so late in the night. If something goes wrong, I'd be up all night long fixing it. Fortunately, everything went smoothly. The map searching page is working properly once again. It went from taking 81 seconds to look for maps to less than a second. Whew! Going back to the error emails... the error was caused by the database taking too long and the web server decided to abandon the request. When that happens, you won't get any maps back as you panned around. If I don't get any error emails tomorrow, then I will know that the problem is fixed. Why did this problem surfaced only recently? As everyone creates more maps, it takes the database longer to search through them. There are so many maps on the server now that it has to do more work to find the ones you're looking for. The problem was caused by too many maps. As my friend says, it's not a bad problem to have.

Thanks for sharing! It's an interesting narrative, how these problems creep up as your user volume increases...

Will there be a limit on the amount of maps or are we all good?

How geeky do you want the explanation? You probably know this since you run your own database driven web sites. I forgot to index a column in the maps table, which caused the slow down. With indexing, the search time went from O(n) to log(n). In pseudo non-geek term, if there are 10,000 maps in the system, it went from taking 10,000 units of time to see if a map should be displayed, it now takes log(10,000), which is 4 units of time to do the same thing. Theoretically, the search function will slow down enough to be noticeable eventually, but it will take some 10^10,000 maps to do so. If I have that many maps, you can be sure that I'll have enough resources by then to deal with it so it won't be a problem either.

waterfordrider, I'll consider this request when I redo the log, which I hope will be some time this year.