Magento Deployment Guide - ScaleArc · Magento Deployment Guide: Installing, Tuning, and Using...

© 2015 ScaleArc. All Rights Reserved.

Deployment Guide

Magento Deployment Guide: Installing, Tuning, and Using Magento with ScaleArc + MySQL + Galera

Deployment Guide | Magento with ScaleArc + MySQL + Galera

© 2015 ScaleArc. All Rights Reserved. | 1

Contents

1. Background.............................................................................................................3

1.1 What is ScaleArc? .........................................................................................3

1.2 What is MySQL? ...........................................................................................3

1.3 What is Magento? .........................................................................................3

1.4 How do these applications work in concert? .................................................3

1.5 Where can I go for additional help? ..............................................................4

1.6 Documentation Conventions .........................................................................4

2. Application Architecture .........................................................................................4

2.1 Website architectures ...................................................................................4

2.1.1 Conventional static website .................................................................4

2.1.2 Magento dynamic website ...................................................................5

2.2 Replication ....................................................................................................6

2.3 Clustering ......................................................................................................6

2.4 Automatic promotion .....................................................................................7

2.5 High availability .............................................................................................7

3. Preparation ............................................................................................................8

3.1 Servers ..........................................................................................................8

3.2 Internet Protocol addressing .........................................................................8

3.2.1 ScaleArc use .......................................................................................8

3.2.2 MySQL use ..........................................................................................8

3.2.3 Web server use ...................................................................................9

3.2.4 Example IP table .................................................................................9

3.3 User Management ........................................................................................9

3.3.1 MySQL user accounts .........................................................................9

3.3.2 ScaleArc user accounts .................................................................... 10

3.3.3 Magento user accounts .................................................................... 10

3.4 Licenses ..................................................................................................... 10

3.5 Security and networking issues ................................................................. 10

3.5.1 Allow password-free login during integration ................................... 10

3.5.2 Open the appropriate firewall port .................................................... 10

3.5.3 Allow unauthenticated network connections .................................... 10

3.5.4 Increase the maximum connection limit ........................................... 11

3.5.5 Domain Name Service configuration ................................................ 11

4. ScaleArc Configuration ....................................................................................... 12

4.1 Galera database clustering ........................................................................ 12



4.1.1 Adding the primary master member ................................................. 12

4.1.2 Adding additional Galera cluster members ...................................... 14

4.1.3 Finishing Galera cluster configuration .............................................. 14

4.2 Write ignore rules ....................................................................................... 15

4.3 Proxy Authentication .................................................................................. 16

5. Magento Configuration ....................................................................................... 17

5.1 Recreation of local.xml by Magento ........................................................... 17

5.2 Editing local.xml to use ScaleArc as a proxy ............................................. 17

6. ScaleArc Performance Monitoring and Tuning................................................... 18

6.1 Live monitor without caching ...................................................................... 18

6.2 Viewing stored analytics ............................................................................ 19

6.3 Analytics drill down .................................................................................... 20

6.3.1 Choose the busiest hour .................................................................. 20

6.3.2 Choose the Magento user ................................................................ 20

6.3.3 Add cache rules for the busiest queries ........................................... 21

6.4 Verifying cache performance ..................................................................... 22

6.5 Cache rule application support .................................................................. 23

7. Summary ............................................................................................................ 23

Appendix – Result set cache rules .......................................................................... 24



1. Background This deployment guide for administrators, developers, and owners documents how to deploy a complete, high-performance Magento dynamic website. This solution consists of multiple components:

ScaleArc, database load balancing software

MySQL, an open source database, running with replication

Magento, an open-source electronic commerce (e-commerce) storefront

This guide assumes ScaleArc and MySQL are already installed and running. We document the configuration changes necessary for Magento to use ScaleArc as its database traffic manager and tuning ScaleArc to obtain maximum performance with Magento.

1.1 What is ScaleArc? ScaleArc delivers database load balancing software that brokers communication between applications and databases. It manages read/write splitting, replication-aware load balancing, and query routing. ScaleArc accelerates performance via these techniques and query caching. It strengthens security with SQL firewall capabilities. In addition, ScaleArc’s cluster management feature improves availability and uptime.

ScaleArc operates at the database-connector level and requires no modification to applications or databases. It supports MySQL, SQL Server, and Oracle. The ScaleArc for MySQL version runs on x86-64 servers, x86-compatible hypervisors, or in the cloud.

1.2 What is MySQL? MySQL is the world’s most popular open source database. It is available in commercial and GPL editions and supports multiple storage engines, including transactional and in-memory tables.

MySQL offers two different redundancy modes: replication, where servers back each other up in master-master or master-slave configurations; and clustering, where databases are partitioned among multiple servers. We use replication, the simpler mode, as our redundancy mechanism.

1.3 What is Magento? Magento is the world’s most popular open-source e-commerce storefront for customer-driven order entry and payment. Over 25% of e-commerce sites in the Alexa Top One Million use Magento.1

Like MySQL, Magento is available in both community (GPL) and enterprise editions. The enterprise edition is supported directly by Magento. The community edition is self-supported, with end users contributing to the forums and wiki.

1.4 How do these applications work in concert? ScaleArc connects Magento and MySQL, presenting one database connection to Magento while managing multiple back-end MySQL servers automatically. It provides an abstraction layer that separates website administration and

1 Tom Robertshaw, February 2013 Ecommerce Survey.

http://www.magentocommerce.com/boards/

http://www.magentocommerce.com/wiki/

http://tomrobertshaw.net/2013/03/feb-2013-ecommerce-survey/



maintenance from database deployment and operation, allowing administrators to dynamically add and drop servers depending on a site’s load.

1.5 Where can I go for additional help? If you need further assistance with any ScaleArc product or service, please contact us.

1.6 Documentation Conventions

Note: by convention, SQL verbs are capitalized while user objects are not. Consider this example:

SELECT user, host, password FROM mysql.user;

In this case, the tokens SELECT and FROM represent SQL reserved words, which is why they are capitalized. The other tokens are user (or system) defined column and table names. We follow this convention throughout the guide.

2. Application Architecture This chapter examines architectural concepts behind a dynamic website integrating ScaleArc, MySQL, and Magento. We first provide an overview discussing key differences between this solution and a conventional static website. Next, we introduce the concept of replication, necessary for configuring a master/slave relationship between multiple MySQL database servers. Finally we introduce the concept of clustering, which ScaleArc uses to manage multiple MySQL servers.

2.1 Website architectures In this section, we compare and contrast a traditional static website, using a web server to retrieve static documents on behalf of a user agent (UA), with a dynamic website, where an application server populates document templates with database calls to produce a “live” document on demand.

2.1.1 Conventional static website

The Hyper Text Transfer Protocol (HTTP) defines a mechanism for retrieving static documents from a server and delivering them to an end user. HTTP defines a request/response protocol where a UA, usually a web browser, issues a request, typically GET, to a web server. The web server then interprets this request and returns a document, usually in Hyper Text Markup Language (HTML) format, to the UA. This basic architecture is illustrated below:

Meaning Typography Description

Substitutable parameter <parameter> Substitute the desired value for this token

Source code command Type the command as shown

User interface Button Look for or interact with the identified element

Literal file.txt Look for or type the literal text indicated

Caution, Note, Warning Callout Please pay particular attention to these instructions

http://www.scalearc.com/about/contact-us/

http://www.rfc-editor.org/info/rfc1945

http://www.rfc-editor.org/info/rfc1866



In a static architecture, the performance limiters are typically the network and the web server. Improving poor performance usually means increasing network bandwidth between the UA and the server and perhaps upgrading the server to transfer more documents per unit of time.

Although a static website is architecturally simple and yields high performance, it has one key limitation: all of the content must be generated in advance. This makes it difficult to manage a real-time inventory and sales system. Providing per-consumer content implies using a dynamic website architecture, which is discussed in the following section.

2.1.2 Magento dynamic website

The front-end architecture of a dynamic website is similar to that of a static one: a UA still makes requests via HTTP to a web server, which returns HTML documents in the response. But rather than merely returning a static document, the server instead invokes an application to generate the document “on the fly.” Typically this application is Magento, which populates static data from templates with data fetched via a database call. This more complex architecture follows:

index.html

about.html

products.html

contact.html

User

Agent Web

Server

User

Agent Web

Server

Magento

Database

Template

Library



The network and web server are still performance limiters in a dynamic architecture. However, additional limiters arise as well. One is the speed of page assembly performed by the application – Magento in our case.2 Another performance limiter is the latency of the database itself.

Page assembly speed can be improved in much the same way as improving web server performance: upgrade the server hosting the application. Improving database performance, however, usually involves adding additional, replicated servers. We discuss this approach in the next section.

2.2 Replication Just like any other server, database server performance may be increased by the addition of resources. But databases have an architectural feature, namely transaction integrity, which limits the performance gained from simply adding resources.

A conventional web server may distribute multiple static documents to multiple consumers simultaneously without corrupting the original sources. But since a write transaction must be atomic, in theory no more than one query may write to a given row at a time.3 Otherwise one producer’s write request could change the database in such a fashion as to invalidate a subsequent consumer’s read request.

MySQL uses replication to provide for data integrity and redundancy. In addition, database applications may use this feature to serve multiple consumers in parallel. Consumers with write requests interact with database masters, while consumers with read requests interact with slaves. Since most applications read more than they write, most replication sets include more slaves than masters.

One problem with this strategy is the application must determine if a request is read only (SELECT) or read-write (DELETE, INSERT, UPDATE) and then route the request to the appropriate server. This approach introduces more complexity into the application.

ScaleArc, however, uses clustering to isolate this increased complexity. ScaleArc connects with multiple applications, routing all requests to the appropriate server in the replication set. This topic is discussed further in the next section.

2.3 Clustering Among other features, ScaleArc serves as a database traffic manager: applications connect to ScaleArc, which then connects to the underlying database server. ScaleArc groups elements of a replication set into an entity known as a cluster. ScaleArc then uses the cluster configuration to determine how to route incoming SQL transactions.

In theory, one cluster member is designated as the master with read-write capability. Other members are slaves with read-only capability. In practice, the number of cluster masters and slaves is an operational decision, and site administrators can change these numbers to reflect actual performance needs.

ScaleArc examines each incoming SQL transaction and then routes the request to the appropriate server. For example SELECT requests may be routed to a read-only

2 If performance is sufficient, the web and application server may run on the same processor. 3 In practice the database server employs a query analyzer to determine whether multiple queries

contend for the same row to execute more than one query simultaneously when possible.



node, while DELETE, INSERT, and UPDATE requests must be routed to a read-write node. ScaleArc uses a modified round-robin algorithm to automatically load balance the incoming requests.

Centralizing this load balancing and routing decision within the ScaleArc database traffic manager offers several advantages to application developers. First, it removes the need to modify the application to match the composition of the underlying cluster. ScaleArc instead manages multiple connections to multiple database servers on the application’s behalf.

Second, developers may use a simple single-user, single-threaded model for designing database logic. Developers need not write a “least busy” routing algorithm. Instead, developers write the application as if it were the sole user of a single server, but they still reap the performance benefits from load balancing and intelligent routing across multiple servers.

ScaleArc Platinum Edition provides the benefit of automatic promotion: in case of failure, a stand-by node is promoted to the master role. This benefit is discussed in the next section.

2.4 Automatic promotion Magento websites driving e-commerce and other mission-critical business applications often employ MySQL Cluster as an advanced form of replication. In this mode, there are at least two master database servers: a primary and a secondary. Write transactions are normally routed to the primary master. If this node fails, then write transactions are instead routed to the secondary master. Once the original primary comes back online, the masters synchronize. Then each master node resumes its original role.

ScaleArc Platinum Edition includes the ability to perform these routing changes on behalf of Magento. The primary master is configured as a Read + Write node, while the secondary master is configured as Read + Standby. When a failover occurs, ScaleArc queues transactions during switchover and reroutes traffic to the secondary server.

With ScaleArc Platinum Edition managing automatic promotion, the application maintains a single connection to the ScaleArc database traffic manager, and ScaleArc handles all of the associated failover logic. As a result, failover time is reduced by an order of magnitude.

This method supports a choice of clustering software: either MySQL Cluster itself or third-party choices such as Galera Cluster and Percona XtraDB Cluster. It is even possible to switch the cluster layer during operations without changing the driving application.

The ScaleArc software, of course, must be available for an application to function. Fortunately ScaleArc supports a high-availability (HA) mode to achieve maximum uptime. This design is discussed in the next section.

2.5 High availability Because ScaleArc is used in mission-critical applications, the product supports an HA mode for maximum uptime. In particular, ScaleArc uses an active/standby reliability model with automatic failover in case of service failure.

In HA mode, a pair of ScaleArc instances are both running. The master instance sends a “heartbeat” signal to the slave. The master also shares all state changes with the slave.

http://en.wikipedia.org/wiki/MySQL_Cluster

http://www.codership.com/content/using-galera-cluster

http://www.percona.com/software/percona-xtradb-cluster



When the slave detects a “heartbeat” failure, it assumes the master’s role and begins serving database requests. Once the master is repaired and brought back online, the slave then reverts to a monitoring state, awaiting the next failure.

Although the active and standby nodes each have a unique static IP address, the pair shares a virtual IP address. Applications connect to the virtual IP, which is constant during failover. Allocating IP addresses to ScaleArc and MySQL, as well as the creation of user accounts, is discussed in the next chapter.

3. Preparation Since our solution consists of ScaleArc, MySQL, and Magento components integrated together and communicating with each other, IP address allocation and user management must be coordinated. Also licenses for the solution components must be installed. This chapter presents guidelines for configuring these items in advance.

3.1 Servers Our solution typically consumes six total servers: two ScaleArc servers, one master and one high availability (HA) slave; three MySQL servers, one read-write master and two replication slaves; and at least one web server hosting the combination of Apache, PHP, and Magento.

These servers may be physical, virtual, or a combination of both. To serve site traffic, the web server should be accessible via either a public IP address or a pinhole. But other IP addresses may be private.

The ScaleArc servers are considered software appliances, each running a self-contained operating system and the ScaleArc database load balancing software. Other servers may run any operating system supported by Apache or MySQL as appropriate.

3.2 Internet Protocol addressing Our solution requires that all network elements communicate with each other at all times. One method for meeting this requirement is to assign static IP addresses to all elements. Another method is to provision DHCP assignments in advance based on Ethernet addresses.

3.2.1 ScaleArc use

Since two ScaleArc servers (one active and one standby forming an HA pair) are running in this solution, we need one IP address for each of these servers.

We also need a third address, a virtual IP address. This IP address is the one Magento will use as the DB_HOST parameter in local.xml to connect with ScaleArc, making ScaleArc failover transparent.

3.2.2 MySQL use

In this example, we employ one MySQL master node and two MySQL replication slave nodes for a total of three addresses. All of our database nodes may operate on the standard MySQL port of 3306.

It is possible to have three MySQL instances installed on the same host and differentiate between them via different ports. This practice is not recommended for production purposes, as such an arrangement substantially limits performance.



3.2.3 Web server use

The web server has a unique requirement: it must accept HTTP requests from the public Internet and deploy SQL commands from Magento on our private intranet. Depending on our network configuration, we need either one or two IP addresses.

If we can route a public IP address and port number via a pinhole to a private IP address, we can use this same private IP address for both purposes. But if not, we may need to configure a public IP address for use by the Apache web server and a private IP address for use by Magento.

3.2.4 Example IP table

We present an example IP table for this installation scenario assuming our firewall or router can provide a pinhole for the public/private network interface:

Although this table must be adapted to a particular installation, we use the above values for examples throughout the rest of the document.

3.3 User Management All of the solution components interact with a MySQL user. And MySQL has root, a password-free, local user with administrative privileges. We now discuss user account assignments, starting with MySQL itself.

3.3.1 MySQL user accounts

MySQL recommends creating a dedicated user for replication. This user may be limited to connect only from those nodes actually hosting MySQL itself.

We also need a remote root user for ScaleArc. We may limit this user to connect only from the IP addresses used by ScaleArc. But this user is required for ScaleArc cluster setup. Full privileges (GRANT ALL) are needed on *.*, but the WITH GRANT OPTION is not required.

Finally, we need to configure a database and user name for use by Magento to publish the website. We recommend this user be restricted to the IP address of the web server itself for security reasons.

One final note: in a MySQL installation with replication, execute all user creation commands on a master. Then the replication mechanism will propagate these changes to the slaves.

4 Note we do not consider application server redundancy, meaning multiple Apache web servers

running PHP and Magento, but this setup may be required for some site loads.

IP Address Hostname Purpose

172.31.1.1 None Default gateway

172.31.1.110 ScaleArc-01A ScaleArc master node

172.31.1.111 ScaleArc-01B ScaleArc HA standby node

172.31.1.112 None ScaleArc virtual IP address

172.31.1.113 MySQL-01 MySQL read-write primary master

172.31.1.114 MySQL-02 MySQL standby-read secondary master

172.31.1.115 MySQL-03 MySQL read only replication slave

172.31.1.116 StoreFronter4 Apache running PHP and Magento



3.3.2 ScaleArc user accounts

ScaleArc has two users: the boot user, available only via the server console, and the main administrator, available via the web console.

The default boot user name is admin with a password of admin as well. This account is used to set the appliance IP address, subnet mask, and gateway.

The main ScaleArc administrator user name and password are defined during initial setup. This setup is performed via the web console, which resides on port 80 at the node’s IP address.

3.3.3 Magento user accounts

Magento includes two classes of users: internal, assigned by Magento for site publication purposes, and external, defined within MySQL and used by Magento itself to access the content database.

We need to specify the external MySQL user when starting Magento installation. During the installation process, we define the internal administrative user.

3.4 Licenses Some components of our solution require licensing. The Apache web server and PHP are all open source products. None requires a license.

Both Magento and MySQL are available in community (GPL) and enterprise editions. To use the enterprise editions, please obtain valid licenses.

ScaleArc is a proprietary product requiring licenses. We need two licenses, one for each server in the high availability (HA) pair. ScaleArc is glad to provide free 30-day evaluation licenses. Please contact us to obtain these licenses.

3.5 Security and networking issues By default, both Linux and Windows come pre-configured to prevent networking MySQL servers together. In this section, we discuss some basic setup requirements for allowing this networking.

3.5.1 Allow password-free login during integration

As mentioned earlier, MySQL installs by default with a password-free root login from localhost. Once the solution has been completely installed and tested, one may constrain this password-free account. We recommend that all other accounts, including the replication, ScaleArc, and Magento accounts, include password auth-entication and named host limitations.

3.5.2 Open the appropriate firewall port

MySQL typically communicates on port 3306 via the TCP/IP protocol. Configure firewalls such that ScaleArc and Magento may connect on this port. If corporate security policy prevents opening this particular port, consider installing MySQL to run on an unblocked port, such as 8080. Then use the unblocked port during solution integration.

3.5.3 Allow unauthenticated network connections

Both ScaleArc and Magento work with the user authentication service built into MySQL. The network connection to MySQL, however, is unauthenticated.

Mandatory access controls requiring authentication prior to establishment of a network connection may prevent MySQL connections. Please disable any service that enforces such control. In Linux, this step usually means disabling selinux. In Windows, this step usually means disabling a specific group policy object.




3.5.4 Increase the maximum connection limit

For historical purposes, MySQL ships with a default limit of 150 simultaneous connections. By default, ScaleArc maintains a pool of 300 simultaneous connections. Either the MySQL connection limit must be increased or the ScaleArc pool must be decreased.

Note MySQL 5.1.17 and later can handle up to 100,000 connections and 500-1,000 connections are routine. We recommend setting the maximum connection limit to at least 500 for this solution by performing the following steps:

1. Stop the MySQL service. Use the sc stop MySQL command in Windows5

or the service mysqld stop command in Linux to perform this task.

2. Open the my.ini file in the Windows installation directory or the

/etc/my.cnf file in Linux using a text editor.

3. Find the [mysqld] section within this file and add the following statements:

max_connections=500

max_connect_errors=999999

4. Start the MySQL service using either the sc start MySQL command in

Windows or the service mysqld start command in Linux.

Alternatively one may use the MySQL SET command to alter these variables on a running server. But unless recorded in the configuration file, such changes will be lost upon server restart.

3.5.5 Domain Name Service configuration

During login of a remote user, MySQL uses reverse Domain Name Service (DNS) lookup for comparison with the host field in the mysql.user table. This process allows MySQL to allow authentication from some IP addresses but not others.

For this operation to work properly, one of the following options must be implemented:

Enable the reverse lookup service. This option is disabled by default on

Windows DNS servers.

Define the hostname and IP address in the hosts file.

Enable skip_name_resolve within MySQL. This option is normally

disabled.6

Implementing one of these options will reduce the login latency. Otherwise ScaleArc will time out when attempting to connect to MySQL.

5 One chooses the service name at installation. This name may be something else, like MySQL56.

Or use the Services snap-in under Administrative Tools in the Control Panel to manage this

service. 6 This last option must be implemented when using IP addresses instead of host names.

http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_max_connections

http://dev.mysql.com/doc/refman/5.1/en/too-many-connections.html

http://dev.mysql.com/doc/refman/5.1/en/too-many-connections.html

http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_max_connect_errors

http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_skip_name_resolve



4. ScaleArc Configuration ScaleArc customer support provides all customers, both pre- and post-sale, with standard installation documentation. These documents discuss how to install ScaleArc in all environments.

For most Galera Cluster (including Percona XtraDB Cluster) environments, however, ScaleArc should be configured in a specific manner with respect to database clustering, write ignore rules, and proxy authentication. The following sections discuss these configuration steps.

4.1 Galera database clustering ScaleArc uses a cluster of database servers to perform several performance acceleration tasks including load balancing and read/write splitting. Prior to creating a cluster, however, the database servers must be running in Galera Cluster mode. Then we may add these servers to a database cluster.

We begin by adding the primary master node as a read/write member. We next add secondary masters as standby nodes and slaves as read-only nodes. We document these tasks in the following sections.

4.1.1 Adding the primary master member

After installing ScaleArc, we may begin Galera cluster configuration. To do so, click Clusters in the main menu followed by the Setup iDB Cluster button on the Welcome! screen.7 This step loads the Create Cluster screen as illustrated in the following section. To create a Galera cluster, perform these steps:

1. Enter a Cluster Name, such as Accounting or Product-Catalog. This

name is descriptive and used throughout the web console.

2. Set both the Load Balancer Virtual IP Address and the Outbound

Virtual IP Address to All IPs [Any]. This setting allows the cluster to use

all IP addresses assigned to ScaleArc.

3. Set the Database TCP Port to 3306 so existing clients may connect with

the cluster via the standard MySQL port. Otherwise, set the port that clients

should use to connect with ScaleArc.8

4. Set the Username and Password of the user created for ScaleArc as

documented in Section 0, 3.3.1 MySQL user accounts. This user must

have GRANT ALL ON *.* privileges but need not have the WITH GRANT

OPTION privilege.

5. The Add Server button changes from an unavailable to an available state.

Click this button.

6. On the Adding Server dialog, enter the IP Address (or the FQDN if

available) of the primary MySQL replication master.

7 If at least one cluster is already configured, click instead the Add Cluster button that appears in

the upper right hand corner of the Clusters screen. 8 Since each client connection port must be unique, choose a different port number if 3306 is in

use with an existing cluster.

http://support.scalearc.com/



7. Leave the Server Status as Read + Write, as this first cluster member is

the primary master.

8. Verify the other settings on this screen are correct. Verify the Port Number

and Maximum Concurrent Server Connections meet the environment’s

requirements. Then click Add Server.

9. An animated “Adding Server” dialog appears. ScaleArc adds the

replication master to the cluster as illustrated in the Servers section shown

below:

10. Verify the server is up and running as indicated by the green “pilot light”

adjacent to the master server’s IP/Hostname entry. Also verify the server

role is correct.

To edit the primary master’s hostname or role, click the associated gear icon. To remove this entry completely, click the associated delete icon. You may then click Add Server to start over from scratch.

To add additional standby master and slave servers to this Galera cluster, perform the steps outlined in the following section.



4.1.2 Adding additional Galera cluster members

After adding the primary master to this new Galera cluster, we can add additional standby masters and slave servers by performing the following steps:

1. Click the Add Server button. The Adding Server dialog box opens.

2. Enter the IP Address (or DNS Name) for this additional server.

3. The Port defaults to 3306. Modify this field if necessary.

4. Set the Server Status drop-down control to Standby + Read for secondary

master nodes or Read for slave nodes. Or choose Standby for nodes that

handle traffic only during failover.

5. Click the Add Server button.

6. Verify the “pilot light” adjacent to Hostname/IP for this server in the cluster

server list is green.

To modify or remove a server, click the associated settings or delete icon. To add additional servers to the cluster, repeat the steps in this section. To complete cluster configuration, follow the steps in the next section.

4.1.3 Finishing Galera cluster configuration

Once all of the servers have been added, we can complete configuration of the Galera cluster. To do so, perform the following steps:

1. Scroll down to the bottom of the Create Cluster page and click the Setup

Cluster button.

2. ScaleArc detects the servers are members of a Galera cluster and displays

the following dialog:

3. Click Yes. After a few moments, the Clusters page will load and the newly

created cluster will be displayed in the cluster list as the following screen

capture illustrates:



4. Verify the cluster is up and running by verifying a green and white check

mark is adjacent to the cluster name and a green “pilot light” is adjacent to

each server.

After creating the cluster, ScaleArc will perform read/write splitting as well as primary/secondary master failover automatically without changing Magento itself.

4.2 Write ignore rules ScaleArc has a strict interpretation of what constitutes a write command. A SQL command that begins with SELECT is considered a read-only command. All other commands are considered write commands.

Magento, however, issues SET commands. These commands of course do not begin with SELECT, yet SET commands do not cause a database change either. If we explicitly declare SET commands as write ignore rules, we obtain even higher performance from read/write splitting. Here is how to set up this configuration:

1. Navigate to Clusters. Click the appropriate Cluster Settings button as

shown in the following screen capture:

2. A multi-tab control loads. Click on the iDB Settings tab.

3. Navigate to the Write Ignore section as illustrated below:

4. Click the On button, then click the Set Rules link.

5. The Write Ignore Rules dialog opens. Click Add Rule, then type SET

names utf8 in the newly created rule. Before proceeding, verify the screen

looks similar to the one shown here:



6. Click Add Rule again to insert a SET SQL_MODE='' (two single

apostrophes, no space) rule.

7. If everything appears in order, click the Save button.

Now ScaleArc will route these commands to the least busy database server.

4.3 Proxy authentication ScaleArc can perform connection pooling by authenticating with MySQL on behalf of the Magento user. But first, this user name, password, and database must be stored in the cluster settings. To do so, perform the following steps:

1. Navigate to Clusters.

2. In the Settings column, click on Users & DBs for the appropriate cluster.

3. The Authentication Offload dialog box loads. Set this feature to On as

illustrated below:

4. Click the Fetch Users button. A user selection screen appears. After a few

seconds, the user list populates. Check the Magento user name and click

the Save button as shown below:

ScaleArc now performs connection authentication and pooling on behalf of the Magento user.



Congratulations! Configuration of ScaleArc for MySQL + Galera + Magento is complete! Configure Magento to use this ScaleArc database cluster by following the steps documented in the next chapter.

5. Magento Configuration Once MySQL and ScaleArc are installed, we simply adapt Magento by changing the database connection settings. We do so by editing the XML parameters in the local.xml file in the Magento site’s app/etc directory. You have two ways to do so: delete this file so Magento will recreate it. Or modify the file so that Magento connects with ScaleArc as a proxy instead of with the database server (or servers) directly.

5.1 Recreation of local.xml by Magento Magento checks for the existence of local.xml every time someone visits the store. If this file does not exist, Magento loads an installer that creates the file from scratch. You will be prompted for the database name, server host name, user name, and password during this process.

Deleting local.xml also requires creating a new main administrative user: you will be prompted for a new “super user” name, email, and password. After logging in again, you may delete this additional user. To avoid this step, directly edit local.xml instead as discussed in the next section.

5.2 Editing local.xml to use ScaleArc as a proxy A less intrusive method of changing the Magento database connection is to simply edit local.xml:

1. Stop the Apache web service. Use the service httpd stop command on

Linux or the sc stop httpd command on Windows.9

2. Open the local.xml file in the app/etc directory under the storefront’s

home directory, for example

/var/www/html/magento/app/etc/local.xml, in a text editor.

3. Scroll to the <connection> element, which is illustrated below:

<connection>

<host><![CDATA[127.0.0.1]]></host>

<username><![CDATA[magento]]></username>

<password><![CDATA[mAgent0!]]></password>

<dbname><![CDATA[magento]]>></dbname>

<initStatements><![CDATA[SET NAMES utf8]]></initStatements>

<model><![CDATA[mysql14]]></model>

<type><![CDATA[pdo_mysql]]></type>

<pdoType><![CDATA[]]></pdoType>

<active>1</active>

</connection>

9 You may also use the Services snap-in to identify and stop the Apache service.



4. In the <host> element, change the data between the innermost bracket

pair from the current host name to the IP of the ScaleArc software

appliance, or from 127.0.0.1 to 172.31.1.112 following our example.

5. If the ScaleArc node is connecting to clients via a different port number,

add a <port> element containing a plain-text integer with the desired port,

for example:

<port>3406</port>

6. Verify there is no other change to local.xml file – then save this file.

7. Start Apache with the service httpd start or sc start httpd

command as appropriate.

8. Test connecting to the Magento storefront via a web browser.

After saving the revised local.xml file and restarting httpd, Magento will immediately start using ScaleArc as its proxy to MySQL. No other change is required.

6. ScaleArc Performance Monitoring and Tuning Once configured, ScaleArc provides several automatic performance benefits. One is read/write splitting, which means SELECT queries won’t wait while other queries block. Another is load balancing among a pool of servers. A third is connection pooling, where ScaleArc maintains consistent connections to the database, recycling these among hundreds of dynamic client connections.

One major performance benefit requires manual authorization – query caching. ScaleArc can store the result set of a site’s busiest queries in memory and return those results on demand without calling the database server. Programmers do not have to write even one line of code or use a different storage engine to obtain these benefits. Instead, you just add a rule to the cache. 10

So how does one determine from the millions of queries a site receives, which ones account for the biggest percentage of database server load? Simple: run live traffic through ScaleArc and use its Analytics feature to identify such queries. Then use the web console to identify the best queries to cache, and you can add them to the cache in one click.

Instructions for adding queries to the cache are documented in this chapter. Advice for setting time to live values per Magento table is discussed in the following chapter.

6.1 Live monitor without caching Once ScaleArc is serving a site, use the live monitor to view the queries per second served between applications and each database cluster. To view this data, perform the following steps:

10 Please first consult with ScaleArc customer support as discussed in Section 0, 6.5 Cache rule

application support.



1. Navigate to Live Monitor → Cluster Stats via the main menu, then click

on the desired cluster.

2. Observe the real-time display showing the past 30 seconds of actual traffic.

3. Scroll to the middle pane showing Queries/Second and the Cache Hit

Rate.

The display should be similar to the following screen capture. Note that even though several queries are running through ScaleArc, the hit rate is zero because caching is not yet turned on.

6.2 Viewing stored analytics While the Live Monitor displays various real-time traffic parameters for the immediately preceding 30 seconds, Analytics shows traffic statistics in graph form over periods of one day, one week, one month, and three months.

To start using this capability, click on Analytics in the main menu. This step loads the summary page, which displays an overview of the current day. Change the start date and sample period using the controls in the upper right hand corner. Mouse over the graph to get peak readings at the sample period interval, as shown in the following screen capture:



Use stored analytics to identify the queries that consume the most storage time. Then add rules to cache these queries with three clicks each. The process for doing so is described in the next section.

6.3 Analytics drill down From this same page, you may drill down and add specific queries. The general process for doing so is:

6.3.1 Choose the busiest hour.

6.3.2 Choose the Magento user from that hour.

With the mouse hovering on the row containing Total Queries for the Magento database, click to load the Query Types browser.

6.3.3 Add cache rules for the busiest queries.

Step-by-step instructions for completing this process are discussed in the following sections.

6.3.1 Choose the busiest hour

From the Cluster Stats display described in Section 0, 6.2 Viewing stored analytics, perform these steps:

1. Choose an appropriate date.

2. Click the down arrow icon (▼) in the Total Queries column. This step

moves the busiest hour to the first row.

3. Click that first row. The user page for this hour loads.

You are now viewing the user details page for the busiest hour on the chosen date.

6.3.2 Choose the Magento user

The next analytics page shows the various database users. With Magento, there are two users: the Magento user itself, which represents actual traffic, and NULL,

The Analytics interface

uses a “mouse over”

mode. Many items

automatically open to

expose further details

without clicking. Expand

the web browser window

fully to see as much of the

interface as possible.

Finally, use a pointing

device that has a scrolling

wheel or function.



which represents system functions. Scroll the page down and mouse over the row containing the Magento user summary statistics, which will automatically expand as follows:

With the mouse hovering on the row containing Total Queries for the Magento database, click to load the Query Types browser.

6.3.3 Add cache rules for the busiest queries

The Query Types browser begins with a graph showing all queries plotted by number of repetitions and execution. Thus the queries responsible for the most system load “land” in the upper right (light pink) quadrant. Mouse over these queries to see the underlying SQL regular expressions as the following screen capture illustrates:

To identify the busiest query for the hour and add it to the query cache, perform the following steps: 11

11 Please first consult with ScaleArc customer support as discussed in Section 0, 6.5 Cache rule

application support.



1. Click the down arrow icon (▼) in the Server Time column to sort these

queries from highest to lowest CPU consumption.

2. Mouse over the first row containing a SELECT statement. This row

automatically expands to show details and a regular expression pattern.

This query is a read-only query consuming the most server time in statistics

collected by ScaleArc so far. An example screen capture follows:

3. Click the Cache button (icon of a lightning bolt and disk) to open the Query

Pattern tool:

4. Choose a Time to Live (TTL) appropriate for this table. Note that even

short TTL values still yield significant improvement, so be conservative

when choosing this value.

5. Finally click the Add button. Verify the rule addition was successful.

Repeat these steps to add more queries as desired. Start with the top dozen busiest read-only queries. Add more query rules as analytics collects more data.

6.4 Verifying cache performance Verify the ScaleArc query cache is on by examining the cache hit rate. To do so, perform these steps:



1. Navigate to Live Monitor → Cluster Stats via the main menu.

2. Click on the cluster name.

3. Scroll to the middle pane showing the Cache Hit Rate.

4. Verify the hit rate is larger than zero as illustrated in the following example:

Recall that the Live Monitor display shows traffic observed over the past 30 seconds. If the cache hit rate is insufficient, repeat the steps outlined in Section 0, 6.3 Analytics drill down, to add more cache rules for increasing hit rate performance.

6.5 Cache rule application support Customers are encouraged to add cache rules only after consulting with ScaleArc product support. An application engineer will verify that caching a particular table is safe for a given application.

This support is offered to all licensed customers at no additional charge, including free trial customers. To obtain this service, visit ScaleArc’s support website. Please request assistance with cache rules for Magento in the ticket description.

7. Summary This guide documents step-by-step installation of an entire solution for sluggish Magento website performance by incorporating ScaleArc for MySQL as a database traffic manager. The documented solution involves multiple phases:

Install MySQL in replication mode for data integrity and reliability.

Install ScaleArc for MySQL for performance optimization.

Install Magento for store front management.

Tune ScaleArc performance and enable in-memory caching.

Internal testing shows that ScaleArc provides up to a 28x database performance boost to Magento sites and allows seamless database scaling of up to 10x, all without application or database change.

Have comments on ScaleArc or this solution guide? We’d love to hear from you. Contact us directly, connect via LinkedIn, visit our Facebook page, or follow us on Twitter.

https://scalearc.zendesk.com/anonymous_requests/new


http://www.linkedin.com/company/scalearc

https://www.facebook.com/ScaleArc

https://twitter.com/scalearc

https://twitter.com/scalearc



Appendix – Result set cache rules The following listing presents the read-only query result set cache rules employed during performance testing of our internal Magento test site. Note the time to live for each rule used was one minute.

Since each installation is different, please consult with ScaleArc customer support before adding any rule to the result set cache.

SELECT àttr_table`\.\* FROM `catalog_category_entity_varchar` AS

àttr_table` INNER JOIN èav_entity_attribute` AS `set_table`

ON attr_table\.attribute_id = set_table\.attribute_id AND

set_table\.attribute_set_id =

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*') WHERE

\(attr_table\.entity_id =

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\) AND

\(attr_table\.store_id IN \((([+-.]|)[0-9.]+), (([+-.]|)[0-

9.]+)\)\) UNION ALL SELECT àttr_table`\.\* FROM

`catalog_category_entity_text` AS àttr_table` INNER JOIN

èav_entity_attribute` AS `set_table` ON

attr_table\.attribute_id = set_table\.attribute_id AND


("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*') WHERE


("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\) AND



`catalog_category_entity_int` AS àttr_table` INNER JOIN




("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*') WHERE


("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\) AND



`catalog_category_entity_datetime` AS àttr_table` INNER JOIN




("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*') WHERE


("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\) AND



`catalog_category_entity_decimal` AS àttr_table` INNER JOIN




("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*') WHERE


("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\) AND


9.]+)\)\) ORDER BY `store_id` ASC



SELECT `catalog_product_entity_group_price`\.`value_id` AS

`price_id`,

`catalog_product_entity_group_price`\.`website_id`,

`catalog_product_entity_group_price`\.àll_groups`,

`catalog_product_entity_group_price`\.`customer_group_id` AS

`cust_group`, `catalog_product_entity_group_price`\.`value`

AS `price` FROM `catalog_product_entity_group_price` WHERE

\(entity_id=("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\) AND

\(website_id = (([+-.]|)[0-9.]+)\)

SELECT `catalog_product_entity_tier_price`\.`value_id` AS

`price_id`,

`catalog_product_entity_tier_price`\.`website_id`,

`catalog_product_entity_tier_price`\.àll_groups`,

`catalog_product_entity_tier_price`\.`customer_group_id` AS

`cust_group`, `catalog_product_entity_tier_price`\.`value` AS

`price`, `catalog_product_entity_tier_price`\.`qty` AS

`price_qty` FROM `catalog_product_entity_tier_price` WHERE

\(entity_id=("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\) AND

\(website_id = (([+-.]|)[0-9.]+)\) ORDER BY `qty` ASC

SELECT `catalogrule_product_price`\.`product_id`,

`catalogrule_product_price`\.`rule_price` FROM

`catalogrule_product_price` WHERE \(rule_date =

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\) AND \(website_id =

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\) AND

\(customer_group_id = ("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\)

AND \(product_id

IN\(("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\)\)

SELECT `core_url_rewrite`\.`product_id`,

`core_url_rewrite`\.`request_path` FROM `core_url_rewrite`

WHERE \(store_id = (([+-.]|)[0-9.]+)\) AND \(is_system =

(([+-.]|)[0-9.]+)\) AND \(category_id = (([+-.]|)[0-9.]+) OR

category_id IS NULL\) AND \(product_id

IN\(("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\)\) ORDER BY

`category_id` DESC

SELECT `core_url_rewrite`\.`product_id`,

`core_url_rewrite`\.`request_path` FROM `core_url_rewrite`

WHERE \(store_id = (([+-.]|)[0-9.]+)\) AND \(is_system =

(([+-.]|)[0-9.]+)\) AND \(category_id = (([+-.]|)[0-9.]+) OR

category_id IS NULL\) AND \(product_id

IN\(("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\)\) ORDER BY

`category_id` DESC

SELECT `core_url_rewrite`\.\* FROM `core_url_rewrite` WHERE

\(`core_url_rewrite`\.ìd_path`=("[^"]*(\"[^"]*)*"|'[^']*(\'[



^']*)*')\) AND \(store_id IN\((([+-.]|)[0-9.]+),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\)\) ORDER BY `store_id`

DESC LIMIT (([+-.]|)[0-9.]+)

SELECT `core_url_rewrite`\.\* FROM `core_url_rewrite` WHERE

\(request_path IN \(("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\)\) AND \(store_id

IN\((([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+)\)\)

SELECT `customer_entity_varchar`\.\* FROM

`customer_entity_varchar` WHERE \(entity_id

=("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\) UNION ALL SELECT

`customer_entity_int`\.\* FROM `customer_entity_int` WHERE

\(entity_id =("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\) UNION

ALL SELECT `customer_entity_datetime`\.\* FROM

`customer_entity_datetime` WHERE \(entity_id

=("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\)

SELECT `customer_group`\.\* FROM `customer_group` WHERE

\(`customer_group`\.`customer_group_id`=("[^"]*(\"[^"]*)*"|'[

^']*(\'[^']*)*')\)

SELECT è`\.\*, IF\(at_is_active\.value_id \> (([+-.]|)[0-9.]+),

at_is_active\.value, at_is_active_default\.value\) AS

ìs_active` FROM `catalog_category_entity` AS è` INNER JOIN

`catalog_category_entity_int` AS àt_is_active_default` ON

\(àt_is_active_default`\.èntity_id` = è`\.èntity_id`\)

AND \(àt_is_active_default`\.àttribute_id` =

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\) AND

àt_is_active_default`\.`store_id` = (([+-.]|)[0-9.]+) LEFT

JOIN `catalog_category_entity_int` AS àt_is_active` ON

\(àt_is_active`\.èntity_id` = è`\.èntity_id`\) AND

\(àt_is_active`\.àttribute_id` =

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\) AND

\(àt_is_active`\.`store_id` = (([+-.]|)[0-9.]+)\) WHERE

\(è`\.èntity_type_id` =

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\) AND

\(è`\.èntity_id`

IN\(("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\)\) AND

\(IF\(at_is_active\.value_id \> (([+-.]|)[0-9.]+),

at_is_active\.value, at_is_active_default\.value\) =

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\)

SELECT `main_table`\.àttribute_id`,

`main_table`\.èntity_type_id`,

`main_table`\.àttribute_code`,

`main_table`\.àttribute_model`,

`main_table`\.`backend_model`, `main_table`\.`backend_type`,

`main_table`\.`backend_table`,

`main_table`\.`frontend_model`,

`main_table`\.`frontend_input`,

`main_table`\.`frontend_label`,

`main_table`\.`frontend_class`, `main_table`\.`source_model`,



`main_table`\.ìs_required`, `main_table`\.ìs_user_defined`,

`main_table`\.`default_value`, `main_table`\.ìs_unique`,

`main_table`\.`note`, àdditional_table`\.ìs_visible`,

àdditional_table`\.ìnput_filter`,

àdditional_table`\.`multiline_count`,

àdditional_table`\.`validate_rules`,

àdditional_table`\.ìs_system`,

àdditional_table`\.`sort_order`,

àdditional_table`\.`data_model`, `scope_table`\.`website_id`

AS `scope_website_id`, `scope_table`\.ìs_visible` AS

`scope_is_visible`, `scope_table`\.ìs_required` AS

`scope_is_required`, `scope_table`\.`default_value` AS

`scope_default_value`, `scope_table`\.`multiline_count` AS

`scope_multiline_count` FROM èav_attribute` AS `main_table`

INNER JOIN `customer_eav_attribute` AS àdditional_table` ON

additional_table\.attribute_id = main_table\.attribute_id

LEFT JOIN `customer_eav_attribute_website` AS `scope_table`

ON scope_table\.attribute_id = main_table\.attribute_id AND

scope_table\.website_id =

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*') WHERE

\(main_table\.entity_type_id =

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\)

SELECT `main_table`\.òption_id` FROM

`catalog_product_bundle_option` AS `main_table` LEFT JOIN

`catalog_product_bundle_option_value` AS

òption_value_default` ON main_table\.option_id =

option_value_default\.option_id and

option_value_default\.store_id = (([+-.]|)[0-9.]+) LEFT JOIN

`catalog_product_bundle_option_value` AS òption_value` ON

main_table\.option_id = option_value\.option_id and

option_value\.store_id =

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*') WHERE

\(main_table\.parent_id =

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\)

SELECT `main_table`\.\* FROM `design_change` AS `main_table`

WHERE \(store_id = ("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\)

AND \(date_from \<= ("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*') or

date_from IS NULL\) AND \(date_to \>=

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*') or date_to IS NULL\)

SELECT `main_table`\.\*, àdditional_table`\.\*,

èntity_attribute`\.\*, IFNULL\(al\.value,

main_table\.frontend_label\) AS `store_label` FROM

èav_attribute` AS `main_table` INNER JOIN

`catalog_eav_attribute` AS àdditional_table` ON

additional_table\.attribute_id = main_table\.attribute_id

INNER JOIN èav_entity_attribute` AS èntity_attribute` ON

entity_attribute\.attribute_id = main_table\.attribute_id

LEFT JOIN èav_attribute_label` AS àl` ON al\.attribute_id =

main_table\.attribute_id AND al\.store_id = (([+-.]|)[0-9.]+)

WHERE \(main_table\.entity_type_id=(([+-.]|)[0-9.]+)\) AND



\(entity_attribute\.attribute_set_id =

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\) ORDER BY sort_order

ASC

SELECT `main_table`\.\*, òption_value_default`\.`title` AS

`default_title`, IF\(option_value\.title IS NOT NULL,

option_value\.title, option_value_default\.title\) AS `title`

FROM `catalog_product_bundle_option` AS `main_table` LEFT

JOIN `catalog_product_bundle_option_value` AS

òption_value_default` ON main_table\.option_id =

option_value_default\.option_id and

option_value_default\.store_id = (([+-.]|)[0-9.]+) LEFT JOIN

`catalog_product_bundle_option_value` AS òption_value` ON

main_table\.option_id = option_value\.option_id and

option_value\.store_id =

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*') WHERE

\(main_table\.parent_id =

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\) ORDER BY

`main_table`\.`position` asc, `main_table`\.òption_id` asc

SELECT `main_table`\.\*, `tdv`\.`value` AS `default_value`,

`tsv`\.`value` AS `store_default_value`, IF\(tsv\.value_id \>

(([+-.]|)[0-9.]+), tsv\.value, tdv\.value\) AS `value` FROM

èav_attribute_option` AS `main_table` INNER JOIN

èav_attribute_option_value` AS `tdv` ON tdv\.option_id =

main_table\.option_id LEFT JOIN èav_attribute_option_value`

AS `tsv` ON tsv\.option_id = main_table\.option_id AND

tsv\.store_id = ("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*') WHERE

\(attribute_id = ("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\) AND

\(tdv\.store_id = (([+-.]|)[0-9.]+)\) ORDER BY

main_table\.sort_order ASC, value ASC

SELECT `review_entity_summary`\.\* FROM `review_entity_summary`

WHERE

\(`review_entity_summary`\.èntity_pk_value`=("[^"]*(\"[^"]*)

*"|'[^']*(\'[^']*)*')\) AND \(store_id = (([+-.]|)[0-9.]+)\)

SELECT `sales_flat_quote`\.\* FROM `sales_flat_quote` WHERE

\(`sales_flat_quote`\.èntity_id`=("[^"]*(\"[^"]*)*"|'[^']*(\

'[^']*)*')\) AND \(store_id IN

\(("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\)\) AND \(is_active =

(([+-.]|)[0-9.]+)\)

SELECT `t_d`\.èntity_id`, `t_d`\.àttribute_id`, `t_d`\.`value`

AS `default_value`, `t_s`\.`value` AS `store_value`,

IF\(t_s\.value_id IS NULL, t_d\.value, t_s\.value\) AS

`value` FROM `catalog_category_entity_varchar` AS `t_d` LEFT

JOIN `catalog_category_entity_varchar` AS `t_s` ON

t_s\.attribute_id = t_d\.attribute_id AND t_s\.entity_id =

t_d\.entity_id AND t_s\.store_id = (([+-.]|)[0-9.]+) WHERE

\(t_d\.entity_type_id = (([+-.]|)[0-9.]+)\) AND

\(t_d\.entity_id IN \((([+-.]|)[0-9.]+), (([+-.]|)[0-



9.]+)\)\) AND \(t_d\.attribute_id IN

\(("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\)\) AND \(t_d\.store_id

= (([+-.]|)[0-9.]+)\) UNION ALL SELECT `t_d`\.èntity_id`,

`t_d`\.àttribute_id`, `t_d`\.`value` AS `default_value`,

`t_s`\.`value` AS `store_value`, IF\(t_s\.value_id IS NULL,

t_d\.value, t_s\.value\) AS `value` FROM

`catalog_category_entity_datetime` AS `t_d` LEFT JOIN

`catalog_category_entity_datetime` AS `t_s` ON




\(t_d\.entity_id IN \((([+-.]|)[0-9.]+), (([+-.]|)[0-

9.]+)\)\) AND \(t_d\.attribute_id IN

\(("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\)\) AND \(t_d\.store_id





`catalog_category_entity_text` AS `t_d` LEFT JOIN

`catalog_category_entity_text` AS `t_s` ON t_s\.attribute_id

= t_d\.attribute_id AND t_s\.entity_id = t_d\.entity_id AND

t_s\.store_id = (([+-.]|)[0-9.]+) WHERE \(t_d\.entity_type_id

= (([+-.]|)[0-9.]+)\) AND \(t_d\.entity_id IN \((([+-.]|)[0-

9.]+), (([+-.]|)[0-9.]+)\)\) AND \(t_d\.attribute_id IN

\(("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\)\) AND

\(t_d\.store_id = (([+-.]|)[0-9.]+)\) UNION ALL SELECT

`t_d`\.èntity_id`, `t_d`\.àttribute_id`, `t_d`\.`value` AS

`default_value`, `t_s`\.`value` AS `store_value`,


`value` FROM `catalog_category_entity_int` AS `t_d` LEFT JOIN

`catalog_category_entity_int` AS `t_s` ON t_s\.attribute_id =

t_d\.attribute_id AND t_s\.entity_id = t_d\.entity_id AND




\(("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\)\) AND

\(t_d\.store_id = (([+-.]|)[0-9.]+)\)




`value` FROM `catalog_product_entity_varchar` AS `t_d` LEFT

JOIN `catalog_product_entity_varchar` AS `t_s` ON




\(t_d\.entity_id IN \((([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+),

(([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+),

(([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+),

(([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+),

(([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+),



(([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+)\)\)

AND \(t_d\.attribute_id IN

\(("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\)\) AND \(t_d\.store_id





`catalog_product_entity_decimal` AS `t_d` LEFT JOIN

`catalog_product_entity_decimal` AS `t_s` ON




\(t_d\.entity_id IN \((([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+),

(([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+),

(([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+),

(([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+),

(([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+),

(([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+)\)\)


\(("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\)\) AND \(t_d\.store_id





`catalog_product_entity_int` AS `t_d` LEFT JOIN

`catalog_product_entity_int` AS `t_s` ON t_s\.attribute_id =




9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-

9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-

9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-

9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-

9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-


\(("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\)\) AND \(t_d\.store_id






t_d\.value, t_s\.value\) AS `value`




`value` FROM `catalog_product_entity_varchar` AS `t_d` LEFT

JOIN `catalog_product_entity_varchar` AS `t_s` ON




\(t_d\.entity_id IN \((([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+),

(([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+),

(([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+),

(([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+),

(([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+)\)\)


\(("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\)\) AND \(t_d\.store_id





`catalog_product_entity_decimal` AS `t_d` LEFT JOIN

`catalog_product_entity_decimal` AS `t_s` ON



\(t_d\.entity_type_id = (([+-.]|)[0-9.]+)\) AND \(t_d\.entity_id

IN \((([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+),

(([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+),

(([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+),

(([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+),

(([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+)\)\) AND

\(t_d\.attribute_id IN

\(("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\)\) AND \(t_d\.store_id





`catalog_product_entity_int` AS `t_d` LEFT JOIN

`catalog_product_entity_int` AS `t_s` ON t_s\.attribute_id =






9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-

9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-

ScaleArc is the leading provider of database load balancing software. The ScaleArc software inserts transparently between applications and databases, creating an agile data tier that provides continuous availability and increased performance for all apps. With ScaleArc, enterprises also gain instant database scalability and a new level of real-time visibility for their application environments, both on prem and in the cloud. Learn more about ScaleArc, our customers, and our partners at www.ScaleArc.com.

© 2015 ScaleArc. All Rights Reserved. ScaleArc and the ScaleArc logo are trademarks or registered trademarks of ScaleArc in the United States and other countries. All brand names, product names, or trademarks belong to their respective holders.

01/07/15

2901 Tasman Drive, Suite 205 Santa Clara, CA 95054 Phone: 1-408-780-2040 Fax: 1-408-427-3748 www.scalearc.com


9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+),

(([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+), (([+-.]|)[0-9.]+), (([+-

.]|)[0-9.]+)\)\) AND \(t_d\.attribute_id IN

\(("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*'),

("[^"]*(\"[^"]*)*"|'[^']*(\'[^']*)*')\)\) AND \(t_d\.store_id =

(([+-.]|)[0-9.]+)\) UNION ALL SELECT `t_d`\.`entity_id`,




`catalog_product_entity_text` AS `t_d

SELECT `wishlist`\.\* FROM `wishlist` WHERE

\(`wishlist`\.`customer_id`=(([+-.]|)[0-9.]+)\) ORDER BY

`wishlist_id` ASC LIMIT (([+-.]|)[0-9.]+)

http://www.scalearc.com/

http://www.scalearc.com/

Magento Deployment Guide - ScaleArc · Magento Deployment Guide: Installing, Tuning, and Using...

Documents

Transcript of Magento Deployment Guide - ScaleArc · Magento Deployment Guide: Installing, Tuning, and Using...