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
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
http://plugins.trac.wordpress.org/changeset/431873/wp-slimstat/trunk/wp-slimstat.php?old=466649&old_path=wp-slimstat%2Ftrunk%2Fwp-slimstat.php
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
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.
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
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
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!
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.
