I have been looking at a client’s Wordpress install the last few days. They have a large number of posts and page load times in general have been increasing. I installed some query logging based on the code in this article … Rails-Like SQL Query Logging in Wordpress
Checking over the logs it became obvious that queries using SQL_CALC_FOUND_ROWS are a problem. Digging through code it appears that where a limit on results is used it uses this query modifier to allow simpler coding of paging. The problem is that since the main query to grab blog posts on the blog home page or any archive page uses this, on a large blog this becomes quite inefficient.
Looking at the log after this change query times have dropped dramatically (from over 0.5 seconds and up to milliseconds). This has immediately improved performance of the blog and overall load on the server.
I am currently looking at some WP Caching API and plugins to further improve performance.
I have been posting a few bits and pieces about best practice building online stores recently, partly because I have built a huge number of stores the last few years.
Just came across this bug when using Google’s “Specific date range” search option …
Google allows a number of ways to filter via their “Show Options” link above the standard search results. Clicking “Show Options” opens a column on the left with more options including the ability to specify a date range. Notice their suggested date format (dd/m/yyyy) and the date format I am using in my example search following the suggested same date/month order. Oops!
Google is localising the suggested date format but not handling the localised input.
On the right you can see using m/dd/yy it works fine.
(And no - no different if I use yyyy instead of yy).
It has been a while since I last posted. I have been building a few online stores lately and came across this article via osCommerce Watch (Questions to Answer for the Online Shopper) that I thought was worth sharing for anyone who owns or builds online stores:
