10 super efficient ways to boost your data management...

Applicable to : Merlin Backoffice ™, PrestaPricing and PrestaCategorie addons (tuto and screen shots made with PrestaPricing)

The speed of sending and processing of SQL queries

For added security, HTTP requests (containing mySQL queries themselves) can be encrypted. This has a cost in terms of performance, encryption and especially server-side decryption takes a lot of time, doubling the total execution time of a query.

So our Tip # 1, looking for the best performance, is to uncheck this option in the application's login window:

The time of reading of the data returned by the server

For the same security reasons, the data read from the database and returned by the server can either be compressed or encrypted. One can think that the compression, since it reduces the volume of the data, accelerates this transfer. This is true sometimes, but it does not take into account the fact that compression and decompression take time, and that often the balance is negative.

Our advice N ° 2, if you are ready to acquire a little security in favor of a greater fluidity, is to choose the mode "Ni encrypted nor compressed":

Accelerate the loading time of the categories

It is possible, if not strongly recommended, to choose the new category loading mode, called progressive loading.

With the old mode, which will disappear, except for versions of PrestaShop 1.2 and 1.3, all categories are read in the database at launch and displayed. If this proves practical when the number of categories is reasonable (less than 300), it becomes really slow beyond several thousand.

With Progressive loading mode, only the first level of categories is read, loaded into memory and displayed. Sub-categories are displayed when you need them. On very large sites (30,000 categories and more), it is up to 20 minutes to win at the launch.

Our advice N ° 3 is therefore to systematically opt for the new mode, when the program offers you this choice. To check or change your previous choice check this option:

This opens this window at the time of the connection, so opt for the progressive loading mode, much faster:

Limit the number of lines displayed per page

These tools have the ability to work on several hundred thousand products or declinations at the same time. If you had to do the same using PrestaShop administration, it would take you years, so the time saving is phenomenal. But this is not a reason not to be effective.

Processing times have the unfortunate mania of increasing exponentially with the number of lines. That is to say that the processing of 5000 lines is not 5 times but 10 to 20 times slower than the processing of 1000 lines.

To keep a certain fluidity and avoid long waiting times, it becomes essential to work page by page, with for each page a reasonable number of lines (which I estimate to be 5000 maxi).

This is possible thanks to the paginators (and to the super paginator who fixes the high limit of adjustment of the paginators):

See this other tutorial explaining the use of these paginators

Limit the number of columns and choose them well

This advice may seem obvious to you, so much the better. But we still see so many users who work with all the columns displayed, more than 90 for the product tables.

There's nothing like it to kneel your server, with hyper complex queries and massive data volumes.

To gain fluidity, you really have to get used to checking only the columns you really need.

On the other hand, not all columns (or rubrics of the database) are worth, some require more resources and server power than others. Sitolog helps you in your choices, the columns with a negative influence on the speed are indicated. The more you select and the more you wait:

In addition, some of the columns indicated "hyper slow" are more so because several of them are checked. Avoid using more than one of these columns at a time. The fact that 3 or more of this type of items are requested can even cause the poorer servers to be crashed into the memory and CPU resources.


Note: in the future version (second half of 2017) of your favorite modules, the columns will be chosen using a new "column configurator", the columns having an impact on the loading speed of the pages will be indicated by pictograms Slow: -, very slow: - or hyper slow: ---):

Use the column configurator

Because it is important to display only the columns that are essential to a given job, the use of pre-settings or "column configuration" allows you to switch between columns with a single click. Why deprive yourself.

In addition you have that of a simple right click in the list, you can name your configurations?

Coming soon, the new configurator allows to create an unlimited number of column configurations (instead of 6 at the moment), using drag and drop to choose the columns and to reorder them. It is also possible to choose the titles displayed in the tables and their width:

Limit the number of tables "switched on"

A "switched on" table is a table whose data is displayed and which automatically refreshes when the parent table is refreshed or changes rows.

For example, the declination table, if it is triggered, will be refreshed automatically when a product is selected in the table of products. This means that requests to read the declination data will be sent to the database and processed. So much time lost if you do not especially need to see the declensions.

If several tables are triggered, for example, declinations, the translation table, and even worse, images, the time required to display the products of a declination can increase considerably.

In summary, consider unlinking all tables you no longer need as the data is displayed. You will see, you will gain another crazy time.

The tables are activated when their "Gear" button (may be replaced by an "eye" icon) is pressed (orange background):

Uncheck the option "Line counters"

A tricky thing to know, the calculation of the number of rows and totals for some columns, although practical, can go as far as doubling the refresh time of pages and tables. So unless you really need it, we strongly advise you to uncheck this option if the refresh rate is your primary goal:

Use pre-filters instead of column filters.

Houla you say, it gets complicated ... courage is almost at the end.


A pre-filter is a filter limiting the number of rows returned by the SQL queries. It acts directly at the level of the requests itself (is written in mySQL). It is therefore particularly efficient, fast and can significantly reduce the volume of data sent by the server, thus increasing the overall display speed.

There are pre-filters all ready, on manufacturers or suppliers for example and two pre-filters fully customizable. A tutorial will be devoted to them soon:

A column filter, on the other hand, acts downstream, once the data is received from the server and displayed in the table, just to hide some lines. It therefore saves no time:

Avoid unnecessarily rereading categories when you change languages

When working on products and wanting to switch from one language to another, it is often unnecessary to refresh the category tree.

A small option to check, little known, allows to make this choice. Check this option and the categories will remain displayed in the current language when you choose another language to display the products:

Two other settings should also be deactivated: product counters in categories tree (new in V 2.3.4) and gauge display.

These two display options have a major impact on table display speeds. No, delete the association if possible (see tooltip).