NOTE: iContact Labs articles are written specifically for Designers, Software Developers and Engineers, and may contain industry terms not typically used outside of the industry. If you have any inquiries pertaining to this article, please contact the author for more information.
This post is part of a series. Read the first two articles Hunting for Database Hotspots, Part 1, Hunting for Database Hotspots, Part 2, and Hunting for Database Hotspots, Part 3, if you missed them.
Written By:
David Rasch, iContact Chief Architect
Sometimes we get tied into specific requirements, rather than leveraging some agility and creativity to determine what’s really needed. Often by using this creativity, we can improve performance, reduce load on our database and users understand that perfect data isn’t always available.
A great example of approximate data shows up when you do any search through your favorite search engine. Both the number of search results and the number of pages are approximations. Sometimes you’ll find as you switch from page 3 of search results to page 4, the search engine finds there aren’t actually any more results to show. Alternatively, as you page through the results, the number of pages can decrease. In both of these cases, the performance and accuracy of the information is tuned to the needs of the users.
Data shows that more than 50% of users only click on the first search result after conducting their search. Under 10% of users voyage beyond the first page of search results. To more than 90% of users, the many pages of results beyond the first are irrelevant. Search engines have realized this and prioritized the computation of these values.
At iContact, we just had an instance where we decided to change the user experience a bit to improve performance, however I doubt our users will ever notice. When you click the “Create” tab inside our application, we designed it so that if you had yet to create a message, we would hide the “Re-use a sent message” link. The challenge was that this created a relatively expensive query that demanded a temp table and filesort. When we went to optimize the query, we realized a few things:
- The only people who wouldn’t see the link are people who just created their account.
- We incur the cost of checking for this message to load an otherwise static page mainly used for navigation.
- The cost to run the query gets more expensive the more messages you send, and less valuable.
We decided to make the link show up all the time. This eliminated the query on one of the most common pages loaded in our application. It’s reduced page generation time by 100s of milliseconds on average.
What are ways you can get creative with your application to alleviate database hotspots?
- Can data be approximated?
- Can you update less frequently, perhaps even probabilistically?
- Can you stop showing the data at all?
- Can you email the data to the user so you have more time to process it?
What other suggestions do you have for changing application logic to create speedier applications? Any case studies out there?
Feel free to provide us with your experiences and feedback in the comments section below.
