WP-ShortStat Slowing Down Root Index Pages

Published Tuesday, July 17, 2007 @ 8:27 am • 4 Responses

[ Keywords: wp-shortstat, shortstat, wordpress, plugin, slow, country, ip, lookup, root, index, fix ]

For over a year now, I have been using Markus Kämmerer’s (Happy Arts Blog) WP-ShortStat plugin for WordPress. The plugin is relatively well-maintained and remains one of my favorite admin tools. Great for popping in on stats without logging into Mint. Nonetheless, due to its IP/country-detection functionality, WP-ShortStat has experienced its share of difficulties (e.g., read through the change log on the plugin’s home page). In this article, I describe how WP-Shortstat slows down the root index-page of a site, and then suggest a (temporary) fix for the issue.

The Issue

I have heard of several different WP-ShortStat problems resulting from the country-lookup feature, including missing statistics, broken pages, and pages not loading (due to slowness of lookup server, etc.). Too many problems for something I really never look at anyway. The new (for me, anyway) issue with WP-ShortStat involves an extremely slow (or even non-loading) root index-page of any site running WordPress installed in a subdirectory. I experienced this problem under the following conditions at the exact same time and on three different blogs:

  1. WordPress installed in a subdirectory (not root)
  2. Running Markus Kämmerer’s WP-ShortStat plugin (version 1.7h)

The problem is that, all of sudden, and for no apparent reason (i.e., no changes had been made), the index.php files located in the root directory (i.e., outside of the WordPress installation directory) stopped loading. Well, okay, they would load, if you let them spin for long enough (average load time: ~3.33 minutes!), which is the same as not loading at all given the average visitor’s attention span. The bizarre thing is that every other page on the sites loaded normally (ha!). Indeed, all pages within the blog itself continued to load quick, fast, and in a hurry, but for some reason, the root index.php page would not. Here is a summary of the symptoms:

  1. Suddenly, the site’s root index.php page will not load (or will load very slowly)
  2. Meanwhile, all other site pages continue to load normally and without problems

The Solution

Granted, most of my traffic is routed directly to internal pages (thankfully, only a fraction of total views are for the root page), so it is doubtful that many visitors noticed the problem before I could solve the issue. At first, I had NO idea why the root page — and ONLY the root page — would not load. Total stumper. Eventually, after a few rounds of the plugin-elimination game, the culprit was revealed! Disabling the WP-ShortStat plugin completely resolved the issue.

And that was just fine as a temporary fix, but I wanted to continue using the WP-ShortStat plugin — I just wasn’t ready to say goodbye (sniff). So, after some research1, trial and error, it became clear that the offending aspect of the plugin involved that incredibly uninteresting IP/country-lookup feature. Nice — I never used it anyway!

Thus, I decided to hack the plugin, solve the problem, and keep WP-ShortStat running tuf. Fortunately, the fix is a snap. Crack open the plugin file, scroll down to around line #21, and locate the following:

function determineCountry($ip) {
		
		$coinfo = @file('http://whois.happyarts.net/ip2country.php?ip=' . $ip);
		$country = trim($coinfo[0]);
        
		if($country == '(Private Address) (XX)' 
		|| $country == '(Unknown Country?) (XX)'
		|| $country == '' 
		|| !$country 
		  )return 'Indeterminable';
			
		return $country;

}

Now, simply comment out the first two variable declarations, $coinfo and $country like so:

function determineCountry($ip) {
		
		// $coinfo = @file('http://whois.happyarts.net/ip2country.php?ip=' . $ip);
		// $country = trim($coinfo[0]);
        
		if($country == '(Private Address) (XX)' 
		|| $country == '(Unknown Country?) (XX)'
		|| $country == '' 
		|| !$country 
		  )return 'Indeterminable';
			
		return $country;

}

..and that should do it. Upload, test, and enjoy. If you were experiencing the issue described above — or any similar issue (pages not loading, slow server response, etc.) — this fix should definitely solve the problem. Sure, you won’t enjoy those nifty country IP lookup data, but you will eliminate all third-party server issues and other related problems.

If this hack worked for you, I would love to hear about it. Or, if you have encountered similar problems, or found a different solution to this or a related issue, please leave a comment and share your wisdom!

References


Dialogue

4 Responses Jump to comment form

1Markus Kaemmerer

July 25, 2007 at 12:07 am

You should have updated to a newer version of WP-ShortStat. This had fixed the problem,too. The old version you are using (before 6. December 06) we used an HTTP based country detection service. This was slowing down our webserver to much. We switched of this service for months now (you can read it on http://blog.happyarts.de/wp-shortstat) and use UDP now. This is much faster for all users and our server can handle hundres of pings per second without problems.

2Perishable

July 25, 2007 at 12:43 am

I was wondering if this would get your attention.. ;) Thanks for clarifying the issue, although I am still confused as to why the slowness only affects the root index in cases where WordPress is installed in a subdirectory. It seems that the problem would affect every page, unless another factor was involved. Either way it’s cool. I tested version 1.12a on another site and everything is running fine. Thanks for the great plugin by the way — it is definitely one of my favorites!

3drmike

July 30, 2007 at 11:13 am

First lookup maybe? Cached afterwards with teh object cache?

4Perishable

July 30, 2007 at 6:22 pm

Perhaps..
How would that be checked/verified?
I mean, just for fun..

Subscribe to comments on this post


Share your thoughts..

TopRead official comment policy

Contact Perishable Press

  • Contact Jeff via form

Search Perishable Press

About Perishable Press

Perishable Press is the virtual playground of Jeff Starr — visionary, founder and lead developer of Monzilla Media, a small web and graphic design company in the lush desert oasis of Moses Lake, Washington. Perishable Press features articles and tutorials on many aspects of digital design..

Read more..

Perishable on Twitter

automation is great: i've got photoshop batch processing 300+ images while FTP is simultaneously uploading them to the server..

Perishable on Tumblr

Tons of Firewalls

Tuesday, 7 October 2008, 1:45 am

Recently overheard on conservative talk radio (instructing listeners how to obtain a free promotional video from their new website):

“This website has tons and tons of firewalls, so you have to use your real email address to download the video..”

The Quiet Search Revolution

Monday, 6 October 2008, 12:15 pm

Just a thought.. As awesome as Google is these days, it would suck if they ended up owning the entire search-engine business. When they get to the point where all competition is impossible (due to their sheer size, financial resources, media influence, etc.), how many alternate search engines will have the resources for continuous improvement and top-quality search results? When this happens, we will have no choice but to do exactly what Google tells us to do.

As deeply ingrained as it is for everyone to instinctively and unthinkingly turn to Google for their search activity, it is time to leave a few alternate search tabs open for as much use as possible. Instead of using Google just because that’s what you always do, try your search on MSN, Yahoo, Ask, or any of the other independent search engines instead. Sharing traffic with other search engines is a nice, quiet way to keep the competitive spirit alive and well in the search-engine business.

Disappearing WordPress Posts

Wednesday, 1 October 2008, 7:50 pm

Today I experienced difficulties while trying to publish or even save new posts in WordPress. I would compose the post as usual, add all of the keywords, tags, meta tags, and so on, but as soon as I clicked the “Publish” or “Save” button, the post would just disappear from existence.

The weird thing is that during the drafting process, WordPress’ default auto-save feature showed that the post had been saved at expected intervals. Unfortunately, after trying to publish several different posts, WordPress showed absolutely no record of the posts ever being created. They simply vanished into thin air.

Fortunately, a little investigation revealed the culprit. If you should find yourself dealing with this same issue, here are some different things that you should try. First, re-upload fresh copies of your entire WordPress installation. I don’t know why exactly, but apparently various files can either go stale or completely disappear from the server. Overwriting or writing fresh files may do the trick.

If that doesn’t work, check your WordPress database for errors. In my case, a little investigation revealed that something had caused a couple of fatal errors in the wp_posts table. Fortunately, checking and repairing the table solved the issue.

Tumblr Battles

Wednesday, 1 October 2008, 5:30 pm

Please excuse the duplicate Tumbr posts.. seems there is no way to ping Tumblr to refresh/rebuild the RSS feed according to changes in post content. So, to resolve the issue I have discussed now like two or three times regarding paragraph elements and proper feed formatting, I have no choice but to repost a majority of my text posts.

This is necessary for the proper import and display of my Tumblr feed into WordPress. Currently, there are five items displayed at once, each styled according to proper inclusion of paragraph tags. Thus, whenever the Tumblr feed “forgets” to enclose single-paragraph posts with the proper tags, the result is an unstyled post entry displayed on my site.

Assuming that makes sense, you will please excuse my dust while I repost a few older entries in an attempt to reconstruct (the hard way) a properly formatted Tumblr feed.

More Optimization Measures

Wednesday, 1 October 2008, 5:27 pm

Another important step in improving the performance of my recent redesign involves the optimization of both CSS and JavaScript content. During development there were around 15 server requests for these two types of files, 10 JavaScript files and 5 CSS files. This was okay for my own use, but would not work for production purposes.

Optimizing these file types involves consolidation, compression, and caching. Consolidation of 10 JavaScript files into three is huge improvement. Now I deliver one JS file for the functionality of the site, one for Mint, and another for Analytics. Likewise for the stylesheets; after consolidation, a single stylesheet is delivered to all modern browsers. There are two additional stylesheets as well, but they are targeted at IE6 and mobile browsers and will not load elsewhere.

Once the files were consolidated as much as possible, it was time to optimize or “crunch” them. Using the sexy Flumpcakes CSS optimizer, I was able to reduce my stylesheets by around 25%. Likewise for JavaScript, I used xtreeme.com’s optimizer to shave an additional 20% off the size of my JS content.

Finally, once I had consolidated and compressed my JS and CSS files as much as possible, I wanted to further my optimization efforts by ensuring that these files were cached by the browser. By setting far-future Expires headers for everything but the statistical files, my site gains an additional performance boost by eliminating the need to reload preexisting content.

Read more on Tumblr..

Subscribe to Comments Recent Dialogue

  • Adam Singer: Thanks for this. You're right, if it isn't broken, don't fix it. I was about to update my permalinks and install a plugin to redire...
  • Marilyn: It looks great on my browser! I wish I had that much creativity in my head! It's gorgeous!...
  • Randy: "Too girly?" It looks like a great design. Define "too girly!"...
  • Christopher Ross: .htaccess based redirects are wonderful. I'm always baffled by web professionals who don't take the time to learn more about them....
  • federico: Hi Jeff... tnx so much...it worked perfectly... c u Federico...
  • Cooltad: The skin seems (mostly) fine in my expert opinion. Your one of the few people able to make a design with a transparent table and a b...
  • Neal: The free Intro to Linux book is a great place to start http://www.ischool.utexas.edu/mirrors/LDP/LDP/intro-linux/html/index.html ...
  • Louis: @Jeff: Your “Archives” page is slick, although I would expect a cleaner implementation from such a vehement advoc...
  • Jeremy: Well I think that you may be over-critical, I don't see a darn thing wrong with it - I like it a lot!...
  • Jeff Starr: Alright, this is exactly the kind of information I was hoping to get. Lots of great ideas and recommendations here. I will be reading...

Read more recent comments..