Posted 6 months ago #
Since updating from 2.5 to 2.5.1 there has been a 50% increase in latency for page loads. Deleting 2.5.1 and re-installing 2.5 solves the problem.
Post load-times are typically 1.5 seconds on my server with 2.5 and below. They go up to around 2.3 seconds when 2.5.1 is installed and active.
Have you done something? :)
Posted 6 months ago #
wp-slimstat.js may be the source of degradation. It runs at each page load. I found this in the load time report by testing my domain with http://tools.pingdom.com
My site shows an ~3sec increase. I'm ok with this for now but am considering StatPressV as a replacement.
Posted 6 months ago #
I just ran a test with gtmetrix.com (great site, btw).
Anyway, with SlimStat installed or uninstalled, the page load times were roughly the same. However, SlimStat caused a three-point reduction in my Google PageSpeed score.
The PageSpeed score went back up three points when I set "Enable JS Tracking" to No. I probably don't need that anyway, since Google Analytics covers what that covers, I think. (Let me know what I'm missing. :) )
Thank you Steve,
I've tried to be as careful as possible in optimizing the code to reduce the overhead added by my plugin. GTMetrix penalizes your site, I think, because the javascript is not compressed. That is something I could not do on my end because most hosting providers do not support this feature (gzip). But once the javascript is cached by the browser, it will not be downloaded every time the user loads a new page.
Best,
Camu
Posted 6 months ago #
Camu,
In my case, if the JavaScript is enqueued, the "Better WordPress Minify" plugin gzips it. It not enqueued, .htaccess deflate gzips it. I double-checked and this is all working.
What I think is the issue for PageSpeed is that this JavaScript isn't enqueued, and thus the minify plugin can't combine it with other JavaScript. Thus, it is seen as one extra resource to load, and PageSpeed likes these minimized.
Would it be possible to enqueue the JavaScript, or is this not possible by design?
Thanks,
Steve
Good point, I hadn't thought about that! Maybe because old versions of WordPress (which I'm not supporting anymore, anyway!) didn't have that functionality. Added to my todo list.
Cheers,
Camu
Done :) Version 2.5.2 enqueues the script per your suggestion. Please let me know if this is how you wanted the plugin to work!
Camu
Posted 6 months ago #
That did the trick! Thanks! Now, I have another suggestion, but I'll start a new thread for that.
Cheers!
Steve
Cool, as you can see I'm always open to new ideas to improve my plugin.
PS: a vote for WP SlimStat would be a nice way to say thank you!
Posted 6 months ago #
Already has a 5-star rating from me. You have a great plugin there.
Thank you, sir :D
Posted 3 months ago #
wow, nice tip steve :} ur suggestion helped improved it, now i can worry less about using slimstats.
WP SlimStat 2.7 will further improve this mechanism by optimizing the script.
Posted 3 months ago #
wow :d sounds good.
Thanks
Posted 3 months ago #
Unfortunately the original issue is still unresolved.
From WP Slimstat 2.5.1 to 2.6 there is still a 30-50% impact on page load times than with all versions prior to 2.5.1. This occurs on a WP3.3 setup or prior WP version. Whereas WP Slimstat 2.5 works fine on WP3.3 and prior.
As awoz stated above, it may be an issue with the tracker, as when a filtered user views the same pages, the impact on load time disappears (as it does when WP Slimstat is deactivated).
Also, WP Slimstat V2.6 browscap.php line 230 is causing errors in the server logs whenever it is called (i.e. on every page view)
"[30-Jan-2012 13:45:29] PHP Warning: touch() [function.touch]: Utime failed: Operation not permitted in /usr/home/../../wp-content/plugins/wp-slimstat/browscap.php on line 230"
PHP V5.2.12. This may be a file permission issue. (The install instructions for WP Slimstat have been followed).
Let me address the error first: this happens because either you or your provider have configured permissions too strict, which don't allow browscap to update its cache. There's an easy fix, though: just set the Autoupdate DB option to no.
As for the performance issue, I can't replicate the issue on my local and production environments. The overhead observed with 2.5 is about 15% (from 0.35 to 0.4 seconds on duechiacchiere.it, my blog) and about 20% with 2.6. Not sure about what is happening on your server. Can you share your server's specs (ram, php, MySQL, etc)? Also are you using myisam or innodb? And how many records are we talking about. My tests are based on a table with about 450k records.
Camu
Posted 3 months ago #
what is myisam or innodb ? and which is better ?
i'm using mysql with phpymadmin :X
If you don't know the difference, you don't have anything to worry about, wp slimstat will choose the best setup for your server environment :)
@Maduro-blanco, as you can see, not much changed in the way the tracking engine works between 2.5 and 2.5.2
Except for the InnoDB support. Not sure if that may be impacting your blog's perfomance.
That's why I'm confused by your statements.
Camu
Posted 3 months ago #
The increase in load times of 30%+ is only for slimstat after 2.5. Only occurs when slimstat is actively tracking. Data size is 13Mb. Standard server setup. I can only repeat that it was fine with slimstat 2.5 and prior. Latency increase appeared in 2.5.1 and after. I would compare 2.5 with 2.5.1+ results to see if you notice any difference. It may just be down to one of those impenetrable software mysteries. Would be good if others could compare page load results between the two versions as well, and we'd have more to go on.
Maduro, as I said in my previous message, I compared load times of 2.5 with the ones of 2.5.2 (which is, as you say, "2.5.1 and after"). Anyway, I'm almost ready to release 2.7, which should bring the overhead down quite a bit.
Camu.
Posted 2 months ago #
It seems that (on my host anyway) each time Slimstat is updated the folder/file permissions of the browscap cache folder are reset to unwritable. This produces the server log error reported above and may, somehow, be the cause of the overhead when Slimstat is tracking. Either way, it would be a good idea to mention this in the installation instructions: that the cache folder permissions might need to be reset to writable after updating.
Maduro,
this is because every time you upgrade a plugin, WordPress removes the existing folder and creates a new one with the new files in it.
As for the performance, have you noticed any improvements after upgrading to 2.7?
Camu
Posted 2 months ago #
Now moved up to 2.8. But there is still an issue with browscap and the cache folder somehow. The problem surfaces when Browscap autoupdate DB is activated (with the cache folder permissions set to writable). At first nothing seems to be amiss, then a few hours or a day or so later all page loads get jammed and take over a minute to load up! This only happens when the tracking is active, and is solved by simply switching off the browscap autoupdate DB. However, if you are logged in as admin or editor (or whatever) and have set slimstat to ignore (switch off tracking for) those users, you will never notice the problem. Meanwhile, all your visitors will be waiting around for over a minute for the website to load in their browsers. Very odd...
You may want to confirm with your provider that they are not blocking curl, file_open and similar functions when they attempt to access external resources. I have Wp SlimStat running on various websites on different hosting providers and the autoupdate works just fine.
Also, if disabling this feature solves the issue in your case, you
can just update that file manually once in a while ;)
Camu
Posted 1 week ago #
I just ran into an issue with the cache folder as well.
While I was adding my site to subversion, this folder was left owned by root and missing the cache files. It took me a while to track down as the symptoms were thousands of open database connections and an unresponsive server. Upon closer inspection the server was also using a ton of bandwidth - here is a link that indicates the issue (my site typically does 3000+ visits a day so this is a big increase): http://i.imgur.com/QUz1Q.png
I took a look at the browscap.ini and it's 490kb so that would explain it. Maybe the code could check to see if the cache folder is writeable before trying to download the files? Maybe an email considering the apparent seriousness?
Good point, indeed. I'm planning to work on this part as soon as I'm done with the updates I'm working on for 2.8.1. The third-party library I'm using doesn't seem to be "smart" enough to check if the folder is writeable, so I'd like to replace it with some code that leverages the built-in WordPress Filesystem:
http://ottopress.com/2011/tutorial-using-the-wp_filesystem/
Sorry about the inconvenience, and thank you for pointing this out.
PS: a vote for my plugin would be a nice way to encourage me to keep it up!
Posted 1 week ago #
so it wouldn't let me start a new topic so I'm posting my question here:
I'm using the demo custom reports.. and I get it activated.. etc..
for some reason it doesn't work out of the box, because $this->limit_results is empty. but if I put this:
if(empty($this->limit_results)) { $this->limit_results = $GLOBALS['wp_slimstat']->options['rows_to_show']; echo "<p>limits: ".$GLOBALS['wp_slimstat']->options['rows_to_show']."</p>"; }
it sets the limit, then the query can run.. do you know why the parent::__construct() is not setting this?
thanks in advanced
Please start a NEW topic, as soon as you're allowed to.
You must log in to post.
