[FIXED][Admin] Slow loading of products

Hello, I realize it is a very old topic, but I'm having exactly the same problem. I'm using OpenCart version 1.5.6.4, have 450 products in the store, but over 3000 option values. Most of the products have no more than 6 option values per product, but the page takes very much time to load, more than 3 minutes when I try to edit the product. Is there some fix for this?

I replied to this here:

http://forum.opencart.com/viewtopic.php ... 15#p515615

Ernie
openshop.li

It doesn't have to due with DB. This is a pure client side issue regarding how a browser can display a webpage with the resources available (CPU/RAM) on your pc. We have products with thousands of option rows so customers are able to pick a size and fraction.

The issue comes from compounding: (product option rows) multiplied by (total amount of values in the "option set") makes (X amount of extra lines of source code).

Lets use an example of options dropdowns using 1 through 60 inches with 1/16 inch fractions between each inch. This means that every dropdown is 960 values multiplied by 960 option rows multiplied by 2 for L x W options. The total render for option values in dropdowns? 1.843 million. The total size for product admin page source code? 60+ megabytes. Total lines in the source? Perhaps millions....

We have not found a solid solution yet, but the theory would be to load options as select box dropdowns ONLY when adding a new row or modifying an existing row. The latter modify function would load+save it with ajax and go right back to "non dropdown" for the row. This would cut the render of select rows down from 1.8million to 1,920 in the case of 2 length by width using 1 to 60 inches.

Dont believe me? We saved a static page using many options. It doesnt use OpenCart, PHP, or DB to make the page....its just a rough capture of a large product edit admin. Paste the following into Chrome and use the network timer to see its size.

view-source:https://src.creadev.org/apps/oc-src-tes ... ource.html

Its not even complete, it cuts off at line 175,779 so thats why tabs and stuff dont work on that page if you view it normally. Hope that makes sense! Hope even more that we can hash out a solution.

sorry, somehow overlooked the 'select option' volume. Could, by calling a 'premade', cached product-page, by use of the thing, published a short while ago here, the Page SERVING-process possibly be influenced positively !? Or is it just the Browser itself, acting as brake?

Ernie

Its ok man, it seems like a DB thing. Its really just the browser itself for the most part. PHP/DB uses a bit more CPU to parse the page, but the real slowness, freezing, and page crashing comes from the insane huge source code. It would save tons of resources client side if there was any method to make the options-saved rows *not* render the select boxes until you need to edit one to change the value for that row.

Pagination of the options rows could help too, but it would get tedious looking for something that may not be sorted alphabetically (due to sort order on option values). Either way it would need to load with JS, so the row method above seems more fluid.

In tests, workstations with good CPU + 8GB ram barely render that source. Even if its rendered, their lies another challenge: product edit pages use javascript to post back changes. If you try to save one of these pages on a weak machine that barely displays page, it may crash/halt during AJAX trying to put back thousands of option rows. This corrupts the product or leaves it half saved.

A solution in the meantime is to not use the admin interface when making mega products like this. Instead use a good CSV/XLS spreadsheet import-export tool and create the options that way. It stinks to use import, but it is actually faster until this issue is fixed up.

Dhaupin wrote:Lets use an example of options dropdowns using 1 through 60 inches with 1/16 inch fractions between each inch. This means that every dropdown is 960 values multiplied by 960 option rows multiplied by 2 for L x W options. The total render for option values in dropdowns? 1.843 million. The total size for product admin page source code? 60+ megabytes. Total lines in the source? Perhaps millions....

We have not found a solid solution yet, but the theory would be to load options as select box dropdowns ONLY when adding a new row or modifying an existing row. The latter modify function would load+save it with ajax and go right back to "non dropdown" for the row. This would cut the render of select rows down from 1.8million to 1,920 in the case of 2 length by width using 1 to 60 inches.

Why not separate out inches and fractions of an inch into two separate options? That way you have 76 options (60 + 16) instead of 960. Otherwise it would be a good case to implement customization like a slider or a text box with autocomplete and validation. People usually don't want to deal with dozens or hundreds of options.

Yeah agree its just an example. Splitting fractions out makes it cleaner, but with complex "ranged" grids where prices change randomly between the inch, and are dependent on eachother, its easier to make logic with 2 routes through the choices rather than 4+. Hopefully can figure out a way to sell L x W ranged fractional stuff better. In the meantime this is the crux with large sets of options and many rows