• Hi,

    I bought this plugin some weeks ago. Loaded 300+ items and I saw all the catalogue go slow. Very slow.

    Right now, if i click on catalogue page it takes more than 13s till the full page loads. It happens too if I try to filter, even if I do it by clicking in a subcategory with only 3 items. In fact, all the imports for the initial catalogue are much faster than showing any item in list.

    Tried by changing from 30 to 18 to 9 items per page with no impact at all, and also checked options and disabled all those i think i don’t need (right now i can only filter by name field).

    Am i missing something?

    Thank you!

Viewing 7 replies - 1 through 7 (of 7 total)
  • Hi swdevagm,

    First, make sure the “Product Search” option (in the “Basic” area of the “Options” tab) isn’t set to “Name, Description and Custom Fields”. The custom fields part adds a lot of queries, which has the potential to slow it down. Try any of the other options.

    Also, try removing two of the three layouts. For example: [product-catalogue id=”X” excluded_layouts=”Detail,List” starting_layout=”Thumbnail”]. This will cut the amount of queries by two-thirds.

    You can also try enabling “Thumbnail Support” (in the “Basic” area of the “Options” tab).

    There is also the possibility that your server doesn’t process the database queries quickly, which wouldn’t help with the catalogue performance.

    Thread Starter swdevagm

    (@swdevagm)

    Hi,

    I’ve tried removing layouts but it didn’t make the difference. Product Search was already on “Name” and “Thumbnail Support” is the initial set up for my catalogue.

    Checked database. All plugin tables with no index (just PK on id…). Is that possible? Has someone tried to use this plugin with more than 20 items as shown in demo?

    Thread Starter swdevagm

    (@swdevagm)

    Hi again,

    Sorry if this message sounds disgusting for you. I’m started to think I wasted last weeks with this plugin and right now I have to give a solution to a customer with a plugin that just doesn’t work fine.

    NO INDEX was a thing (very serious by the way), but after creating them the problem of slow catalogue is still there. So the problem must come from the programming.

    I’ve been checking the source code of the Insert_Product_Catalog function. No way this plugin works with more than 20 items as I said.
    Filtering is about removing some data BEFORE doing all the work, not about doing ALL the work and after getting all data removing on filters…

    BIG EXAMPLE:
    if ($CatalogueItem->Item_ID != “” and $CatalogueItem->Item_ID != 0) {
    $Product = new UPCP_Product(array(“ID” => $CatalogueItem->Item_ID));
    $ProdTagObj = $wpdb->get_results(“SELECT Tag_ID FROM $tagged_items_table_name WHERE Item_ID=” . $CatalogueItem->Item_ID);
    $Prod_Custom_Fields = $wpdb->get_results(“SELECT Field_ID, Meta_Value FROM $fields_meta_table_name WHERE Item_ID=” . $Product->Get_Item_ID());
    if ($Product->Get_Field_Value(‘Item_Display_Status’) != “Hide”) {

    WHAT? So you’re telling me I’ve wasted 3 different querys (at least…) just to avoid processing 1 hidden item? Filter should be in the query on database, not in PHP… Why am I processing item to get the tags and custom fields if the item is just hidden? So if i have 25 hidden items i lose 50 querys just to keep going….

    Right now I have 1 catalog with 310 items. Showing 15 per page. How can you explain the database is querying and proccessing all items even when the first 15 records where already available to show? And… why?

    How can you explain 300 * 5 querys (at least) executing everytime I do a click?
    There’s no serverside problem, it’s a CODE problem, all filters and pagination are made on PHP side after getting all data every time… there’s no way this plugin work fine with more than 20 items because you are not using WHERE…

    As I said, I’m very dissapointed with the plugin. I feel so cheated.

    The querying is set up as required for the functionality of our plugin and has been optimized as much as possible with this in mind. The queries that are used after reaching 15 items are required to know which products meet the criteria of the search, so that the counts in the sidebar can be updated and categories, etc. without any matching products can be greyed out.

    That being said, it’s a good point about the item_display_status. We’ll take a look to switch that around.

    It definitely works with more than 20 products. There are people who use the catalog with hundreds of products. For example: https://www.terrytew.co.uk/hire/. And we’ve tested it with many more than that. Could you send us a link to your catalog, so we can check the console, etc.?

    Thread Starter swdevagm

    (@swdevagm)

    You can’t tell me querying is optimized as much as possible. Is just a lie and you shouldn’t lie here.

    Example optimized query system
    SELECT ***** FROM Items (JOIN DATA FOR FILTERING) WHERE (Filters)
    ForEach Item
    Check if paginating
    SELECT * FROM Item (Now i have to show the item, i get all data…)
    Result: With 700 Items, I’m doing 1 + (products_shown) querys = 16 querys.

    What this plugin does
    SELECT all ItemIDs From Catalog X
    ForEach Item
    SELECT category INFO
    SELECT Item INFO
    SELECT ItemTag INFO
    Check if Item is Visible
    Add DATA

    Result: With 700 items, you are doing 1 + 700*3 querys = 2101 querys.
    Notice: You shouldn’t ask for all items info when you are paginating. You filter in database, not in PHP after getting all info!

    So… 2101vs16 querys, being 15 of them the same…

    Adding the fact your tables have no INDEXES, so the server just DIE BYE QUERYING when you add tags / custom fields, because in all those thousand querys you are executing aren’t optimized. I would like to see a living site with custom fields and tags working with more than 40 items faster than 6s.

    The querys are not optimized at all, not even for the functionality of the plugin. I’m here just because i paid 50$ because I need 2 catalogues with custom fields, and the plugin can’t move my data if try to use them, so there are no reasons to use it.

    As said before, feel cheated. I did a whole integration system so I won’t give up and I’ll just fix your product for my customer. I changed the code so I can show the items in 3s, not the 12s-15s i was getting for a 9 item per page catalogue.

    @swdevagm Hello, I am having the same issue I uploaded 2500 products using the plugin but the page takes more than 12 sec to load it is not possible to use it. Can you let me know what in the code did you change? I would appreciate very much! Thanks!

    Thread Starter swdevagm

    (@swdevagm)

    Sadly i have to say there are no minor changes here. You can start looking at Shortcodes.php in Functions folder of plugin, but you need some programming skills (PHP & SQL). All the code for the list is in the same function (can’t remember the name sorry, not working right now), but names are pretty descriptive.

    The main problem is the code is not compatible with medium-big catalogues because system is asking for all items info even if they are in a different page or marked as “Hidden”.

    You can contact me here ([email protected]) if you want some advices 😀

Viewing 7 replies - 1 through 7 (of 7 total)

The topic ‘Slow catalogue’ is closed to new replies.