Archive for July, 2012

Building The Debs Store

Earlier today we announced the launch of the new debs store over on It’s something we’ve been working on for a while and we’re pretty excited about the value it’ll bring to debutantes trying to find their debs dress or tuxedo online.

I wanted to write a bit about the technologies behind the new store, and some of the decisions we made along the way, as we’ve learned a lot through this process and I wanted to share those lessons.

Finding Stock

The first challenge was finding stock to put into the store. There were a few different methods to try including partnering directly with boutique stores, or even stocking inventory and providing order fulfillment ourselves. But we’re an online business and we want to automate as we much as we possibly can allowing the business to scale in the right ways. We decided that the only way to go was to partner with other online stores, linking their content into our aggregated store focused purely on debs apparel.

There are literally hundreds of online stores selling stock suitable for the debs market. The only problem is that they sell pretty much everything else as well making it very difficult for debutantes to find what they need. Having a curated collection of all debs apparel provided across these online retailers in one place was our goal with this project. Now all we had to do was find a way to link in this content and commercialise it.

Commercial Decisions

There are a number of indirect benefits to launching a store like this one. It raises our profile in the industry and draws further attention to our debs planning and ticketing software. But the store needed to make commercial sense on it’s own as well. This is where the affiliate platforms come in. We looked through various affiliate networks, including LinkShare, SkimLinks, TradeDoubler, and Affiliate Window. We needed an affiliate platform with a robust API as we would need to do some pretty heavy integrations to keep the store managed and stocked with appropriate content.

Backend Integration

In the end we went for a flexible solution which supports multiple affiliate platforms. We built a set of administration tools which tie directly into each of the affiliate platforms’ APIs and allow us to really easily add and remove products into our store from each platform with a single click. It’s still a manual job, and always will be because we care about the quality of content we list, but integrating in this way really helps to speed up that process. Secondly, for obvious reasons we’re only listing items from merchants that actually deliver to Ireland so that’s a factor to consider as well.

To maintain the accuracy of the stock and it’s information we run daily scripts which compare the information in our store against the data returned in the corresponding API calls. This keeps the store fresh and reduces the number of dead links to virtually zero.

Improving the Content

In some places the images returned back from the affiliate platforms weren’t of a high enough quality for what we wanted, so we went about writing some additional scripts which automatically called directly out to the listing on the merchant’s website and, using some clever pattern matching, we pulled out much higher resolution images than are provided in the affiliate platforms’ API feeds.

We are also able to use some heuristics code to create relationships between items helping to offer relevant suggestions to users browsing the store. Much like the ‘related products’ links you often see in large online stores.

Server Optimisations

Despite Ireland being very small, and debs being extremely niche, the debs dress industry is still pretty important, and can be quite lucrative. To cater for the additional expected traffic we’ve bulked up our server somewhat. Here’s a quick overview of what we did.

Using CodeIgniter’s built in caching features, we implemented database caching and file caching where appropriate. Database caching is a relatively simple technique which alleviates pressure on SELECT calls to the database server. It stores the returned value of each SELECT statement in a file cache. And instead of querying the database, CodeIgniter checks if a cache exists for that query. If it does, then it uses the contents of the file instead of querying the database.

On top of database caching, we introduced file caching were appropriate. File caching is natively suppoted by CodeIgniter as well. It also supports Memcached and APC cache engines, but our server doesn’t have a huge amount of RAM right now (just 1GB), so we’re happy enough to use file caching for the time being. With file caching, the result of the processed PHP script (the HTML) is stored in a separate file. CodeIgniter checks if this file exists before attempting to run the PHP. In many cases this greatly reduces the CPU load on the server and reduces the processing time to similar of what it would be if the server was serving out static HTML files.

Not stopping there I wanted to improve our actual PHP configuration on our server as well. I switched from SuPHP to FastCGI and installed PHP’s APC caching engine. APC caches PHP’s interpretted code into a binary, helping to greatly improve any server’s performance by many factors. Using to load test our server I could see the server’s performance from 1-250 concurrent users over 1 minute going from an initial 143 successful hits and over 80% of timeouts to 2,400 successful hits with less than 1% of timeouts. That’s an improvement of over 16x. Using this new configuration our server can now handle a sustained level of traffic of more than 3,000,000 hits/day. Not bad for a single VPS running a CodeIgniter app and a MySQL database server.

I’ve also got plans to introduce Varnish Cache as a reverse proxy should that be needed. I’m expecting that to increase our server capacity to approximately 8,000,000 hits/day. Like they say, if that becomes our problem it’s a good problem to have.

Our new domain:

As part of the launch of the debs store, we’ve also fully migrated over to Yep, we’ve ‘pulled a facebook’ and dropped the ‘the‘ from our name. We’re really pleased with the new name and hope it’ll help to reaffirm our commitment to the debs industry and put us in top spot in people’s minds when they think of planning any aspect of their debs online.

Migrating an existing website from one domain name to another isn’t a straightforward exercise. There are many considerations to make and quite a number of steps to go through. I’ll write up a bit more about that in my next post.

Until then, please visit our new debs store and if you know anyone having their debs this year, please tell them about it.

Comments Closed