Runtime environment optimizer for JVM-style languages
A continuous optimizer detects a code promotion of a candidate release of an application. In response to the code promotion, the continuous optimizer instantiates a JVM and profiles the application to obtain a JVM profile. The continuous optimizer benchmarks the candidate release against the JVM and JVM profile. The continuous optimizer further compares the benchmark results with previous benchmark results. Based upon the comparison and a set of rules, the continuous optimizer causes the candidate release to be promoted.
1. A method for deploying a release of an application, the method comprising:
profiling a candidate release of the application against a plurality of Java virtual machines (JVMs) to identify a JVM and generate a candidate JVM profile that is configured to achieve performance goals of the application;
benchmarking the candidate release of the application with the identified JVM and the candidate JVM profile to generate benchmark results; and
applying a rule to deploy the identified JVM, the candidate JVM profile, and the candidate release based on a comparison of the benchmark results with previous benchmark results.
2. The method of claim 1 , wherein the identified JVM executes in one of:
a container;
a virtual machine; or
a container within a virtual machine.
3. The method of claim 1 , wherein:
a plurality of additional applications are benchmarked against the identified JVM and the candidate JVM profile to generate additional benchmark results; and
the rule is further based upon a comparison of the additional benchmark results with previous benchmark results for the plurality of additional applications.
4. The method of claim 1 , wherein the benchmark results include at least one of: startup speed; method latency; throughput; garbage collection pause times; application jitteriness; or transactions per second.
5. The method of claim 1 , wherein the identified JVM, the candidate JVM profile, and the candidate release are deployed by a service orchestrator.
6. The method of claim 1 , wherein the identified JVM to which the candidate release is deployed comprises a plurality of deployed applications.
7. The method of claim 1 , wherein the rule prioritizes a performance metric of the candidate release.
8. A system comprising:
a memory; and
a processing device, operatively coupled to the memory, to:
profile a candidate release of an application against a plurality of Java virtual machines (JVMs) to identify a JVM and generate a candidate JVM profile that is configured to achieve performance goals of the application;
benchmark the candidate release of the application with the identified JVM and the candidate JVM profile to generate benchmark results; and
apply a rule to deploy the identified JVM, the candidate JVM profile, and the candidate release, based on a comparison of the benchmark results with previous benchmark results.
9. The system of claim 8 , wherein the identified JVM executes in one of:
a container;
a virtual machine; or
a container within a virtual machine.
10. The system of claim 8 , wherein:
a plurality of additional applications are benchmarked against the identified JVM and the candidate JVM profile to generate additional benchmark results; and
the rule is further based upon a comparison of the additional benchmark results with previous benchmark results for the plurality of additional applications.
11. The system of claim 8 , wherein the benchmark results include at least one of: startup speed; method latency; throughput; garbage collection pause times; application jitteriness; or transactions per second.
12. The system of claim 8 , wherein the identified JVM, candidate JVM profile, and candidate release are deployed by a service orchestrator.
13. The system of claim 8 , wherein the identified JVM to which the candidate release is deployed comprises a plurality of deployed applications.
14. The system of claim 8 , wherein the rule prioritizes a performance metric of the candidate release.
15. A non-transitory computer-readable storage medium including instructions that, when executed by a processing device, cause the processing device to:
profile a candidate release of an application against a plurality of Java virtual machines (JVMs) to identify a JVM and generate a candidate JVM profile that is configured to achieve performance goals of the application;
benchmark the candidate release of the application with the identified JVM and the candidate JVM profile to generate benchmark results; and
apply a rule to deploy the identified JVM, the candidate JVM profile, and the candidate release, based on a comparison of the benchmark results with previous benchmark results.
16. The non-transitory computer-readable storage medium of claim 15 , wherein the instructions further cause the identified JVM to execute in one of:
a container;
a virtual machine; or
a container within a virtual machine.
17. The non-transitory computer-readable storage medium of claim 15 , wherein:
a plurality of additional applications are benchmarked against the identified JVM and the candidate JVM profile to generate additional benchmark results; and
the rule is further based upon a comparison of the additional benchmark results with previous benchmark results for the plurality of additional applications.
18. The non-transitory computer-readable storage medium of claim 17 , wherein the benchmark results include at least one of: startup speed; method latency; throughput; garbage collection pause times; application jitteriness; and transactions per second.
19. The non-transitory computer-readable storage medium of claim 17 , wherein the instructions further cause a service orchestrator to deploy the identified JVM, candidate JVM profile, and candidate release.
20. The non-transitory computer-readable storage medium of claim 17 , wherein the instructions prioritize a performance metric of the candidate release.