Tuesday, May 14, 2013

OXID Commons 2013

Nice to be here in Freiburg, and make last preparation for my presentation in OXID Commons. More information you can find there: http://www.oxid-commons.de

Tuesday, March 12, 2013

Prepare your extensions for Master - Slave

As you already know, since OXID eShop v5.0 (enterprise edition) shop supports MySQL Master-Slave replication. This feature is a part of OXID eShop performance boost packet for high load scenario, which also include: cache backend for Memcached, and tools for reverse proxy - Varnish. In this post I shortly explain this feature’s benefits and how prepare your custom extensions for your own shop or how should be updated your commercial modules stored on OXID eXchange.

What Master-Slave gives?


With Master-Slave you are able increase your shops scalability. As said in mysql.com: "Better response time for clients can be achieved by splitting the load for processing client queries between the master and slave servers. SELECT queries may be sent to the slave to reduce the query processing load of the master." So if database is bottleneck of your system use Master-Slave replication and most of data selection queries redirect to slaves. About 90% of the shop queries are selects, so this load can be easily spread to one or more slave servers.

How it is done?


The best practice how to implement this feature is to separate call for data selection and management (insert, update, delete) to separate function. OXID did it in more simple way, but the used concept is the same.
All call to data base are the same as in previous version, we just added addition parameter for methods used for selecting data. For example:

oxDb::getDb()->getOne('select some data', array(), true);

This third parameter tell, where query should go to master or slave: true - slave, false - master. By default this parameter is true, so by default all select queries goes to slave. If master-slave feature is not configured this parameter no make sense. Methods such as execute() or query(), have no this parameter, so they should be used for insert, update or delete queries.

How prepare your extensions?


All your extensions are already prepared! If you properly use function mentioned above, you do not need any change, except situations, where you know that data select goes together with update, delete or insert. In general you should follow these recommendations:
  • For all your selects use: getAll(), getOne(), getRow(), getCol() etc. methods;
  • For insert, update and delete queries use execute() method; 
  • In situation where data must be selected from master use third parameter with value false;

That's all, be prepared!