Several tips for your Beanstalk service

Creating a Beanstalk environment using the AWS console is a very straightforward mission mainly because the entire flow is very intuitive and steps are clearly listed. But with this approach we must ensure several configuration options are properly set. In this article we’ll list a couple of settings we saw ignored in many situations. Our suggestion is to browse the documentation and eventually to find other articles on this topic and only after you understand how things are going to update the settings, otherwise the application might operate odd or become unavailable, even your piece of software doesn’t have any bug.
We strongly recommend you to enable log rotation into S3. By default, this option is not activated, which means you will have access only to logs that are not rotated yet. Even more, if a host is going unresponsive and is replaced, you will have no clue to identify if the root cause is your software (or a dependency used in your software). By activating this options, you have the possibility to track any request and to investigate any possible issue. If you determine costs are going too high because you save all the logs, you should add a rule to automatically move them from S3 into Glacier or to delete logs that are older than a specified number of days.
Also, you should operate some changes on command line arguments and settings for JVM. You should increase the JVM heap size if the underlying instance you selected has more memory available. On the same line, the JVM arguments should include the following settings:
* force timezone to UTC -Duser.timezone=…
* Caching policies for name lookups…
* Garbage collector, if you want to change the default
* JVM meta space -XX:MaxMetaspaceSize=… Even there is a special place to set this option (see below picture), as of today this option is not correctly set on the JVM if you use Java 8. In the service logs, you’ll see an entry like this:
OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=96m; support was removed in 8.0
There are many articles dedicated to JVM tuning and monitoring and we recommend to see which options fits the best your use case.
For production environments it is strongly recommended to spend some time thinking which are the best scaling triggers for your application. You are encouraged to define as many triggers as you consider, based on CPU load, latency time, number of requests, etc.
Lastly, it is very important how you deploy a new application version. There are multiple options here, each of them being right in a certain situation. As always, our advice is to understand when to use one or another and after that to adjust the environment settings with these values.