Viewing 10 replies - 1 through 10 (of 10 total)
  • Plugin Author David Lingren

    (@dglingren)

    I will have a look at this issue. MLA uses the WordPress WP_Query class for most of its database interaction, so I’m not sure what tuning options are available. Can you tell me more specifically how you are filtering the images, e.g., are you using the dropdown list at the top of the Media/Assistant screen, or clicking on a tag value in the table column?

    Thanks for this report and for your help.

    Thread Starter karlazz

    (@karlazz)

    Yikes, you were fast on this. I used the drop down list. Yes, I am looking at the site from the database perspective and see that you are just using good old wordpress table entries, nothing extra.

    Maybe we can try w3tc.

    Thread Starter karlazz

    (@karlazz)

    How would the performance settings in the settings option table be affecting the filter? Here they are —

    Where-used database access tuning
    Featured in enabled

    Inserted in enabled

    Gallery in cached

    MLA Gallery in cached

    Thanks

    Plugin Author David Lingren

    (@dglingren)

    The “where-used” settings do not affect the performance of the category/tag filtering. They only affect the four Media/Assistant table columns with similar ” … in” names.

    For example, the “Inserted in” column lists the posts/pages that have a reference to a Media Library item, e.g., using “Add media” to insert an image in the body of a post or page. The only way to discover these references is to go through the body of every post and page searching for the file name of the item. Since this is “expensive” (database intensive), you can decide how often to perform the search or turn it off all together. Similarly, the “Gallery in” and “MLA Gallery in” columns are populated by executing every shortcode in the database and seeing which items they return; again, expensive.

    I hope that makes sense.

    Plugin Author David Lingren

    (@dglingren)

    I must confess I’ve not done any testing with the “W3 Total Cache” plugin. Generally, caching works on the theory of saving the results of a page generation or a database operation on the hope that another request for the same result will be coming along soon. If your site has lots of users all looking at the home page, etc., this is terrific. If you have one or a few users in admin mode using the dropdown to filter by category, the odds of a duplicate request are small. If you have one user clicking on different category/tag terms each time they refresh the screen, I’m not sure how caching would help.

    I’d be very interested in you experience with W3TC if you decide to pursue it.

    Plugin Author David Lingren

    (@dglingren)

    I’ve run some experiments and I have a suggestion. Try changing the “Where-used database access tuning” options to “Disabled” and see the effect on your display times. In particular, try disabling the “Inserted in” option; in my tests this had a significant effect.

    The “Featured in” and “Inserted in” options are computed only for the items actually displayed. This means you can improve performance by reducing the number of items displayed on each page. Pull down the Screen Options (upper-right corner) and adjust the “Entries per page” option.

    Let me know what you find – your issue might not be related to filtering the display by tag value.

    Thread Starter karlazz

    (@karlazz)

    Hello,

    Thank you for all your responses. I turned off the search in feature and the speed went up to acceptable levels. I see you came to the same conclusion. And thanks for the tip about entries per page.

    Cheers,
    Karla

    Plugin Author David Lingren

    (@dglingren)

    Thanks for this update; I’m glad you’re having a better experience.

    Based on your report and my investigations I have been able to make a few improvements in the coming (v1.40) upgrade. I’ve reduced the database processing for some operations and I have added a new selection to the “Inserted in” tuning option. You can select “Base” to search for the basic file name and not do a separate search for each of the “intermediate size” files. This makes quite an improvement in speed while still giving you the most important part of the “Inserted in” information.

    Thank you again for bringing this to my attention and for helping to improve the plugin.

    Thread Starter karlazz

    (@karlazz)

    Glad you could get so much mileage out of it! Thanks for a great plugin, we’ll look for the upgrade

    Plugin Author David Lingren

    (@dglingren)

    Version 1.40 is out – it includes the new “Base” selection for the “Inserted in” tuning option and some other database improvements as well. Give it a try and let me know if you have any issues or further questions/suggestions. Enjoy!

Viewing 10 replies - 1 through 10 (of 10 total)
  • The topic ‘Slow searching through lots of images’ is closed to new replies.