Deferred/queued sync - "algolia_task" - is (maybe) not in use?

[moory-se]

Here it says:

By default, this plugin will ensure that your WordPress content that is flagged for indexing stays in sync with Algolia.

This behavior does not rely on CRON, but uses a custom private post_type algolia_task.

I've looked through the code, and nowhere I can find any traces of this being true. Here we're calling the sync method which is doing this synchronously.

I see two problems if I'm correct:

1. The documentation is wrong
2. The documented behaviour (queuing updates) is obviously a good one, and the opposite is less good

Am I missing something?

If not, I could have a go at trying to implementing this. I would use ActionScheduler.

For me personally, this behaviour slows down our site drastically. Also, integrations are very slow since every product update is also a algolia update. Disabling syncing, a product update call goes from 2 seconds to 0.3 seconds in our environment.

[tw2113]

Hi @moory-se

I am pretty sure the documentation is indeed wrong in this case, as you're pointing out. We copy/pasted a lot when we forked https://github.com/algolia/algoliasearch-wordpress and this looks like a prime example of that.

I checked the changelog for that archived copy, and they removed that algolia_task post type in version 2.0.0.

That said, our plugin here is using https://github.com/algolia/algoliasearch-client-php internally for its requests.

I am familiar with ActionScheduler, but I think sticking with the PHP SDK that they're still maintaining, is going to be the best route at the moment. Looks like they're prepping for a 4.0.0 release soon.

To be certain, what you're saying is that our current setup is slowing down your website?

I'm curious if you'd benefit from this filter:

$this->changes_watchers = (array) apply_filters( 'algolia_changes_watchers', $this->changes_watchers );

You could just return an empty array and have none of the default content types get watched. You'd need to re-index on your own perhaps with the bulk buttons in our settings pages, but that could help with content creation in the meantime.

add_filter( 'algolia_changes_watchers', '__return_empty_array' );

[moory-se]

Hi,

I think you're mixing 2 concepts here. The PDP SDK has nothing to do with queuing/not queuing? ActionScheduler is a small library that gives plugin developers a framework for handling background jobs. It is not replacing the Algolia PHP SDK in any way.

The idea behind a queue is to let the request (a save request, for instance) be faster since it will not have to wait for a algolia index request. Your suggestion is speeding things up because it does nothing - that's quite far from "doing everything you want, but in the background".

I still think some kind of background job is a good idea.

[tw2113]

Noted and understood regarding ActionScheduler, but I guess I'm still not seeing the benefit here yet, unless you're having performance issues just from updating one content type post, and it being because of how the watcher code is eventually pushing up information to Algolia, during that request, as logically it'd be only one post at that time.

I know that the bulk operations in our settings pages are running on AJAX requests and have I believe a max per request of 100 at a time.

[moory-se]

When doing an update currently, we have to wait for the Algolia request and response. With a queue in place, all we do is to place the task in a queue. This is essentially always 0ms. Then the queue is handled in the background (not in a request) - and that's where the actual Algolia call is made.

This scales very well when doing integrations with Wordpress. We for instance push prices from an external system. This is 16k calls daily. Each of these calls needs to wait for Algolia, making them ~7 times more slow.

This is not a "special" thing for this plugin, but rather how most indexing processes are being handled. Wordpress and WooCommerce use the same method for many things :)

[tw2113]

Documentation has been updated to no longer refer to the algolia_task portion that was previously removed.