E-Commerce Performance Features

Performance, just like security, is a major non-functional characteristic of any software application. And for the most part, it depends on the application itself, not the size of infrastructure supporting the application.

The general e-commerce consensus is that either you always serve a page in under 300ms, or your customers get frustrated. You might probably get away with this in retail with occasional customers, but B2B users just cannot be tortured on everyday basis. Meanwhile, you also require advanced functionality for filtering, searching and sorting, catalog sizes of 10K-100K products are the industry norm, and why would one want invest in high-grade hardware for a simple e-commerce interface?

With E-Commerce B2B, we feel we have solved this. If anything, performance is definitely not in the list of support inquiries.

E-Commerce B2B uses data replication approach to make your Dynamics NAV data available on the e-commerce website, and vice versa.

Replication, or simply put - automatically maintaining a “mirror” database with the necessary data on the remote server - is arguably the most important design feature of E-Commerce B2B, as it provides numerous benefits for having the solution run stable, perform well with conventional hardware, and require minimum maintenance.

The key point for performance is that the web application operates on a local database only - it does not request anything from your Dynamics NAV while serving online customers. On this premise, you can easily scale-up or scale-out your infrastructure to serve thousands of customers without even slightly affecting your current Dynamics NAV infrastructure and performance.

Wholesales and B2B in general tend to operate on volume. The product catalog of an average E-Commerce B2B installation contains approx. 15,000 items with attributes, going up as high as 600K items, while nonetheless requiring rapid search, sorting and filtering capabilities. Never mind the popular e-commerce systems, this is a challenge for typical SQL-based technology as such. Given the specifics of Dynamics NAV, the proper indexing path will not help much, as e.g. “your price” field is not readily available in NAV, and is calculated on the fly based on ~10 parameters, date included. Yet you need to sort by this field, don't you?

We have done serious investing to solve the performance challenges related to large catalogs, and the technology we have landed to is a specific combination of a 100% in-memory database for your catalog, and data-mining techniques for deep lookups, aggregates, and calculations. With this up our sleeve, we are confidently within <300ms response times with the said size of catalog and feature complexity. Our largest server is only 4GB RAM currently, and it holds nicely both against international user base, and search engine indexing.

Finally, just having the software built simple and light may do wonders in terms of performance. This is now getting technical, but when you have interpreters over frameworks over containers over abstractions over assemblies over libraries, the end product just cannot be fast. In reality, just plain and simple is all you need nowadays (provided it's neat looking), as at the end of the day - you want to get your work done with as little friction as possible, not really a system that is so sophisticated that, you know, you need to stand by and wait while the page loads.