Jump to content

Edit History

J. Jackson

J. Jackson

I appreciate the suggestions, however disk I/O wasn't any part of the issue. Any software which fires 450 queries at the database server and consumes 1.5GB of RAM per visitor to display a product detail page has flaws that storage performance and database configuration tweaks won't solve. This was the results of the profiling done against the default install of PrestaShop with their catalog loaded. I submitted a pull request to deal with some of the initial memory issues I ran into, but the query counts are inherent in the way Presta's code is written. Some of these issues can be partially mitigated by reducing the functionality of the site, but that was honestly the initial appeal of using Presta.

In this case, I am the agency working with the customer to update their site / software. I have years of experience in database administration, working with systems much larger than 3.4 million records. Some of my other customers have databases with billions of records and terabytes of data. They, however, are in the tech industry, not the lawn equipment industry.

This was merely a test case for PrestaShop as it might have been a simple solution for their shop. The test systems used to initially profile the software had NVMe storage, hundreds of gigabytes of RAM available, and each test instance could be allocated dozens of cores if needed. However, the target hosting platform can not contain these sorts of specs as it is cost prohibitive to allocate such resources... unless self or co-locating the hosting. They do not have the technical resources for this.

As mentioned previously, the solution ultimately chosen was to create a custom site. The resulting code and software have no problems querying the customer's catalog on much more modest hardware platforms.

This is not a knock on PrestaShop. As I mentioned, I really enjoy the software and have used it for other projects. It just wasn't a good fit for this particular customer's needs. There is no such thing as a truly one size fits all e-Commerce solution. Aside from the size of the catalog, their needs included things like large supersession chains, product substitution lists, and the ability to lookup no longer available parts for cross referencing. These are not part of Presta's base functionality and would have required additional custom modules to be written. There were simply too many modifications needed to make it suit the purpose of the site.

J. Jackson

J. Jackson

I appreciate the suggestions, however disk I/O wasn't any part of the issue. Any software which fires 450 queries at the database server and consumes 1.5GB of RAM per visitor to display a product detail page has flaws that storage performance and database configuration tweaks won't solve. This was the results of the profiling done against the default install of PrestaShop with their catalog loaded. I submitted a pull request to deal with some of the initial memory issues I ran into, but the query counts are inherent in the way Presta's code is written. Some of these issues can be partially mitigated by reducing the functionality of the site, but that was honestly the initial appeal of using Presta.

In this case, I am the agency working with the customer to update their site / software. I have years of experience in database administration, working with systems much larger than 3.4 million records. Some of my other customers have database with billions of records and terabytes of data. They, however, are in the tech industry, not the lawn equipment industry.

This was merely a test case for PrestaShop as it might have been a simple solution for their shop. The test systems used to initially profile the software had NVMe storage, hundreds of gigabytes of RAM available, and each test instance could be allocated dozens of cores if needed. However, the target hosting platform can not contain these sorts of specs as it is cost prohibitive to allocate such resources... unless self or co-locating the hosting. They do not have the technical resources for this.

As mentioned previously, the solution ultimately chosen was to create a custom site. The resulting code and software have no problems querying the customer's catalog on a much more modest hardware platforms.

This is not a knock on PrestaShop. As I mentioned, I really enjoy the software and have used it for other projects. It just wasn't a good fit for this particular customer's needs. There is no such thing as a truly one size fits all e-Commerce solution. Aside from the size of the catalog, their needs included things like large supersession chains, product substitution lists, and the ability to lookup no longer available parts for cross referencing. These are not part of Presta's base functionality and would have required additional custom modules to be written. There were simply too many modifications needed to make it suit the purpose of the site.

×
×
  • Create New...