LPT: On Creating a High-Performance REST Service in Java

java_rest_hp.md

• Use Java 8. Seriously, any other version is just backwards-thinking. Functional aspects of the new version is reason enough to use it.
• Use Jersey REST Framework. I've tried every other framework out there (including the bloated, over-engineered Play Framework) and nothing comes close to its efficiency and features without being bloated.
• Never use parallelStream()...at least in the current release of Java 8 as it has the most inane implementation of parallelism I have come across to date.
• On that note, never spawn threads at all within a request. If your request is taking too long using a single thread, you're doing it wrong.
• Use a profiler. Buy a YourKit license now.
• Be mindful of your logging. For example, if you're using Log4J2 asynchronous loggers, don't use includeLocation=true.
• If you need a simple in-memory, non-distributed caching, use Google Guava Caching libraries. For Pete's sake, don't roll your own using ConcurrentHashMap; life is too short for that.
• Need pooling objects? Use Apache Commons Pool.
• You want a slow REST service? Use Spring Framework (Read: don't use Spring Framework).
• Tomcat vs Jetty? Jetty might be lighter weight, but still a pain to set up compared to Tomcat. As for the rest of the competition? I don't even bother. BTW, don't get into that Non-blocking I/O hype (at least for now)...Java is inherently blocking (i.e., it's not trivial to write non-blocking I/O code without writing a lot of code), so unless all of your resources supports non-blocking operations, don't even bother.
• Use synchronized keyword really sparingly; Again, if you feel the need to use synchronized on a method, you're most likely doing something wrong.
• Be mindful of what class/libraries to use for generating random numbers. Be aware that SecureRandom has a synchronized method making it a source of contention if you create a lot of random numbers on a heavily-loaded service.
• Don't get fancy on logging. Don't do any of this. No matter how you slice and dice it, stacktrace operations are very expensive in Java. Don't be lazy and just use constant strings.

Thanks for this note. Something I was looking for a while.