And you are here why?

So, Meltwater decided to run   their own ES setup   (on AWS, but still, their own instances). Why? In their own words — “ AWS Elasticsearch Service   allows us too little control, and   Elastic Cloud would cost us 2–3 times more than running directly on EC2 ” Go read   the entire post  — it is well worth it (especially the bit about sharding!), but the following performance tips are worth calling out 1. Limit searches to relevant data . Obvious, but lords, it’s amazing how much this one gets ignored. 2. Invest in Observability . Do you know where your resources are going? GC stats, io-wait, memory hogs, CPU usage, etc. etc. In particular, get really close and intimate with JVM performance tuning 3. Memory, not GC . Unless you’re really good, or have a real edge case, odds are that you’re not going to do much with the GC sub-system. Instead, focus on reducing memory allocation. 4. Azul Zin g for Memory . Basically, outsourcing your JVM management ...

Scott Sellers (of Azul fame) has a post up on GigaOm about Java memory issues.  To quote An improvement in the Java virtual machine (JVM) can make a world of difference. E-commerce application failures can often be sourced back to limitations of conventional JVMs, which constrain application resources and make it challenging to scale apps beyond a few gigabytes of memory, which can effect performance under load. Conventional JVMs also suffer from stop-the-world pauses because the JVM needs to clean up its internal memory, the impact of which causes applications to freeze and become unresponsive. Programmers must tune Java to work around the JVM’s limited scalability and very carefully manage the amount of memory a given application uses. For e-tailers, this is bad news, because e-commerce applications must handle users loads that are never static and require more memory for each user and transaction to ensure consistent user response times and high sustained throughput...