Clarification of disk usage requirements, resource usage & phoning home?

Dear Scott,

thank you for bringing your concerns to our attention.

You are correct about the disk usage issue: the third party library we use, Browscap, has grown over time from a mere 2.5 MB file to a total of 20 MB over five files. We will update the requirements accordingly to reflect this change, it is a honest mistake on our end. It should read 25 Mb, just to stay on the safe side.

Regarding your other concern, you are once again correct about the ambiguity of that setting, and we will implement a fix in our next update to address this situation. However this configuration only works when it is set to YES (please take a look at the source code), so you can rest assured that we are playing by the rules.

As for the server load, isn’t in the nature of any WordPress plugin to slightly increase the amount of work the server will do to complete the actions and filters which that plugin hooks into? The tracker has been designed and coded to be as little resource intensive as possible, and according to our tests, it only requires about 5-10 MB or RAM (to load the Browscap dataset first, and the MaxMind dataset to geolocate the IP then). It performs 6 MySQL queries on average, to retrieve a post’s categories, a user’s information, the visit ID, the plugin’s settings and ultimately to store all the information about a pageview. Being most of them “read” queries, they don’t lock the table they interact with. Also, please note that the plugin can work in “Javascript Mode”, which defers all the actions to after the page has been served to the visitor, thus eliminating any performance issue during the request itself.

However, long story short, we can add a disclaimer that clarifies that this plugin will slightly increase your server load to perform its duties. Again, to me it sounds like those warnings to not put your cat into the drier or the microwave, but I guess they’re there for a reason after all.

Database size: Slimstat includes an option to do a periodic purge of the data in wp_slim_stats, either by archiving it into a separate table (which is never used by the plugin to generate its reports) or just deleting it. This way users can customize the plugin’s behavior to fit their needs. This option used to be set to 120 days, but then users started pointing out that they had lost data over time, not being aware of this setting. For this reason we now deactivate this feature by default, and let the user enable it as needed. It seems quite self-explanatory to me that if the plugin is recording information about pageviews, it will have to store that information somewhere, and that it will grow over time.

Hosting providers allowing Slimstat: we’re only aware of two or three web hosting providers which don’t allow Slimstat among a long list of WordPress plugins; however we haven’t seen such a disclaimer on those other plugins’ pages, so we never thought of adding one to Slimstat.

Again, thank you for taking some time to review these issues, which we are more than happy to address and fix.

Best,
Camu

PS: please feel free to close this topic, if you think your concerns have been addressed in a satisfactory way.

Hi Camu,

Thanks for getting back to me so quickly, and for the clarification and detailed response.

Regarding my questions on the disk size and phoning home issue, that sounds good, and I appreciate the clarification. Everything is good there.

One of the things we’ve had to learn to do over the years is improve how we communicate things to less technical users (often clients fall into this category), because they just might not be familiar with these issues, and then they get surprised by certain things. They want to run a site with the power of Amazon.com on a low-end shared hosting account, and we have to inform them why that can’t happen. ?? By adding the clarification to the docs that I recommended, it will definitely help with that.

Just to give you a little background…we do a lot of site optimization for clients, so we do a lot of benchmarking and timing of database issues, including individual query times, and how these change as the DB grows or is reduced in size. We then track how these can affect site speed. We’ve also done a lot of interacting with web hosts to get feedback and get their insight into these issues, as well as managing our own web hosting server for clients for several years.

I’m definitely more technical as I’ve been doing web development for almost 20 years, and am a plugin developer as well. ?? The sheer size of the plugin when unpacked (when compared to the 5MB in the docs) and the question about phoning home were initially a bit disconcerting for me. The bandwidth and server load issue I expected though, as it’s something common to all stats or database heavy applications. (In no way is your plugin out of the norm compared to other plugins of this genre.) And we have used this plugin in the past although it was several years ago, and I expect it’s been through major evolutions since then, so we’re looking at it fresh. So, clarification on the first two things will help both technical and non-technical users, and clarification on the third will help more non-technical users.

Regarding the performance issue…its not that anything coded wrong in the plugin, its just that it is a stats plugin, which doing a lot of work, and you can’t ask a plugin to do so much without expecting some increased server load. Just like you with cars can’t expect to get the power of a V12 supercar without sacrificing some fuel economy.

I know you have done a lot of work to optimize the speed and improve efficiency so kudos to you on that.

I agree about all WordPress plugins slightly increasing server load, but this is more than slightly my friend. ?? Unfortunately a lot of go-to plugins that people use for testing this (such as P3) don’t accurate gauge the overall impact on a site.

Where this comes into play isn’t necessarily on the front end with individual page’s load speed but rather on the overall server load, which has a subsequent effect on the site’s performance and load speed. Some examples of how this has an overall effect on the site’s performance:

• When server load is increased, it can affect time to first bite, thus affecting the page load speed of other pages that are not directly related to the current operation.
• It negates much of the efficiency improvement provided by caching plugins. Normally you can use a caching plugin to serve static html pages via an .htaccess rewrite and reduce server load significantly, both by not accessing the DB at all but also by not having PHP run on each page load. If caching plugins are used, even with your JavaScript mode on, it will still need to run PHP and access the database on each page load, which will contribute to a consistently higher overall server load. JavaScript running in the browser can’t write to a DB directly so you still need PHP to do this. (Servers have limits to the number of PHP operations that can be done at once.) While using caching will improve things, when a plugin is still accessing PHP and the DB, it will be far less of an improvement than if they were not, and there will still be a significant increase in server load.
• The larger the DB gets, the longer each individual query takes. Just to give an example – and this won’t apply to all users – when you have 1000 users on a site at once, extra milliseconds can turn into extra seconds. Scalability becomes an issue. With more powerful servers this is less of an issue, but with cheap shared hosting servers that are overcrowded, this dramatically affects a site. Giving users a heads up that they should not use it on weak servers would be helpful. Even with the database purging and maintenance, the DB size will increase significantly. This increase in size in turn affects the query time of all other unrelated DB calls, including WordPress Core and plugin DB calls.
• The other seemingly unrelated, but significant issue is just the sheer size of the included files. When you have over 20 MB, that is no small task for the server to simply read all the data, let alone process it. This will also affect the server load and speed of the site as a whole. For this point alone I would almost say it should be run exclusively on hosts with SSD drives. If you can find a way to trim down the browscap library, or use a lighter version by default and give users an option to upgrade to the full version of browscap from within the plugin (like you have them click to download the GeoLite DB) along with a heads up on increased resource requirement, that might help. In my experience it doesn’t take an overly huge DB to accurately detect all browser and OS variations. We used to use browscap on sites (more than 5 years ago) and even at its smaller size we tracked noticeable increase on server load and overall effect on site performance.

Keep in mind the plugin is called “Slim” Stats, so people will automatically assume it’s super lightweight. Educating users will help give people realistic expectations.

Also, site optimization and speed become bigger issues each day for WordPress users, especially with site load speed affecting search engine rankings now (and therefore a site’s revenue). And it’s not just search engine rankings at stake for site owners…it’s revenue. Amazon did a study that showed that for every 1/10 second their site slowed down, they lost 1% in sales.

If you provided some minimum server requirements and then some recommended server specs (or even recommended web hosts), that would be amazing.

Regarding the web hosts banning it, I’ve personally seen 3 or 4 (possibly 5) that have banned it (along with most stats plugins so its not just this plugin…stats functionality requires a lot of resources). Not necessarily that I agree with them. I think banning plugins and blaming them is a bit ridiculous, and is a smoke screen for weak servers and limits people’s freedom. I just think being up front is important and people will appreciate it.

It’s just something people need to be aware of. Again…not saying they shouldn’t use it…it’s a 5 star plugin and that’s why I’d take the time to share my thoughts on this.

Thanks!

– Scott

Wow Scott,

I wish all our users were as wordy (in a positive way!) as you are. Thank you for taking a good chunk of your time to elaborate on all these issues.

I will try to summarize some key points:

– Perfomance: we offer a premium add-on that allows users to define a separate DATABASE where to store all the information collected by our plugin. This extension was designed as a solution to the performance issues you highlight in your message. By using a separate database, most of the problems are gone because this way the database used by WordPress is not impacted at all.

– Disk/Memory Usage: like I said, we will add some more information to the requirements and on our website, to clarify how much disk space is needed, and how data grows over time.

– Caching Plugins: yes, Slimstat might negate the benefits of such plugins, however please keep in mind that you could install our plugin on a separate server and just add the tracking code to your cached website, just like you would do with Google Analytics. Again, this would solve all the performance issues at the cost of using another server to keep track of your traffic.

– Most of what you point out could be summarized with the well-known way of saying “no pain, no gain” ??

– We don’t feel like recommending web hostings, as our users are all over the world, and it would not be fair to just promote a handful of providers. Our experience is not this vast to allow us to be experts in that field.

Cheers,
Camu

Hi Camu,

It’s no problem. ??

Thanks for the additional info you provided.

I really like the idea of the separate database in order to not impact WordPress. Excellent.

Also, installing it on a separate server and using the JS tracking code like Google Analytics is excellent. I had no idea you could do either of these things with the plugin.

Please brag about these features more prominently in your documentation. ?? Maybe even have a section that is prominently displayed on how to get maximum speed/performance with the plugin and talk about these advanced/premium features. Not sure how you want to word it but something to that effect may be good.

Totally agree about no pain no gain. Sometimes it just helps to remind users of that. ??

No problem about not recommending particular hosts. But having some recommended server specs may be good, so people can make sure they get something robust enough to perform well. Just thoughts though.

Overall, great explanations and solutions, and thanks for taking the time to clarify these things. It’s much appreciated. Keep up the excellent work!

– Scott

Hi Scott,

if you haven’t already, a review for Slimstat would be a great way to say thank you ??

Cheers,
Camu

Hi Camu,

Absolutely. We’ll be happy to. Have a good one!

– Scott

Here you go ??

https://slimstat.freshdesk.com/support/solutions/articles/5000650166-what-are-slimstat-s-minimum-requirements-and-optimization-strategies-

Nicely done, Camu!

Now you just have to brag about these features more! ??