Ideally that's something Episerver should solve on their side so I would recommend going that way before trying double indexes.

In my mind customer should not think about that. Episerver provides an index and makes sure that index is accessible, it supports certain number of queries per second and corresponding number of documents.

Could you please describe what do you mean by "high load on the Episerver Find index"? Is there any issues or delays? Missing data?

Then we are in agreement :)

As a customer you should not try to load balance your index. We will do that automatically for you if we experience high loads on indices on our clusters.

If you experience issues with client errors (i.e. 'Too many requests' or 'Too many documents') you can contact support to have your account upgraded.

/Henrik

Thanks for the input!

In our case we are getting the error even though we have max number of request set to 75 request/s for our FIND license. We are investigation other solutions like blocking IP-numbers, reducing number of requests, contacting episerver etc. Based on your input we will put the thought about using two index to rest for the moment.

reagrds

Magnus

The other problem you could encountered using two Find is ranking mechanism behid the scene will work differently so user through pagination will get duplicated result. As I know ElasticSearch is scalable so logically if there is any pressure on server it can scale itself up. So I think EPiServer needs to take a look on this. Max EPiServer Find can handle is 75 req/sec which I don't think is a case. We had similar issue and with help of EPiServer support we resolved this using caching.

It actually turned upp to be related to the .track function. It was causing a lot of extra calls to FIND. When removing .track from our searches we reduced the number "too many request" with 99,9% ;) Thanks for the excellent support from Henrik Lindström on this matter!

Magnus

Thanks for sharing Magnus.

A question, how did you manage to get so many track-queries?

And yes, Henrik is a Yedi, has helped me a lot over the years!

The culpit, as i understand it, was that we where calling the .track function even though we where just adding filter to the search operation with the same query string (and we have a lot of filter that are updated constantly as the user searches/filters) So the .track function only needs to be called when the actucal query string changes according to Henrik Lindström. There also seemed like non optimal implementation of the track function which causes it to send two http request to FIND for each search operation. Henrik Lindström said that he would look into that. For now we have disabled .track in our implementation.

Magnus