This may be a reality if not using the right approach to avoid expensive I/O operations. On a high-pressure container environment, where EC2 Auto Scaling is frequently triggered to add more capacity in the cluster, it may take around 4 to 8 minutes for a container to become ready from the time the EC2 Auto Scaling was triggered to the time the Windows container accepts traffic. Let’s say you are running an Amazon Elastic Container Service (Amazon ECS) cluster based on Windows or an Amazon Elastic Kubernetes Service cluster (Amazon EKS) with Windows node groups. Let’s put the comparative aside and burst the Windows container launch.īefore we dig into how to solve the problem, let’s understand it first. As an example, a developer should not run ASP.NET applications on a Linux container, nor should they run Python on a Windows container. This is true, but this comparative doesn’t bring much value to the table as each platform address completed different problems. In many cases, I also hear the following comparative: Linux Containers vs Windows Containers and how fast is the Linux when compared with Windows. In part this is true, however, it is important to demystify “the big image” and how to implement cache strategy to avoid expensive operations on the disk (the extraction) and speed up the Windows container launch. I have heard many times from customers that Windows containers aren’t fast to launch due to the container image size. This is an excellent feature to be combined with the proposed AMI generated in this blog post. Once flagged, every instance launched from the AMI will automatically launch faster. Customers can flag any Amazon Machine Image (AMI) running Microsoft Windows Server to launch faster. Because of this reduced Startup time, the Tomcat community should perhaps consider adding a step to create an SCC by doing a single start of Tomcat Server during build into their OpenJ9 based docker images.Update: On January 11, 2022, AWS announced the ability to launch Microsoft Windows Server instances up to 65% faster on Amazon Elastic Compute Cloud (EC2).From the data we got, we can confirm that OpenJ9 with SCC has an out-of-box ~30% reduced Startup time with only 2% increase in Footprint against no SCC.(used numactl - physcpubind=0–3 - membind=0) Pinned 4 processors to the server during the run.CPU Type: Intel(R) Xeon(R) Gold 6126 CPU 2.60GHz.Size of docker images (on disk) with tomcat using ExplicitSCC and the original one are: Docker Image SIZEĪll Above experiments are done on a machine with following config The command below is used to start the docker container: docker run -v $PWD/logs:/usr/local/tomcat/logs -cpuset-cpus="0-3" -cpuset-mems="0" -d īelow are the results of Startup and Footprint from my experiments:Ībove graphs Y-axis uses normalized data since it’s the relative picture that matters.įrom the graph data above, OpenJ9-ExplicitSCC(with 10 warm-ups during build) didn’t help much in reducing the Startup time as OpenJ9-ExplicitSCC (which does a single run during build) also gave similar results. Huge Pages used is the difference of the value from “ /proc/meminfo” before and after the tomcat Startup. RSS of a process is calculated using “ ps -p -o rss”. So, I had to measure it by summing up RSS of a process and Huge pages used (if enabled). Because docker stats doesn’t add up Cache memory, the docker with SCC showed lesser memory_usage (which is not we are looking for!) For Footprint: I initially used docker stats to collect the Memory_Usage of a container.For Startup time: Need to mount the logs directory of the container into your server and Use the log (catalina.out) generated by the server and look for INFO .Catalina.start Server startup in **** milliseconds.To calculate the Startup time and Footprint, below methods are used: I also created an another image which runs the tomcat Server for 10 times (instead of one time as mentioned in above snippet) to populate the SCC – only to check if that can improve more Startup time. With the above changes in Dockerfile, we can build an image which uses SCC with OpenJ9. # set variables to create shared class cacheĮNV JAVA_SCC_OPTS "-Xshareclasses:name=tomcat_scc,cacheDir=/tmp,enableBCI -Xscmx20M"ĮNV JAVA_OPTS "$" , to avoid any AOT that happens at the start of container as it doesn’t give any benefit to the container.īelow are the lines I added in Dockerfile for above instructions. Now, change the JAVA_OPTS to make -Xshareclasses flag readonly. Do a cold Tomcat Startup run as part of build itself.Add JAVA_OPTS which has SharedClassCache related options.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |