Configure an e-commerce Site in a High-traffic, Distributed Environment.
Configure ecommerce Site
High-traffic sites require more than a single machine.
You can divide the e-commerce software components among several machines to distribute the load and improve performance. This activity is known as load balancing.
A multimachine configuration has the following:
A router to divide requests and balance the load between machines.
A single domain name used by all machines (for example, www1.mall.com and www2.mall.com).
Multiple instances of the e-commerce software, each on a separate machine.
A single instance of the payment gateway, installed on only one of the e-commerce software machines. This single instance is necessary to prevent corruption of payment data that might arise from multiple instances of payment gateways.
A single database and database management system (DBMS) on its own machine.
Cluster servers and special third-party software to distribute the load evenly.
Multiple machines, with the load balanced between them, allow performance to be improved so that almost any amount of traffic can be managed. Each instance of e-commerce software stores its information in the same remote database (via Open DataBase Connectivity, ODBC) so that the information presented by each machine is consistent across the site.
If only two machines are available, the simplest multimachine configuration is to place the e-commerce software engine and payment gateway on one machine and to place the DBMS and the database on another. In such a configuration, a router is not necessary.
Staging server configuration
You should never test on your production server.
Create a "staging server" where you can test database updates and site customizations.
This configuration has:
Two domain names (with separate IP addresses), one for the production server and one for the staging server
Two instances of e-commerce software
Two databases: the production database and the staging database
Machine configurations and Staging server Considerations
When creating a staging server, you can copy the product and store data from the production database to the staging database, and then propagate updates back to the production database. Similarly, you can copy stored Web pages and macros from the production site to the staging site and copy updates back to the production site. Thus, updates can be fully tested before being released to the public.
Note that customer and order information is not copied to the staging server, thereby reducing the chance that this critical information will
be stolen, lost, or corrupted. Finally, your staging server probably does not need to include a payment gateway.
In the next lesson, we will discuss legacy integration.