Plugins Scalability

Recently, I’ve been thinking about the state of plugins. In my previous post I’ve mentioned the free and premium plugins, and additionally I could split them in other categories, such as: small and large, self-contained and extensible, user-oriented and developer-related, optimized and non-optimized.

I could go further with secure/insecure and everything, but that’s another story. I’d also like to cover the aspect of user-oriented plugins vs. developer helpers, which is a separate topic.

Scalability

According to Wikipedia:

In electronics (including hardware, communication and software), scalability is the ability of a system, network, or process to handle a growing amount of work in a capable manner or its ability to be enlarged to accommodate that growth. (link)

In the software world, the term scalability is used for describing a piece of code and it’s capacity/speed when it comes to running it with a huge amount of data, which could be: millions (or more) database records, visitors, or gigs of bandwidth (numbers vary). Non-experienced programmers (or ones who work on low-cost projects) usually skip that part while building the architecture and designing the project. At the end – it still works for small blogs and “business card” websites with a few dozen visitors.

The problem comes when the site grows, both the number of database records and visitors is increased, and the site behaves oddly. I’ve seen a lot of enterprise companies in the Java/.NET world who solve those problems by adding more hardware. Sometimes it’s way cheaper and better for the business, especially when it comes to a huge CRM/eRP that could take months of a team’s time to improve a complex software or a library that could cause regressions, but it could be avoided here and there, and we play in a different field in the PHP/WordPress world.

WordPress Plugins

Especially when it comes to Open Source (and freely distributed software), developers often try to solve their own issues, often at the beginning of the process (before the project is released, by implementing a new feature). Whilst this is not always the case, statistically speaking the percentage of large WordPress websites is significantly low when compared to regular blogs and small websites.

[tweet https://twitter.com/scottkclark/status/412626247764570112]

There are different issues that could cause performance leaks and the database layer is one of them. One has to be proficient in all aspects of the WordPress ecosystem in order to properly evaluate all risks and bottlenecks that could bring the site down due to non-optimized code.

Few of the possible issues:

  • large and non-optimized selects fetching too much data
  • malformed or non-strategical MySQL joins
  • lack of caching
  • wrong server setup (or choice of servers etc)
  • loading scripts on the top of the site (code-wise) that could load post-load
  • loading lots of scripts/files that are not needed
  • adding code to too general hooks
  • loading large data into single variables without buffering

You might have a valid reason to implement your software against these rules (and a lot more really), but often those issues come from one of the three reasons:

  1. lack of proper understanding of the development process
  2. lack of time/cash to build that software properly
  3. the plugin would be used with small projects only

Let’s review the three aspects quickly in the WordPress.org Plugin Repository context, with some business insight within.

Lack of Development Skills

It’s no shame to build a plugin without following all the best practices. We (most of us) have all started this way, working on some small sites or blogs, building some fancy extensions to our blogs. We plan for a few pages, a hundred blog posts and a hundred visitors a day, everything works great even on a small shared hosting plan.

If you want to be a mediocre freelancer or a small agency that works on small websites and blogs that stay small all the time (or just code for fun), it could be okay. If you want to improve your skills and take the next step to development, you might consider spending more time reading some tutorials and books (or watch some videos) on performance, or learning some practices and tools for benchmarking your code and servers.

Lack of Time/Insufficient Payments

If you have experience with performance, then the lack of time or a project cost that doesn’t cover those optimizations could be the reason to build a non-optimal solution.

The good news is that you still know that your code isn’t great and could potentially fix that. The issue comes when you release a general plugin that doesn’t scale and let users with larger sites install that plugin. Their site runs slowly now.

Small Projects Only

The consequences from that are similar to the second reason. Users with larger websites can’t evaluate how large their project is, and their database/web servers is affected by your piece of code.

What could we do?

Since no one can force you to release something for free on your profile, I would suggest the following solutions to this problem. These are all considerations really. If you have no clue how to make your software scalable, spend some time learning what performance is and ways to optimize your code. If you plan on releasing a non-optimal plugin for some reason, make some notes on the plugin description page with its limitations, or don’t release it on WordPress.org if it’s really critical.

Besides, most of that is just as valid for theme authors as it is for plugin developers. I admire all plugin/theme authors who release their code for free, but we shouldn’t forget that it is available to anyone and could harm someone’s business without the proper disclaimer.

2 thoughts on “Plugins Scalability

  1. Somehow that post reads a bit like “10 common excuses for bad code” /joking.

    To get back on topic: One of the most important things I’ve learned is that micro optimization normally is worth nothing. And the same goes for reading about performance bottlenecks. XDebug and KCacheGrind will in 99% of all cases point you somewhere where you never expected the bottleneck to be. So my recommendation goes for “learn about profilers” less than “learn about performance”.

    1. Thanks for commenting Franz!

      That’s correct and profilers could help a lot. However, there are various issues (for instance, related to slow queries, bad sever setup, proper caching setup, loading heavy JS or running slow DOM queries) that some profilers can’t quite “explain”. Even if you learn how to use profilers, it’s still important to know why do functions execute slowly, and definitely try to avoid these reports in the first place by “doing it right” 🙂

Your thoughts?