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.

Currently, I’m working inside a site where a previous developer made some fairly poor choices.  I’ve been adjusting code to make the frakkin thing work right.  It’s not the host.  It’s the shopping cart.

I wrote a quick test script in PHP to perform 10 tests of 4,000 database operations.  Across the tests, I get a result of about 1.6 seconds for the 4,000 operations.  I’d consider the host pretty good for that.  In fact, my own host company averages 5.4 seconds for the same test.

What’s annoying me about the cart?  The amount of time it takes to load.

Ok.  I’ve ruled out that the server is to blame.  I’ve ruled out the database is overworked.  There have been a few page loads of this cart that run up to 1.6 minutes.  It’s amazing.  Really.

I’ve contacted the cart’s vendor and their only suggestion for speeding everything up is to move web hosts.  They would gladly host the site for my customer for a measly $20/mo.  There was no mention of how to speed up the cart on a server that’s not theirs.

So…  the logic is, if the host has any sort of load on it, the cart will be slow.  Move it to a really really fast computer with nearly zero load (i.e., nobody is doing anything at all on it), then the cart should be fast enough.

Yes, that’s true.  It will.  I’m testing the cart at midnight and it is nice and fast.  During peak hours, however, it gets bogged down because of how much processing it’s doing in the background.

Did I say midnight?  Oops.  Time to log.  I’ll write some more tomorrow about how this cart was made.  For programmers, the key phrases are “macro vs micro.”

Ok.  This is a general blog for me, my company, and stuff I see going on around me in the computing environments.

This article should be entitled “who are you?”  Well, I’m the guy that runs this site.  The guy that peddles his time.  The guy that loves to write code.  I’m the geek you see peeking over the website pages, wondering why things aren’t working the way they’re supposed to.

Yes, this is one of those typical, “hey, let’s get started” posts.  It’s pretty generic and I’ll try to keep things light-hearted.  If you check back, I’d really appreciate the visitors.  If you want to hire me to write code, I’d really REALLY appreciate it.