What do you do if/when Find is unavailable or slow?


Occasionally we run into an issue that our page is unaccessible or incredibly slow. Optimizely support tells us in these cases that it is a Find issue. We have been suggested to wrap all code related to Find in try-catch blocks or to implement a custom request timeout.

Has anyone else run into this problem and implemented some kind of solution?

Jan 30, 2023 8:22

We typically implement Find as any external service on which we cannot really depend on, but first things first, how do you use Find? Do you meassure the number of requests? This can be seen in services like Azure Application Insights and similar unless you have your own service monitoring software. 

Find has a request cap depending on your license size (https://www.optimizely.com/online-order/order-episerver-find).

  • Small: 25 QPS
  • Medium: 50 QPS
  • Large: 75 QPS

Optimizely is quite nice regarding QPS throttling but if you have a lot of queries over time the service will eventually shut down for a while, in some cases query serving will be stacked and you will experience the service as "slow".

So yea, I have entered projects where this have been an issue. First thing is to check how you actually query Find, can some queries be cached, rebuild your website not to be dependent on external services and implement them using some circuit breaker pattern or atleast as components/MVVM-services.

Jan 30, 2023 9:00

Our website is completely dependant on Find, every single page uses it, usually even several blocks per page need it. 

I cannot answer about QPS, only requests per second. Don't know which plan the company has chosen but I would assume it should be one that is business-appropriate :D 

Rebuilding the website seems like a scary scope, even though we are discussing for some places to add a possibility to fecth data ourselves in the catch blocks. 

Jan 30, 2023 11:42
Jan 30, 2023 11:54

No, we are not using it, and I can see in my current task as a separate bullet point saying that we will not use it : D We are using a CustomObjectCachingService instead.

I wonder if there is one entry point where we could check if Find is down and take action in that case; or do we need try catch blocks in all the methods all over the project?

Jan 30, 2023 13:33

Cant really understand why you wouldn't use it. 

Anyway, you sure should check the availability or response time of Find, break out the implementation and use a circuit breaker, but then your site relied heavily on Find, right?

I'd still give the built-in cache a shot, there must be a very good reason not to. Usually a few seconds (like 10-30s) will give the desired effect.

Jan 30, 2023 14:05

And by not being reliant on Find do you mean you are taking the results from the database via the repositories?

Jan 31, 2023 10:28

Relying on Find is usually faster way, especially compared to loading from database. but it has its own caveat, as Eric mentioned you definitely want to:

  • cache your queries by StaticallyCachedFor
  • cache your data (i.e. after returned by Find and transformed by your code) using ISynchronizedObjectInstanceCache

this is a good start Common Find caching pitfalls | Optimizely Developer Community

QPS is the upper limit of how many queries you make to Find before your requests be returned with 429 (too many requests). IIRC it's a 5 second window, so if your QPS is 50, if you reach 250 queries in 5 seconds, your 251th and more queries will get 429 responses. you definitely want to avoid that.

Jan 31, 2023 11:02

We have ended up implementing try catch blocks and different scenarios, either retrieving the results from the database or displaying a temporary error message. 

Thank you for help both!

Mar 20, 2023 8:35
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.