Archive for the ‘Systems’ Category

Diamond Comparison Tool

Wednesday, November 16th, 2011

Shopping diamonds just got easier with the Compare Diamonds tool.  View multiple diamonds together on a single page and easily identify their similarities and differences.

Getting Started

From diamond detail pages, select “Add to Compare” and the selected diamond’s details are added to the Compare Diamonds tool.  Diamonds added show up in the first or leftmost position on the comparison page.

View Similar

With one diamond in Compare Diamonds, an option to “View Similar” diamonds allows you to quickly and automatically compare against other diamonds.  This option is displayed only when similar diamonds exist.


Share your compare list with friends and family for feedback and discussion


View your compare list any time from the shopping cart menu or any diamond details page.

Best prices of GIA certified diamonds,

Shop Diamonds on your iPhone

Tuesday, July 19th, 2011

Shop and compare diamonds on your iPhone and save up to 20%.

Search by shape, price, size, cut, color, and clarity with easy to use and familiar controls.

Scroll through search results and view full diamond details including original GIA certificates.

Magento performance optimization (continued): custom Block Cache in Magento

Thursday, April 7th, 2011

As we keep improving to bring faster browsing experience to our visitors, recently we’ve made another step, to use Magento cache aggressively to speed up page processing at backend(server side).


By studying the traffic and visit statistics, we found that many of our visitors were landing on static CMS pages, so keeping these pages fast can make our visitors feel good at the first impression, rather than experiencing a slow page then leave. Originally we thought Magento could cache the CMS pages & blocks if we enable the cache in Admin Panel, but that’s not true after digging into the code. So we planned to change this and make those frequently-visited blocks to be cacheable to accelerate the response speed.

Finding solution

In Magento wiki, there is a tutorial introduces the regular way of using block cache. To make one block cacheable, you just need add the code for the block class like below:

protected function _construct()
   'cache_lifetime' => 3600,
   'cache_tags'     => 'Cache tags for this block',
   'cache_key'      =>' Cache key for this block'

If choosing this way, we need to edit every block class to use cache, this requires certain code change which is not effective yet. Is there a better way? Yes! Because we have Magento Events. After looking into the core module, we found that before getting block output Magento will dispatch an Event (core_block_abstract_to_html_before), this is a good place to inject our cache setting for any block we want rather than editing each block independently.


1. Add a new module or editing an existing module’s config.xml, add the following event listening setting:


2. Add the implementation of event handler:

class {your_company}_{your_module}_Model_Observer{
 //you can make this to be configurable at Admin Panel
 //the non-CMS Block you want to cache
 private $cacheableBlocks = array('Block_Class_A', 'Block_Class_B', ...);
 public function customBlockCache(Varien_Event_Observer $observer){
  try {
   $event = $observer->getEvent();
   $block = $event->getBlock();
   $class = get_class($block);
   if (('Mage_Cms_Block_Block' == $class) && $block->getBlockId()) {
    $block->setData('cache_lifetime', self::CUSTOM_CACHE_LIFETIME);
    $block->setData('cache_key', 'cms_block_' . $block->getBlockId());
    $block->setData('cache_tags', array(Mage_Core_Model_Store::CACHE_TAG, $block->getBlockId()));
   } elseif (('Mage_Cms_Block_Page' == $class) && $block->getPage()->getIdentifier()) {
    $block->setData('cache_lifetime', self::CUSTOM_CACHE_LIFETIME);
    $block->setData('cache_key', 'cms_page_' . $block->getPage()->getIdentifier());
    $block->setData('cache_tags', array(Mage_Core_Model_Store::CACHE_TAG,
   } elseif (in_array($class, $this->cacheableBlocks)) {
    $block->setData('cache_lifetime', self::CUSTOM_CACHE_LIFETIME);
    $block->setData('cache_key', 'block_' . $class);
    $block->setData('cache_tags', array(Mage_Core_Model_Store::CACHE_TAG, $class));
  } catch (Exception $e) {

3. Now we are done, pretty easy, right? :D

Further tuning

Soon after we rolled out the code, we met several problems that required code enhancement:

  1. For some CMS pages or static blocks, they might embed other dynamic blocks which shouldn’t be cached, so you may need use a ignore-list of CMS page id or static block id in the event handler, and skip the cache setting if the block is in the ignore-list.
  2. If your site has HTTPS enabled, you’d better use current protocol(Mage::app()->getStore()->isCurrentlySecure()) as a part of the cache_key in case the cache is mixed under certain case.

Easy way to implement Asynchronized Product Filtering(Layered Navigation) in Magento

Saturday, February 26th, 2011

This post is to introduce how we made the async product filtering in Magento when we were doing the new Diamond Search, you’ll find the solution is really simple and you can make it in minutes!

Systems Posts and Technorati

Thursday, July 29th, 2010

Posts to this blog can now be monitored via Technorati.

Technorati blog claim code: TUNVTFCGWUW9

Magento performance optimization: build our own “summary table” for diamond search

Monday, July 26th, 2010

This post is a follow-up to “Process to Optimize Magento under AWS”, to explain more details of enhancing the diamond search in, via summary table.

Process to Optimize Magento under AWS

Friday, March 26th, 2010

As we have been using AWS for nearly 2 years to run, I’ve summarized a general process to optimize Magento under AWS (or other cloud-based LAMP stack) as below:

1. Capacity planning, be clear about how many items will be loaded into the system as well as the expected traffic volume (rough) in a certain period, this can help you choose the proper hardware resource (EC instance for AWS) at the beginning.

2. Apply commonly used ways to each separate component/sub-system of your system, e.g:

> Apache/Web Server: compile/configure the right mode & module, set proper parameters such as MaxClients, process threads, enable compressing module and set a never-expire header for static files if possible

> MySQL: set proper cache size, buffer and FS mode; apply the high-performance patch provided by Percona

> PHP: compile all needed extensions to be static, use at least one OP cache extension (eAccelerator/APC/xCache/ZO) and set the right parameters (caching mode, compressing level, etc.), set proper memory limitation

> OS: tune the FS/network related parameters, shutdown all unnecessary backend services (e.g. cups, portmap, etc.)

3. Once all of these are in place, let’s dig something more with Magento’s native support:

> Enable cache for all

> Configure backend cache type to be memory based (either shm FS or OP cache’s shm function)

> Use memory FS or database to save sessions

> Enable flat category/catalog, use Magento compiler if possible

> Use separate host (even a lighter web server on same server, but different port) to serve static files (/media/*, /skin/*)

4. Now, the system should be performing reasonably well, I believe the site should be OK to launch! Actually, my post was written at that point after we finished all items listed above – step by step – we experimented using different approaches to bring better browsing experience to those who shop for diamonds and engagement ring mountings on

The next step will be much more interesting… also more challenging: monitor and detect the ‘performance optimizable area’ proactively, that could be either the slowest area of the system, or the place frequently called which could be bottleneck as traffic grows, here is a list that we have done/are doing based on our experience:

- Use separate server for database, web app and static files if needed

- Optimize Magento indexing strategy (we cannot easily upgrade to Magento 1.4, so need do something by ourselves with 1.3…)

- Build our own ’summary table’ for diamond search. As we have ~40,000 items, I can not imagine how slow Magento would be if using its own schema (even using flat-catalog)

There might be more specific cases when we were building JB, but that’s all what I remember and summarize at this point, I think we can go deeper for some specific problem if you guys have specifics you can share.

At last, I can share you the main stages that we have experienced since we started to run JB on AWS:

- Starting point – EC2 + S3: one small instance to host everything, write a script to backup data from EC2 to S3 everyday

- Soon after AWS brought out EBS, we moved to use EBS, all our ‘variable data’ (htdocs/database/logs) were stored on EBS, and we started to scale out — allocated more instances to run database and web server separately

- As backend/infrastructure-level performance are not big concern to us, we started to focus more on front-end/UX area, that what we are doing now — to improve our page look and feel, optimize the page structure to bring the web user convenient and useful information when shopping for diamonds and jewelry.


Performance Blitz

Thursday, September 17th, 2009
During July and August of 2009, the technical team focused on site performance. To start, we identified key performance metrics including
  • page load time from browser (seconds)
  • page processing time at backend (milliseconds)
  • resource utilization (memory, cpu, network, disk)

Each of these metrics were measured at the beginning of the project to establish baseline values. Next the team worked to identify, diagnose, and fix areas of our site that contributed to less than desirable performance.

The Production Environment

The online store manages more than 40,000 individual online luxury items including diamonds, pave engagement ring mountings, necklaces, earrings, and bracelets. Our goal is to never make our customers wait longer than 2 seconds for pages from our site.

The production environment is deployed and managed via cloud computing, using a small instance (1.7GB memory) Elastic Compute Cloud (EC2) from Amazon. Data storage is managed via Amazon Elastic Block Service (EBS); EBS provides highly available, highly reliable storage volumes for EC2.

We noticed that disk reads/writes were sometimes quite slow. So, we made a couple of changes to improve EBS I/O:

  • Reduce contention by creating separate disks for reads and writes
  • Added eAccelerator cache to both reduce PHP disk I/O and boost run-time performance

Our Web Server

Next we found that our Apache configuration included several modules that does not use. We removed the unused modules and recompiled Apache and mod_php statically to not only reduce memory consumption, but to also improve both startup and execution time performance.

The Database

As is often the case, database bottlenecks creep in and affect web site performance. We found that some simple tuning of our MySQL database yielded significant performance gains. We adjusted our MySQL configuration based on several tips from the Tuning Primer. We also adjusted MySQL innodb_flush_log_at_trx_commit to balance the I/O ratio.

Don’t Forget the Network

Page load time is dictated by the time required to download and present all page content. To boost download performance, we added a sub-domain for skin and media files which permits the browser to download content, media files, and skins in parallel. We also used gzip to reduce size of certain “large” pages (in some cases page size was reduced to ~40% of original) which in turn lowers network load.

Finish Line

The effort and changes described above have been implemented. We compared the original baseline values against the current values and here are the results:

  • average page load time is now less than 2 seconds; baseline value was more than 6 seconds
  • page processing time is now around 400ms; baseline value was 635ms
  • resource utilization is down more than 50% from baseline levels

We are quite happy that all gains from this “Performance Blitz” were achieved without adding or upgrading hardware! In the future, when we do add computing resources, we can be confident that will be used efficiently.

Our goal is to provide you with quality diamonds, pave engagement ring mountings, and an exceptional shopping experience.  We do this with our team of special designers, expert gemologists, skilled jewelers, and thoughtfully designed web site.  Explore and give our concierge service a try, we are here to exceed your expectations!

Matching Diamonds with Pave Engagement Rings

Tuesday, September 8th, 2009

Providing exceptional user experience (UX)  for online diamond and engagement ring shopping is no trivial task.  It is different from virtually all other eCommerce merchandising that you will find on the Internet today.

To begin with, each customer is unique in their approach; some begin with the diamond and others start by picking a special mounting followed by the diamond. For the later, some shoppers already have diamond as an heirloom or gift.   And, of course the diamond and ring must work well together.  An online system that does all this is much more than a traditional eCommerce solution.

The size and shape attributes of diamonds, are essential when selecting compatible  engagement ring mountings.  Equally important are the engagement ring prongs (metal pieces which hold your diamond in place).  The number, type, spacing, and orientation of prongs determines which sizes and shapes of diamonds each pave ring mounting can accommodate.

Prong spacing is especially critical for designer engagement rings and pave engagement ring mountings with their many smaller diamonds near the center stone.  High quality designer pieces accommodate specific shapes and sizes of diamonds.

The system automatically takes the prong attributes into account and presents customer with a list of matching products (mountings or diamonds based on your selection).  These “matching products” are presented because they work well with the diamond or mounting that you previously selected.  We use a combination of systems and gemologist recommendations to produce our matching products and we stand behind them 100%.

Our goal is to provide you with quality diamonds, pave engagement ring mountings, and an exceptional shopping experience.  We do this with our team of special designers, expert gemologists, skilled jewelers, and thoughtfully designed web site.  Explore and give our concierge service a try, we are here to exceed your expectations!

Additional Payment Options; PayPal and Amazon

Tuesday, September 1st, 2009

Adding more payment options to is a natural step forward.  Whether it’s for convenience or peace of mind, customers need choices when it comes to online payments.  Our customers asked for these options, so we’re pleased to make them available as payment methods in our shopping cart.

Beginning next week, payment method options will include:   all major credit cards, wire transfer1,  PayPal, and Amazon Payments.  During checkout, customers complete their billing and shipping addresses on and then select their payment method.

Our goal is to provide you with quality diamonds, pave engagement ring mountings, and an exceptional shopping experience.  We do this with our team of special designers, expert gemologists, skilled jewelers, and thoughtfully designed web site.  Explore and give our concierge service a try, we are here to exceed your expectations! customers automatically receive a 1.5% discount for payments made via wire transfer.