In previous posts we've talked about why Continuous Performance Testing (CPT) must be an integral part of managing the user experience. We've also discussed some of the reasons CPT is hard to implement.
I was recently on an airline flight with onboard entertainment. There was a good selection of movies, but look at the film navigation menu!
We’ve talked about searching nested parents and children with Solr Block Join. But we can go far beyond that, to searching siblings, grandchildren, and other descendants. This gives your customers more search options without forcing them to do a new search every time they add a search parameter. In fact, with Solr Block Join, nesting depth and search option possibilities are almost unlimited, so your customers can see more of what you have to offer with fewer clicks than it would take without Block Join. Here's how it works:
The “law of unintended consequences” applies to using the block join query parser in Solr, just as it does to many other things in life (and software). Leave out certain query strings in Solr, and It seems to make no difference.
Faster responses make customers happy. Lower hardware requirements make budget people happy. Block Join can help accomplish both these goals, which is why we strongly suggest using it for nested document searches in Solr. But that’s enough about why we advocate using Block Join for nested and faceted searches in Solr. Now we’ll talk about how to do it.
In a previous post, we talked about business motivations behind the support of structured documents in a Solr/Lucene index and the unique requirements for a faceting engine which is created by this approach to modeling data. We have introduced SOLR-5743.
Join support is a highly-requested Solr feature, especially in e-commerce. So I repeated Erick Erickson’s benchmark test with block join support for Solr, and I want to share my observations on how BlockJoinQuery can maximize Solr/Lucene performance.
A straightforward look at how Block Join Faceting works, how it can save your customers from frustrating search experiences, and why Grid Dynamics created SOLR-5743 to bring Block Join Faceting to Solr
Solr/Lucene has emerged over the last few years as a leading open source search platform for large-scale e-commerce search engines. Systems based on Solr power major sites including Macy’s, Kohl’s, Walmart, Etsy, and many others.
The main reason website and application performance testing is not already continuous in many companies is clear: it’s hard to implement. Why? Let’s look at a few CPT implementation issues: