About the way product image files are stored in PrestaShop

Indeed, saving all the product image files of the online store into a single directory is not the most convenient, especially if it is a very extensive product catalog.

Nowadays, thanks to product importers like PrestaImport, it is not necessary to enter them by hand, and we can find stores with thousands of products for sale. But let's take, as an example, a not exaggerated number of products: 333. Assuming that each product has, for say, 3 images, that's 999 images, and taking into account that PrestaShop saves each image in 5 different sizes (more or less, depending on the theme), plus the original, that's 6 files per each image, making a total of 5,994 image files.

Taking into account that from 500 files in the same directory the performance of the hard disk suffers, it is a good idea to try to organize those 5,994 image files in subfolders. And so on, the PrestaShop development team planned something about that, at the beginning of the 1.4 series.

However, the method they adopted has become an example of shit in decision making within software engineering.

It was decided organize the image files this way:

Each image is registered in the database with an unique identifier, which is an integer. Well, this number is used as a guide to determine at what directory save the (6) files corresponding to the image in question, plus an index.php file that PrestaShop puts to prevent the url corresponding to that subdirectory from being visited directly. The identifier is broken down into digits and for each digit a subdirectory is entered, creating it if it does not exist.

For example, to the image id.1 we got the subdirectory 1/, to image id.11, the subdirectory 1/1/, and to the image id.111, the subdirectory 1/1/1/. Or to image id.352, the subdirectory 3/5/2/. As you can see, foreach digit there ir a depth level in the directory tree.

So far good, but, no one thought of it make accounts? Didn't they see that an excessive number of directories could be created? Maybe you are wondering "well, what's the problem?". I'm going to tell you. To start with, try downloading or uploading via FTP product images from a PrestaShop store. It's exasperating, because for each directory change, you have to send a request to the server, and, even if it's not an excessive number of images (in our example, 999), it's very slow. But this is not the main problem.

Let's do the math first. We have 999 images, whose identifiers are correlative, starting with one up to 999. Inside the img/p/ folder, for PrestaShop product images, will have 9 folders, called from 1 to 9 (there is no zero folder because the image with zero identifier does not exist). Inside each of those 9 folders, we will have 10 folders, called from 0 to 9 (there is folder zero that would correspond to image identifier 10, 20,...), and inside of each one of that 10 folders, another 10 folders called from 0 to 9. So, the directories needed to store the files of those 999 images are: 9 * 10 * 10 = 900 directories. And those directories will have a total of 999 * (6 + 1) = 6,993 files (999 images by 7 files, that are 6 .jpg files plus the index.php file).

Ok, until there we're still well, but let's stretch the thing a little, let's say 3333 products instead of 333. Then, there will be 9999 images (3 by product), which would result in 9 * 10 * 10 * 10 = 9,000 directories, and 9999 * 7 = 69,993 files. This supposes a consumption of 9,000 + 69,993 = 78,993 inodes in hard disk. But, what is an inode?

The inodes are the total of directories and files existing in the disk unit. And there is a limit, first determined by the unit itself, but in shared web hosting and virtual servers, an arbitrary limit is usually set, since it is understood that excessive inode consumption affects disk performance. You can find limits of 100,000, 215,000, 430,000,... If your hosting is a dedicated server, we will be talking about a limit of several million inodes, but the fact is that most of those who set up a PrestaShop online store do not have that capacity, and face lower limits.

There are stores that have thousands of products, for example, catalogs of an average of 5,000 products are being imported, thanks to PrestaImport, and we are seeing that the consumption of inodes grows exponentially with the number of images, with which it is very easy to reach the limit of inodes imposed by the hosting provider. Also don't forget that product images are not the only thing on the disk. I have seen a limit of one and a half million inodes being overflowed by a PrestaShop store with 40,000 products and 110,000 product images.

The effect of exhausting the available inodes is that you will not be able to create new directories or files on the disk, trying to do so will fail, resulting a disk full error, even though we actually have several gigabytes of free space. And, of course, in this situation the website (and our hosting) is practically unusable.

Sometimes the limits imposed by hosting providers are too low, especially compared to other hosting features, such as disk space or transfer, but that does not mean that the PrestaShop development team may have devised a much less "generous" method with inode consumption. For example, simply following the same idea, but using the product identifier instead of the image identifier to determine the directory where to save the files, you would already be reducing consumption considerably. Each product would correspond to a directory, where all the files of its images would be inserted, instead of a directory for each image. We would be saving in directories, and in files (because of the index.php ones that would not be created).

Of course, the image files have to exist, there is no saving on that, so if you are going to set up a store with PrestaShop and put a large number of products on sale, choose your hosting well. In addition, this is just one example of the consumption and performance problems of the PrestaShop online store system, which, despite all this, is great and I recommend it, but always knowing everything that must be taken into account.