Hi Walter,
You’re right, this is going nowhere.
We thought that the bottleneck might be the http connection between the API
running on Cloud Foundry, and the Solr Cluster on an external host.
Potentially saving bandwidth on that seemed (at the first glance) like a too
good option to not look i
I really do not expect it to make anything faster. I think you are wasting your
time. Compression also adds some latency because the compression happens before
data is sent out.
If your CPUs are idle, that is a red flag for performance. In every one of our
clusters, CPU is the limiting factor
Hi Walter and Jörn,
thanks for your suggestions! I will keep them in mind.
According to our sysadmin, the CPU's on the Solr nodes are “doing basically
nothing", so that’s a plentiful resource in our case. We’re most interested in
reducing the response time of the whole chain, that (for search A
Years ago we did some testing with HTTP compression for search results with the
Ultraseek search engine. It wasn’t faster. It was sometimes slower.
Once you have enough RAM, search is a CPU-limited problem. HTTP compression
uses more CPU to save network bandwidth. But search isn’t limited by net
You could also change the responsewriter from json to javabin to improve
performance.
Or increase network bandwidth. Then often people fetch more from solr than they
need. There is a huge saving potential. Increasing the cores for https
encryption can sometimes help.
Compression also leads to
