In the course of delivering many successful Continuous Performance Testing (CPT) implementations for enterprise customers, Grid Dynamics engineering teams have developed a number of basic design principles to guide their actions. Your requirements may be unique, but just as all custom race cars have a chassis, suspension, and wheels, all CPT implementations need to follow the six design principles we talk about in this post.
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.
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:
Nobody wants situations where e-commerce performance issues lead to lost revenue. Nothing upsets engineering teams more than frantic application troubleshooting and patching in the middle of the night.
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.