Telling the static part of the product object that it needs to live by the same rules as the dynamic part, particularly when the payload of the bulk of the product data is so huge compared to the dynamic price and inventory data is just crazy talk (my opinion of course :)
So we only hit the database for the dynamic properties of an object. Sounds brilliant! So what's your proposed solution?? :)
It seems the easiest way would be to apply output caching to the "non-dynamic" user controls.
Don't get me wrong, your comments are valid but we are getting away from the fact that we want to cache our domain objects for longer than a single http request and currently we can't. For me, that is the bigger issue here. Output caching will help but isn't going to fix everything.
P.S. There's nothing stopping us from eager loading data rather than submitting so many queries to the database.
SQL Dependency Cache is also where we are heading with most of the patches we are doing (I'd pay someone to consult with me on this by the way...)
I'm half tempted to just throw the non-price, non-inventory product objects in the application memory space and hard cache them there.
My other alternative is to deserialize the product object into an XML blob and then shove it into an extra XML field in the nop_product table.
I'm also chasing down why loading a product detail page causes the LoadCategorybyID proc to fire hundreds of times. Unlike most catalogs where a product fits in a nice tidy category somewhere, my single product with 21 product variants can be classified in over 500 categories depending on the situation.
When the product detail page is loading it's hydrating the "complete" product object which means it's firing off zillions of individual, atomic "get category" procs. Why? to assemble the breadcrumbs that actually only needs to know the name and ID number of 4 to 5 categories. That's just one case where the monolithic "get everything we know about this product" is just overkill... and when you multiply that times a bunch of products and variants it gets messy.
I think I need a streamlined "get only what I need to know about this product to show a product detail page" object...
So is Facebook, but I can guarantee you that aside from the asynchronous AJAX callbacks when you post an update, 100% of that website is publication cached content.
I don't know about Facebook but Wikipedia uses Memcached. Not a suggestion or anything just a point of information!
Using Lucene.net create an index of your catelog and only query this.
When a product / catelog is update update the index. I.E there are no database calls on the front end.
A friend of mind has already done the leg work on this.
I have the done a lucene.net search on http://www.shortersclub.co.uk/search.aspx?searchterms=haribo
This would be a solution to all our problems?
What possible issues could there be?
+1 for lucene.
We would need to have separate services for the UI and administration (talk to database directly in admin). Of course you could use the .net cache in the same way (and this would resolve the problems we have experienced up to now with EF and caching).
Using Lucene.net create an index of your catelog and only query this.
When a product / catelog is update update the index. I.E there are no database calls on the front end.
A friend of mind has already done the leg work on this.
I have the done a lucene.net search on http://www.shortersclub.co.uk/search.aspx?searchterms=haribo
This would be a solution to all our problems?
What possible issues could there be?
+1 for lucene.
We would need to have separate services for the UI and administration (talk to database directly in admin). Of course you could use the .net cache in the same way (and this would resolve the problems we have experienced up to now with EF and caching).
I believe Magento works in a similar way.
I'll see if I can get something working over the weekend.
The other nice thing about using lucene is ease of facet searching and creating facets from your catalogue
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
