Piggybacking to this thread and adding some background to this. We had some performance issues when we had a lot of simultaneous users one night. So now we're looking at causes and places to optimize the e-commerce site. The epi version is 11.2.0.

We observed that we get calls to the InventoryService when we load a variant page, which struck us as odd. The calls to the InventoryService are made from EntryContentPublishedStateAssessor.IsPublished. So, looking at that method, it appears that there is some built in functionality that in some case will say that the content is not published depending on the stock status. 

Our interpretation of this is that the implementation should return 404 for entries that are out of stock in some way. We struggle to see the scenarios where customers would like to display the product or not based upon the state of PreorderAvailableUtc. Not as a default implementation anyway. Most use cases is that they want to disable the buy button and show a text that it is out of stock, I believe.

We see that there are other implementations of the IPublishedStateAssessor interface (SimplifiedPublishedStateAssessor, DefaultPublishedStateAssessor) that we have tried to use instead. But as Erik said we haven't been able to override the behaviour.

Anyone that have any other ideas of how we can get around this? We don't get the 404s, but we don't want the logic in EntryContentPublishedStateAssessor.IsPublished to run, because it might be expensive, might even be db calls as Erik mentioned.

That's an interesting finding. The class was added to fix a bug - so we are in a compromise state here - how much slower when the check is added? In 10.7.1 and higher (when the class was added), the caching for inventory system is also much better ...

I'll probably file a bug and see if we can do. Will keep you posted. 

It's not really down to performance principally (all though we found it in a performance cause), it's down to that we don't want that business logic run. Even if the cache is better and we might not get sql queries for most of them, we still have no interest in hitting the inventory cache whenever we route a product page. Maybe Google spiders will crawl all our product pages and the cache is now pretty bust. We need some sort of work around (or "bug fix") for this. We feel this is too much business logic for a framwork to force upon us, regardless of performance implications.

Fair enough. I filed a bug. How and when it's fixed is up to discussion within the team :). But as this is reported from a partner, we'll make sure to take a look. 

Great! We'll likely be poking around to try and find an alternative solution for it, if we do we'll update the thread! :)

On the side note: It is hard to say how much slower it gets when the check is in place.

Even with improved caching the worst case scenario is that the first user will get a tremendeous hit as it is one extra database call for each entry.

Performance wise it will increase linear with how many entries are checked as the IPublishStateAssessor has no support for bulk operations., but always loads the stock status one by one.

To disable the decorator we have for the time being forceably overridden it:

c.For<IPublishedStateAssessor>().DecorateAllWith((ctx, inner) => (IPublishedStateAssessor)ctx.GetInstance(Type.GetType("EPiServer.Core.Internal.DefaultPublishedStateAssessor, EPiServer")));

Use with care, we are not liable for any problems.

It will be removed in upcoming release. (Probably 11.2.6, or 11.3, we're yet to know) 

It should be in Commerce 11.2.6