E-Business Application performance optimization based on WebSphere Commerce (7)

Optimization recommendations for special functions--search

The new search feature is the feature that introduces the WebSphere Commerce product during the Commerce V7 FEP2, and can provide a fast search function with good scalability under large data sets. Search for new features provides a fully integrated, Third-party search engine Runtime framework that provides a complete solution around this framework, including product catalog search, business management, and other features. Because the search framework provides rich scalability, the future of new features can be chosen based on the framework for development, so how to better optimize the search performance is more important. Due to the default integration of the SOLR search engine based on the Lucene library development in the WebSphere Commerce product, the SEO recommendations provided in this article are intended for SOLR, if not specifically identified. This section describes the optimization process for each part in the following steps as shown in Figure 1 below. For the sake of brevity, WebSphere Commerce is referred to as Commerce below.

Figure 1. Search run-time environment deployment steps

Optimization of search production environment planning and deployment

WebSphere Commerce Site Topology Planning

The new Commerce Search feature consolidates open source free search engine SOLR and deploys it as a standalone was application, so you need to take into account the server resources needed for the application when doing capacity planning for the entire Commerce site. It is generally recommended that you consider a horizontal approach in which a stand-alone server runs a SOLR application, which avoids the impact on the capacity of the server on which the Commerce application resides. The cost of this topology, in addition to the additional server resources required, is the need to consume a portion of the intranet network bandwidth to transmit Commerce and SOLR applications between the request and response data, considering the intranet speed and bandwidth situation, should be able to bear. Or consider a vertical way to place SOLR applications in a separate JVM on the same Commerce server. This can save the server cost already intranet bandwidth, but consumes the same server capacity.

SOLR applications also require Web server support, and often we recommend that a stand-alone Web server be deployed to the SOLR cluster to avoid the potential security risks associated with a shared Commerce Web server, and that SOLR query requests require additional firewalls to Performance issues, but the need for additional hardware purchases, including load balancing considerations, for independent deployment of new WEB servers requires a specific analysis of the environment specific to the customer to make decisions.

SOLR Application Topology Planning

At large sites, there is usually a thousands of or tens of thousands of concurrent traffic, and a single SOLR runtime Java virtual machine is hard to guarantee the performance of so many accesses, so it can be extended to SOLR with a Commerce-like level or vertical was server and merged into a single cluster. And to control the synchronization of the search index data in the cluster by configuring a single master service node, as shown in Figure 2. The primary node is used only for indexing and updating purposes, and the Commerce production environment does not access the primary node, but only from the node. Each time the master node produces an update, it is "pulled" to complete the replication update of the data by all detected from the node.

Figure 2. SOLR master-Slave configuration diagram