What we will talk about:
- Faster page loads on a Commerce Server Site
- Faster exports to Online Retail Channel Partners
Faster page loads on a Commerce Server Site
The Commerce Server object model has been developed with extensibility in mind. It was also designed to allow for rapid rollout of sites with medium sized product catalogs. The more products you add to the system the longer it takes to retrieve just the right set of products from the system to show in your web site.
Often site visitors just ‘Browse’ a site for content/products and the experience is considered simple. However, that simple experience requires significant complexity in code. Part of the anticipated site visitor browse experience is:
- Filtering – Limiting the products they are browsing by selecting size, color or material, etc.
- Paging – Limiting the products displayed on the page to 25-50-100
- Sorting – Displaying the products alphabetically, lowest to highest price, by user rating, etc.
- Ads – Presenting relevant marketing messages or ads
Modern eCommerce includes both filtering and sorting through the navigation process. Marketing staff expects page content (promotions, etc.) to be relevant to the requested page. These conditions often slow the response time of the page. Because the page not only needs to return the products it also needs to return the Sortable Fields, Filter Values, Paging needs to indicate number of pages based on the filters, and content. If the web page was static instead of dynamic these concerns would not come into play. However, product catalogs change and properties about products change (price, availability, color variants) so the pages are dynamically created.
Through interaction with the Commerce Server API and through a technique called ‘multi-threading,’ we can cause the information to come to the web page faster. Essentially, we can ask Commerce Server to give us data by asking for multiple sets of data at one time. Here is an example of a serial progression:
- Ask for Filters - 1 second wait for results. Process the results then go to next step
- Ask for Sortable fields - 1 second wait for results. Process the results then go to next step
- Get Sortable fields - 1 second wait for results. Process the results then go to next step
- Ask for Paging Info - 1 second wait for results. Process the results then go to next step
- Ask for Ads - 1 second wait for results. Process the results then go to next step
- Finally ask for a page of products that honors the filters and sorting criteria - 1 second wait for results. Process the results then go to next step
- Total wait, 6 seconds
Here is the example of a ‘multi-thread’ progression:
- Ask for Filters – no wait, results come back in 1 second
- Ask for Sorts – no wait, results come back in 1 second
- Ask for Paging Info – no wait, results come back in 1 second
- Ask for Ads - no wait, results come back in 1 second
- Ask for a page of products that honors the filters and sorting criteria – no wait, results come back in 1 second
- Each result comes back in approximately 1 second simultaneously, results are processed as they return
- Total wait, 1 second
The above description is provided as an example. Commerce Server is mature and has been performance tuned over time. However, the example presented should illustrate to you that 6 - 1 second tasks can be completed in 1 second not 6 seconds. This technique is called parallel programming and MethodFactory has implemented the technique in many places to make the already fast Commerce Server product appear even faster when providing data to web pages.
Ask yourself, how many customers do you lose because page loads are ‘too slow’? And consider this and other ways you can mitigate those losses.
Faster exports to Online Retail Channel Partners
Retail Channel Partners like Google and Amazon are important revenue components of most modern B2C eCommerce sites. Many require real-time integration for order injection and frequent updates of product information (price, quantity, etc.).
Let’s say that you have a product catalog of 300,000 products. If a programmer were to use the Commerce Server API to create an export to send to other online retail channels, that export could consume hours and significant server resources. Through understanding the Commerce Server object model, database structure, and current .NET based functionality, MethodFactory can produce the same export in minutes, sometimes even under a minute.
When creating a product catalog you may add properties that you want filterable or searchable. Commerce Server allows this through its API. Commerce Server does not add indexes to its table structures to support searching based on new properties. Because there is no ‘Amazon’ API in Commerce Server we added indexes to the Commerce Server tables on the fields we want to filter on and we wrote SQL stored procedures to take advantage of our indexes. When we coupled that with SQL Server 2008’s ability to produce XML, we produced our desired output in minutes instead of hours.