Document some suggestions for those who are strapped for memory

[codefromthecrypt]

Java heap tuning can be notoriously difficult. We don't set any memory options, deferring to whatever platform runs zipkin. For example, the cloud foundry build pack has heuristics to set memory flags such that the resident size is understood (preventing instances from being killed based on os constraints for example). Adding to that, our deployment is flexible. Those getting started literally use the server's memory as storage. Having an aggressively small memory configuration could slow people who are just getting started.

At any rate, there may be some pointers or otherwise we can point to folks new to java or skeptical about it from a resource POV. For example, one with extremely small memory requirements could do things like setting really low memory -Xms64m -Xmx64m -XX:CompressedClassSpaceSize=32m -XX:ReservedCodeCacheSize=32m. However, we should be careful about recommending doing things like this as most aren't in such restricted environments.

Meanwhile, if there are things that cause Zipkin to use a lot of memory at runtime (ex if handlers are too chatty or codec is inefficient), we should indeed look into these. In other words, if there are real memory problems we should address them regardless of how we document general pointers.

This topic arose from a go developer who was surprised to see defaults consume hundreds of megabytes of memory. If we inventory some general pointers, answering the next person could be easier openzipkin/zipkin-gcp#38 cc @c-knowles

[codefromthecrypt]

https://spring.io/blog/2015/12/10/spring-boot-memory-performance is another analysis

[Logic-32]

My favorite would involve a change to Zipkin more than the server it's running on. But it's: #1960. Basically, if you don't buffer data then you don't need a big heap ;)

I think we've also found that small, potentially rapid requests help (easier to flush small bits from the buffer than large blobs). But we didn't have fantastic metrics when we made that change :\

[codefromthecrypt]

thank you. you might notice we made large cleanup of (v1) code with only porting of integration tests left todo. features like this are ok now to start if you want. particularly the collector is now separate jar so we can consider things even past java 8.