In case you missed them, here are the top posts from The Performance Zone this past week. As chosen by yours truly.
There is always the next JVM behaving badly. And you know by heart that if you just could have had those few startup options exposing some more information about what is going on, you might have stood a chance of actually fixing the goddamn thing.
We are working on performance a lot lately, but performance isn’t just an issue of how fast you can do something, it is also an issue of how many resources we use while doing that. One of the things we noticed was that we are using more memory than we would like to, and even after we were freeing the memory we were using. Digging into the memory usage, we found that the problem was that we were suffering from fragmentation inside the managed heap.
Replication throttling in Solr 5 works; that’s a fact. What we would like to see next is an API that would enable us to dynamically change the throttling, so we can automate that depending on our needs without pushing our collection configuration to ZooKeeper or reloading a core in master-slave deployment.
An examination of how memory management works in Linux, and an analogy to banking that shows how Linux's method of memory management can be problematic for developers.
The examples in this post will demonstrate how to combine Collection-backed Streams with groupingBy Collectors to reorganize the underlying Collection's data in groups prescribed by a provided classification.