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.
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.
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!
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.
I was wondering if anyone has any experience using two EPIServer FIND index towards one EPIServer database? The setup consist of two loadbalanced webservers running the website. Each website is using the same database and the same FIND index. However as we are having a high load on the PIServer FIND index, i was wondering if it is possible to use two FIND index instead, one for each webserver/website to spread the load towards FIND on two index. Any issues that we might run into if we try it?