Very slow loading

Suporte Dúvidas
1

Hello, thanks so much for all your work on Tainacan, it’s such a wonderful resource.

I am having some trouble with a very slow load time on my main collection page: The Clockworks Collection – The Clockworks . It seems to do nothing for a long time and then load all at once.

I’ve looked through the archives on this forum and have seen suggestions to disable faceted views and clear old files via the garbage CLI command - I have done both these things, but it hasn’t made any difference. We also recently changed our hosting provider, which has resulted in much faster load times for the site as a whole, but no change to the Tainacan page.

I wondered if maybe I was missing something else that might be obvious to you guys when you look at it? I’m using the Blocksy theme.

Thank you!

2

Hi, @ktamb , welcome to Tainacan’s site.

You are likely experiencing the same thing I had here:

The solution is to optimize the WP DB indexes and one plugin I’ve been using on Tainacan and WP in general clients is the “Index WP MySQL For Speed”. It changes the database indexes to a much faster setup. I’ve seen significant improvements on both Tainacan and WordPress blogs and applications that rely on WP tables.

Like any database change, please backup your site and data before trying it. I’ve never had an issue, but it has the potential to break your whole database if anything goes wrong.

Hope it helps!

3

Thank you so much! I’ve now installed and activated that plugin, cleared the cache etc - I’m afraid I’m not seeing any improvement so far. Do you know if that plugin is the only way to make this change?

4

@ktamb From your last message, it seems that you haven’t actually executed the index changes.

Activating the plugin does not change the indexes. You must first go to “Tools > Index MySQL” which is where the plugin option live.

Then you need to make it apply the indexes on the DB. This is where the DB is actually changed.

This is the plugin page before applying the indexes:

image
image977×983 105 KB

you have to both “add keys” and “convert keys”. Remember to backup your DB before that.

Below is a screenshot of a system I manage that had the indexes applied.

image
image538×658 61.9 KB

After that, I was able to see a great improvement in performance.

Cheers,

Fred Marvila

5

Sorry, I didn’t actually say I had done the settings, but I had - here’s what I have:

image
image1656×1188 107 KB

I’m still looking at loading times of 8+ seconds :frowning:

6

Thanks, @ktamb . That’s strange.

you don ´t have that many rows (my example has about 10x more). It shouldn’t be suffering due to indexes even if that wasn’t the case.

I’d say the issue is within your host. Even though the rest of the site is fast, it may be due to caching on the hosting service configuration (some times even internally). However, Tainacan goes directly through WP, without cache through REST. This is not usually cached and thus has to run full WP execution, going to the DB and all.

If it is a shared environment, that could easily be limiting the resources or even be limited due to low resources. I had an experience on another case unrelated to Tainacan in which the server was “fast” but the disk was very slow. Their internal caching system made most of the calls be quick, but disk intensive tasks like backup were painfully slow. This might be similar to what you have (DB access or CPU may be capped).

I accessed your site and it does have a delay, but I’d say it is not very different from what I’ve experienced in similar situations on shared hosts and even on small cloud hosts.

I´m not sure what else could be improved without going further down the performance rabbit hole (which is usually not possible unless you control the whole server or add something like elasticache to improve search, which is possible on shared hosts but is a separate service).

7

Yeah 100 items with that short amount of metadata is no good reason for a slowdown, you shouldn’t need even database index tweaks… I do think there might be something in the host side.

And how about your log? Do you have many? Go to your Activities List at the repository level and see how many are there…

8

Thank you both - this sounds right to me. I’ve just checked the logs and there are 5690 items in there, but I don’t know if this is a lot or not?

I’ve taken it up with our server provider and they say it’s hitting the PHP threads limit and suggested increasing our protection against bots and automated traffic. I’ve tried that and will see how it goes…

9

Hi @ktamb!

Yeah even 5690 logs it is not a high value in my opinion… let us know if you find something else!

10

Hi @ktamb!

While I don’t think this will fully cover your situation, can you give a try on this?

11

Thank you :slight_smile: I don’t understand exactly what this task is though - it just looks like a series of files? Do I put these somewhere?

I have spoken with my web host and they said the site was hitting its PHP threads limit. I increased the site’s protection against bot traffic and that did result in a small improvement, but it still feels slow. I’ve now run an APM on the site and it says that the wp-cron job is the biggest culprit (I had previously disabled this, and have now disabled it again). I also got the below results for plugins:

image
image2266×1058 150 KB

At this point my web host is just saying I should disable Tainacan, so I’m a bit stuck!

I understand this issue about caching versus bypassing cache and I wonder if there is any mileage in forcing caching for some of the parameters? The URL seems to have a lot of parameters loading when the images are loading.

12

Hi @ktamb sorry for not explaining!

What I suggested with the previous comment is that you download that .zip, which contains a on-development version of Tainacan, go to your WordPress plugins page → “Add new” , click on Send/upload and from there install the new version.

The WP-Cron is how background processes are managed. In Tainacan they are used for three things: Importers, Exporters and Bulk Editing operations. You can disable it safely if you are not going to need any of these three.

I’m not familiar with how the APM runs its performance check, but you will need some good willing from your web host if he is already asking to remove Tainacan just due to that. The point is that, Tainacan does and will be doing a lot of stuff in your server, and that is not necessarily an issue, it is mainly the plugin doing the job to which you need it. The Items List with the faceted search is a complex UI, and having its filters and advanced search features available comes with its cost to the database and host.

But I still think there might be other reasons for having your issue, we have numerous use cases in different hosting platforms that are not hitting PHP threads limits without a good reason. If you ever point us to specific things to investigate, we will see if there is an improvement, I promise that. The other topic that I mentioned, for example, was the case of a user who identified a performance bottleneck in a JS library that we use to render progressive loading on images. That was an hypothesis that have good arguments and I was able to identify the issue and solve (I hope so, we’re testing it). The WP Cron is a solid argument and if proven the root cause we could even investigate ways to offer disabling the features related to it more easily in the UI. But all in all, Tainacan will do more things than, say, UpdraftPlus, a plugin that only runs its job from time to time to generate a backup. Do you agree?

Specifically about the URL params, if you read them, you’ll see they all are needed to build the current state of the items list. The define order, which metadata are shown, pagination and later which filters are applied. It is a really dynamic content so it is not something that is cached as an HTML in the page, the component actually refreshes itself internally via JS every time you change something (requests are done via REST API).

13

Hi @mateus.m.luna - this update made a huge difference, thank you so much!