Using one of the less expensive hosting providers and a shared hosting plan for your WP-e-Commerce site is a great way to get started. The hosting providers often have easy one-click setups that they have already been optimized for a WordPress blog. These configurations can be a convenient as a starting point for setting up your WPeC site. Not having to set up and tune your Web Server and WordPress configurations can save hours or even days worth of work.
Optimizing a server for WordPress almost always includes setting up a cache to improve the ability of your server to handle requests quickly and consistently. If you aren’t familiar with how a cache works it’s pretty simple. If the result of a computation, database request or file read might be needed later, save the result close by so that if it is needed again it both easy and fast to get.
Caching on a blog is useful because the intent is for each piece of content to be read over and over again, perhaps thousands of times. Keeping the raw data close to where the web page is created not only speeds the experience for the end-user, it helps balance the utilization of server components. This means more requests can be processed by less hardware and software.
There are lots of caches that can be configured for a WordPress site. The common types are proxy-caches, op-code caches, object (attribute-value) caching and content delivery networks (CDN). Hosting provider’s will setup whatever a combination of cache types that matches what they anticipate to be met their users needs.
There a many implementations of each cache type some are bundled with server software, some are commercial products, some are services. For example, there are probably hundreds of CDN that could be used with any given web site. If your web site is running on any type of Linux variant with Apache it could be the case that your hosting provider has preconfigured a server to APC for WordPress Caching.
APC offers two caching capabilities, op-code caching and attribute caching. Your site can be configured to use either APC capability, or both, or neither. It’s important to understand each cache capability, and how it helps your site.
Op-code caching stores pre-processed copies of your web site’s PHP source code so that pages will load very fast. I benchmarked this site with APC op-code caching enabled and disabled and WordPress loaded 20 times ( 210 vs 10 milliseconds) faster with APC op-code caching enabled. That is a huge improvement.
APC also offers attribute (object) caching. Two things about WordPress blogs that make it a perfect fit for very active attribute caching. First is that content is very rarely changed, it is added to. This means that if WordPress saves an extra copy of a piece of content it doesn’t have to worry about has the value of the attribute being changed.
Second is that under the hood, WordPress data is broken into lots of distinct, small, easy to manage, pieces of data, sometimes called objects. These pieces of data used to create web pages can come from attributes and values saved in a database, or somewhere else.
Post objects have attributes with values. User objects have attributes with values. Comment also have attributes with values. If you take a quick look at your WordPress database you will see many of these attributes and values saved in the wp_commentmeta, wp_postmeta and wp_usermeta database tables.
The core WordPress code is tuned to take advantage of attribute value (object) caching if it is available. WordPress does this by saving the attributes and their values in the object cache at the same time they are saved to, or read from, the database.
WP-e-Commerce (WPeC) is architected to take advantage of the WordPress platform and all of the performance benefits that it provides. In WPeC products are just another WordPress post type, visitors are just another meta type, and carts are just attributes attached to visitors.
How does add to cart work?
- Shopper looking at a product page clicks the add to cart button,
- WPeC get’s the shoppers cart through the WordPress API
- Product is added to the shopper’s cart
- WPeC saves the shoppers cart through the WordPress API
Shopper goes to checkout page and cart is empty! 🙁
If our server configuration includes Linux, Apache using Fast CGI and APC, and is set up to use APC for attribute value caching it is likely the case that we just got hit by the behavior in this bug report.
When your web server gets a request to serve a web page or add something to a cart the web server gives the request to one of many “workers” that are available. Each of these workers is thought to be an exact duplicate of each other. This means that any worker should be able to process any request, and the result should be the same.
But this isn’t always entirely true with regards to APC. Each worker could have its own copy of the APC cache.
How about a demo?
We installed the apc.php statistics file that comes with the APC cache on a production web server. Watch file cache information as we refresh the page.
Notice the hit/misses change, and they and go down. The other stats change also. This is because the request to serve this page is using statistics from the APC cache unique to the worker that is serving the page.
Here is what is going on…
- Worker 1 gets the request to create the product page when the users cart is empty. WPeC asks WordPress to save the empty cart. A copy of the cart is put into the database and a copy gets put into worker 1’s APC cache.
- Worker 2 gets the request to add a product to the shoppers cart. WPeC asks WordPress for the shopper’s cart. WordPress checks the APC cache first, it’s not there. WordPress gives WPeC the cart that is stored in the database.
- Worker 1 gets the request to show the checkout page. WPeC asks WordPress for the shopper’s cart. WordPress checks the APC cache first, finds the cart. But the cart is the original (empty) cart.
- WPeC tells the user nothing is in the cart.
What to do?
Easy. Don’t use APC for object ( attribute-value ) caching with WordPress. Use APC for op-code caching only.
Can object caching be turned off?
Yes. But it’s not a good idea. Without an object cache your site will slow down. The impact on user experience will be noticeable. However, If you want to you can turn off object caching entirely rename or delete the object-cache.php file in your wp_content directory.
Can I fix the APC configuration?
Perhaps. This is an article that describes what you have to do. Not for uninitiated or the faint of heart 😉
Use a different object cache (the best solution)
If your host is sophisticated enough to try to make APC available to you it’s also very likely that your host has memcached available. If so, you can switch to using memcache as your object cache by replacing the object-cache.php in your wp_content directory with an object-cache.php that sends the request to memcache rather than APC. You might want to take a look at this plugin that includes the object-cache.php you need and some installation instructions. If your host hasn’t made memcached available it’s requires some basic Linux skills to set up. Just make sure you host has given you the required permissions.
Is there an easy way to see if a site has this problem?
If you want to see if your site has this configuration problem you could also try our Snappy WPeC plugin that does provides some WPeC and WordPress diagnostic information. The plugin is free.
If you find the snappy plugin helpful and want to tell us how much you like it, why not purchase one of our other WPeC plugins. Perhaps the Shopper Watch plugin that let’s you see what users are looking at, and what they have in their carts, or maybe our stamps.com plugin that let’s you print postage from the WPeC sales log page.
If you need some help diagnosing and fixing up your WordPress + WPeC configuration email us and we can work with you and your hosting provider to get things set up correctly.