I am currently working with a PHP-based shopping cart on a client’s website. The cart, as a whole, is fantastic. It’s fully featured with load of options and configuration modules. It supports nearly every conceivable payment option and has built-in controls for defining a site’s appearance.
The problem with it is, it’s slow. Depending on the web server’s load, I have measured it taking upwards of 1.6 minutes to render a single page inside the cart. On off-peak hours, the pages render on average of 4 seconds each.
Upon investigation, I believe I’ve found the culprit.
During the course of my debugging various problems, I have spoken with the cart maker’s tech support and gleaned some interesting information. One quote in particular stuck in my mind:
Yes, we’re aware the cart can be a bit on the slow side. As we grew the code and added every feature we can think of, it became rather… large. If you can find a way to speed everything up, we’d really appreciate that.
This is a typical problem of what’s known as bloatware. This is where very possible feature is added without true regard to what everyone is needing. The issue at hand is how the code was implemented.
This particular cart presents the site developers with a very full API for implementing the cart’s code. How do you inherit the code and make it available to your script? That’s very simple. With the following line at the top of your PHP page:
This looks very easy, yes? Correct. The drawback to this is, it’s too easy.
The cart I’m working with (sorry, but I don’t feel like pointing fingers) requires that one line and you get every feature available in their API, ranging from SSL, PEAR, RSA, AJAX, cache, email, wish list, database, HTML forms, and cookie features. The list goes on and on. In fact, that one required include statement moves through a list and then includes a grand total of 317 files. Those are only the ones reported back to the internal debugger. Yes, it has that, too.
Let’s say you just want to display how many items you have in the shopping cart. How is it displayed? Simple, by making a call to ShoppingCartProductsQuantity(). Continue the assumption, though. Perhaps that’s all you want displayed on a certain page? It’s still that single function call and you still have the availability of the hundreds of other calls at your disposal.
It appears some people have gotten the idea that computers are fast enough that we can throw whatever we want at them. We don’t have to think carefully about what we’re writing, because the computer will handle it anyway. That’s completely untrue, especially when writing code for the web.
Unless you have a dedicated host to server your web pages, you are sharing the machine with several other clients all at the same time. Some of the citizens of the web server are great. They make sure their code is fully patched with current versions and there is nothing errant running around. The web server population also has miscreants or those who just aren’t attentive to their code. I have seen web farms put up notices that some of their machines are being taken offline to remove some “bad code”. Some of the inhabitants were running old code that had been hacked and had unknowingly launched a DDOS against a target.
While there is no way we, as developers in our own space, can protect the server against what someone else is doing, there are techniques we can use to make our code more responsive.
Thus comes in part of this article’s title: micro or macro?
I recently explained the way the shopping cart was working and how I would suggest it be designed.
Imagine you are handed an encyclopedia. Someone asks you, “Give me the definition of ‘dog’.” You would flip through the encyclopedia, find dog, write down the results, and hand it over.
Now, imagine you were handed a large stack of flash cards. Someone asks you, “Give me the definition of ‘dog’.” You would flip through the cards, locate the “dog” card, extract it, write down the answer, and hand it over.
See the difference? This shopping cart is the “encyclopedia.” You always have every definition available even if you aren’t using them. This is macrocode: a piece of code written from the perspective of the whole code body.
A much better way would be to design the “flash card”. Or, write it as microcode: designing the code from inside the whole code body.
Instead of a single line providing your program with every possible option, break things apart. Perhaps you only need the above mentioned “how many items in a cart?” Great. Put the following line in your code:
The “CartContents.php” could be an API into only items inside the current cart. Sure, that API could then inherit other items such as SSL or database, but it most likely wouldn’t need access to email or HTML forms functions.
As your code needs more features, include that piece of the library to expand what it has available. Don’t just assume that you always have everything all at the same time. If you do, then you’re just bloating your code.