High Performance Oracle Endeca Designs for Retail. Technical White Paper 24 June

Size: px

Start display at page:

Download "High Performance Oracle Endeca Designs for Retail. Technical White Paper 24 June"

Phoebe Lillian Lawrence
5 years ago
Views:

1 High Performance Oracle Endeca Designs for Retail Technical White Paper 24 June

2 Excogis - High Performance Oracle Endeca Designs for Retail Table of Contents 1 Executive Summary Current design Store- specific data Content data Re- design Removing unnecessary data Re- structuring data Data Sharding Performance Testing & Measurement Testing Methodology Request Log MDEX Flags Test Infrastructure Specifications Testing Results Conclusion Page 2 of 13 Copyright 2014 Excogis Ltd. All rights reserved.

3 Excogis - High Performance Oracle Endeca Designs for Retail 1 EXECUTIVE SUMMARY As a specialist Endeca consultancy, we often come across organisations that have implemented an Oracle Endeca solution either on their own or by engaging a partner that had limited or no Endeca experience, resulting in a deployment that is at best not optimal. While technically, the original deployment may be acceptable for a period of time, more often than not it will eventually cease to be fit for purpose, and based on the business perception of the Endeca product, it may also be (incorrectly) considered unable to handle further/advanced functionality. One of Excogis clients (henceforth referred to as BigRetailer ) is such an example. The client in question is a retailer with a large brick- and- mortar presence that deployed an Endeca solution to power their online channel several years ago. BigRetailer never adjusted their Endeca design despite increasing the data processed and indexed by their Endeca deployment and their online channel (i.e. traffic & load) growing by more than 100%. Excogis used BigRetailer as a real- life example of the benefits that can be gained by using advanced design techniques and principles on an Endeca deployment. This white paper describes a redesign to BigRetailer s Endeca configuration and architecture that increased the performance by almost 300%. While the re- design work was specific to the structure of BigRetailer s data, the approach and principles used can be applied to almost any Endeca deployment. Page 3 of 13 Copyright 2014 Excogis Ltd. All rights reserved.

4 2 CURRENT DESIGN The current design of BigRetailer s Endeca configuration has two (2) main elements that negatively affect its runtime performance. 2.1 STORE- SPECIFIC DATA One of BigRetailer s main functional requirements was the ability to provide a first level of personalisation by presenting the user with a product catalogue that was available in their associated store (that will eventually fulfil their order), and display the pricing and promotions that applied to those products in that store. Each store has a catchment area based on address postcodes and a user is automatically associated with a given store based on the shipping address postcode defined in their profile. BigRetailer was operating three hundred and sixty (360) stores in their country, as of the writing of this paper. Each store was identified by a four (4) digit numeric ID. A product could have attributes that in some cases could have a unique value for each store, e.g. three hundred and sixty (360) different prices. Some of these store- specific attributes include: Attribute Value type Comments Stock Integer One (1) of six (6) possible values Price Floating point Any value OnOffer Integer The four (4) digit ID of each store where it is on promotion In an effort to future proof the deployment and capture data for any potential new stores, the Endeca configuration was set to index all attributes that were found in the source data. The resulting Endeca record has on average close to one thousand five hundred (1,500) attributes that are store- specific variations of the above set, and numerous other attributes that are not used in any way. 2.2 CONTENT DATA Another design decision made by the original implementation team was to include product content as part of the Endeca index. While this could be a useful approach for small data sets or limited content elements, in this case the content was the full product detail information in XML format. This XML content is presented on the Product Details Page (PDP) as- is. By doing this, Endeca had essentially become a content repository instead of a search & navigation engine to power rich data- driven user experiences. With the abundance of options for Content Management Systems (CMS), Product Information Management (PIM) systems, Content Delivery Networks (CDN) and commercial E- commerce platforms that are designed for exactly this type of capability, indexing product content in Endeca is completely unnecessary and detrimental. Page 4 of 13 Copyright 2014 Excogis Ltd. All rights reserved.

5 3 RE- DESIGN The re- design of BigRetailer s Endeca configuration and architecture focused on three (3) main areas: 1. Removing unnecessary data from the index 2. Re- structuring data for efficiency 3. Employing a data sharding architecture 3.1 REMOVING UNNECESSARY DATA As mentioned above, indexing large amounts of static content that are not used to facilitate search or navigation over the data set, is unnecessary and detrimental. In the redesigned Endeca configuration, attributes from the source data were explicitly mapped to pre- defined Endeca Properties and/or Dimensions. This avoided the inclusion of both the XML content data and unknown attributes that were simply passed- through to be indexed but not used by the application. For the purposes of this paper, it is assumed that any display- only attributes are served by another mechanism, e.g. CMS, PIM etc. 3.2 RE- STRUCTURING DATA The 6.x MDEX series was designed to use a more efficient index structure, by indexing data on an attribute basis. This made it more efficient to index wide records that had a large number of attributes with varying values. However, some attributes whose values are constrained to a pre- defined set of possible values, could be re- structured to take advantage of the more efficient attribute- based index storage. One such example is the store specific stock attribute used by BigRetailer. The current design will add to the record three hundred and sixty (360) different attributes, each of which can have one (1) of six (6) possible values. For example a record could include attributes such as: Stock_1001 = 3 Stock _1002 = 3 Stock _1003 = 3 Stock _1004 = 2 Stock _1005 = 2 Stock _1006 = 3 Stock _1007 = 3 Stock _1008 = 1 Stock _1009 = 3 Stock _1010 = 3 Page 5 of 13 Copyright 2014 Excogis Ltd. All rights reserved.

6 With the above structure, the MDEX must store and index three hundred and sixty (360) different attributes. By converting the attributes to use a naming convention that includes the stock value instead, the index becomes more efficient. The new record would include the attributes: Stock _1 = 1008 Stock _2 = 1004, 1005 Stock _3 = 1001, 1002, 1003, 1006, 1007, 1009, DATA SHARDING The concept of data sharding is an established design pattern in the technology space, mostly associated with big data systems and applications. The concept is to divide a large set of data into smaller sets of data using a reliable and reproducible condition (e.g. the last digit of a product ID) that can be used to easily determine which sub- set of data you need to access. Each sub- set is called a shard and an index of that shard will be more efficient than an index of the entire data set. The number of shards created and the condition used to split the data depends on the nature of the data being indexed, as well as the functional and performance requirements of the application(s) that will access the data. Sharding will result in multiple index instances that contain distinct data sets instead of multiple index instances of the same data. However, while the number of distinct indices increases, their size will decrease and performance increase without necessarily requiring more server resources that the monolithic index configuration. For the purposes of this paper, the store IDs were used as the condition to split the data, with each shard containing data for one sixth (1/6) of the overall stores, or sixty (60) stores per shard. The diagram below illustrates how the deployment architecture would change with sharding. Figure 1 - Legacy Monolithic index design Page 6 of 13 Copyright 2014 Excogis Ltd. All rights reserved.

Excogis - High Performance Oracle Endeca Designs for Retail Figure 2 - New

8 4 PERFORMANCE TESTING & MEASUREMENT In order to compare the performance of each Endeca index design, a series of performance tests were executed against each one. The performance tests were executed on the same hardware, same Oracle Endeca software versions, same source data and same query logs (see following section for details). The results were measured by analysing the MDEX request logs that resulted from the performance tests, using the Endeca reqloganalyzer utility. The results are shown in the last part of this section. 4.1 TESTING METHODOLOGY The performance tests were executed using the Rackspace cloud infrastructure. The tests involved one (1) test client and one (1) test server. Each index design was tested with two (2) different load configurations; one (1) using ten (10) concurrent connections and one (1) using twenty (20) concurrent connections. Each test for a given load configuration was executed twice, resulting in a total of eight (8) performance tests, four (4) for each index design. Before each test, the appropriate MDEX instance was started. At the end of each test, the MDEX instance was shut down, the MDEX logs were copied to a secure location and subsequently deleted from their default location in order to allow new log files to be created. Finally the test server was rebooted to prepare for the next test. The load applied by the test client to test server, consisted of HTTP requests to the Endeca MDEX server from a prepared request log. The requests were sent with zero (0) think time, i.e. as soon as the response to a request had been read, the next request was submitted immediately. Once the load test was complete, the MDEX request log was analysed using the Endeca requestloganalyzer tool, to measure the performance achieved during the test. 4.2 REQUEST LOG The request log used for the performance tests was taken directly from a load & performance test executed by BigRetailer s operations team. The log contained approximately two hundred and fifty thousand (250,000) Endeca queries. This log was pre- processed in the following ways in order to make it suitable for the performance tests that Excogis executed: Non- search or navigation queries were removed (e.g. /admin?op=ping requests) Certain parameter value delimiters were converted to match the format of the MDEX 6.5 format (e.g. + were converted to for the property selection parameter) Attribute names that were not used were removed Dimension IDs for certain store specific Dimension values (e.g. On Offer) that were not part of the index were mapped to equivalent Dimension IDs that were valid for the index Attribute names for certain store specific Attributes (e.g. Stock) that were not part of the index were mapped to equivalent valid Attribute names Attribute names and/or Dimension IDs for Attributes and/or Dimensions that were re- structured, were mapped to their corresponding new Attribute names and/or Dimension IDs Page 8 of 13 Copyright 2014 Excogis Ltd. All rights reserved.

9 4.3 MDEX FLAGS The MDEX instances used for the performance test had the following execution flags configured: --threads 6 --whymatch --spl --dym --dym_hthresh 5 --dym_nsug 3 --stat-abins 4.4 TEST INFRASTRUCTURE SPECIFICATIONS The specifications for the machines used in the performance tests were as follows: Test client Rackspace Next Generation Server (London region) Performance 1 configuration CPU: Intel Xeon 2.6GHz CPU Cores: 8 vcpu cores RAM: 8 GB Disk: 40GB System + 80GB Data partitions (RAID10- protected SSD) Network: 1,600 Mb/s OS: Windows 2008 R2 Datacenter, SP1 Software: Oracle Endeca Platform Service 11.0 Oracle Endeca MDEX Oracle Endeca Tools & Frameworks (with Experience Manager) 11.0 Rackspace Next Generation Server (London region) Performance 1 configuration CPU: Intel Xeon 2.6GHz CPU Cores: 8 vcpu cores RAM: 8 GB Disk: 40GB System + 80GB Data partitions (RAID10- protected SSD) Network: 1,600 Mb/s OS: Windows 2008 R2 Datacenter, SP1 Software: Oracle Endeca MDEX Page 9 of 13 Copyright 2014 Excogis Ltd. All rights reserved.

10 4.5 TESTING RESULTS The analysis of the MDEX logs following the performance tests, revealed a very significant increase in performance across all the captured metrics. The table below summarises the raw results of the performance tests. The designations 10T and 20T represent the results from the load configurations with ten (10) concurrent connections and twenty (20) concurrent connections respectively. Performance Metric Avg ops/sec Avg Response time (ms) Avg MDEX time (ms) Avg Response size (Kb) Legacy New Change Legacy New Change 10T 10T 20T 20T % % % % % % % % The diagrams below illustrate visually the dramatic difference in performance. Avg ops/sec Avg ops/sec Legacy 10T New 10T Legacy 20T New 20T Page 10 of 13 Copyright 2014 Excogis Ltd. All rights reserved.

Avg Response [me (ms) 160 140 120 100 80 Avg Response ome (ms) 60 40 20 0 Legacy 10T New 10T Legacy 20T New 20T Avg MDEX [me (ms) 16

11 Avg Response [me (ms) Avg Response ome (ms) Legacy 10T New 10T Legacy 20T New 20T Avg MDEX [me (ms) Avg MDEX ome (ms) Legacy 10T New 10T Legacy 20T New 20T Page 11 of 13 Copyright 2014 Excogis Ltd. All rights reserved.

Excogis - High Performance Oracle Endeca Designs for Retail 250 Avg Response size (Kb) 200 150 100 Avg Response

12 Excogis - High Performance Oracle Endeca Designs for Retail 250 Avg Response size (Kb) Avg Response size (Kb) 50 0 Legacy 10T New 10T Legacy 20T New 20T Page 12 of 13 Copyright 2014 Excogis Ltd. All rights reserved.

13 Excogis - High Performance Oracle Endeca Designs for Retail 5 CONCLUSION Using a real life example with real data and a real load test profile, we have documented a dramatic improvement in performance by simply modifying the Oracle Endeca index design. Even though each Endeca deployment is unique with its own requirements and constraints, the approach and design principles used in this paper can be applied to most Endeca projects. For example a similar approach could be used for a B2B application where customers can access a specific subset of the data with specific pricing defined by their individual contract. Another example is a retailer with multiple business units (e.g. clothing, electronics, furniture etc.) that offers a single basket experience or a fashion retailer that operates multiple brands. Traditionally the first instinct or assumption for addressing the scalability of an Endeca deployment is to increase the hardware footprint in order to scale horizontally, but we have shown that the right design and configuration of your Endeca deployment can be equally important as your other performance enhancing tools and mechanisms. If you would like to find out how we can help you improve your Endeca deployment, contact us at sales@excogis.com. Page 13 of 13 Copyright 2014 Excogis Ltd. All rights reserved.

RACKSPACE ONMETAL I/O V2 OUTPERFORMS AMAZON EC2 BY UP TO 2X IN BENCHMARK TESTING

RACKSPACE ONMETAL I/O V2 OUTPERFORMS AMAZON EC2 BY UP TO 2X IN BENCHMARK TESTING EXECUTIVE SUMMARY Today, businesses are increasingly turning to cloud services for rapid deployment of apps and services.