After some discussion with a colleague from another company that also uses App Engine, he told me that he managed to cut down his app warm up time from ~15 seconds to ~5 seconds using the following steps:
- Configure Eclipse to bundle classes produced during compilation into a single JAR file.
- Configure Eclipse to upload this single JAR file instead of hundreds (or thousands) of separate Java classes during App Engine deployment.
He argues that during instance warm up, since the instance need to load only a single bundled JAR file instead of thousands of separate classes, the warm up would be significantly faster. Any thoughts or opinions about this?
I would definitely like to try it by myself, but I don't have enough Eclipse-mojo to know how to configure such steps. Does anyone know how to configure Eclipse or the Google Plugin for Eclipse to do the steps outlined above? (And have the deployed apps successfully runs in App Engine, of course)
Thank You,
As stated in an earlier answer, the App Engine SDK supports packaging
WEB-INF/classes
into a jar file, which will end up inWEB-INF/lib/_ah_webinf_classes-0000.jar
. You can activate thisusing the appcfg tool with the option
--enable_jar_classes
.using the Google Plugin for Eclipse by configuring the properties of either your WAR or EAR project: Project properties > Google App Engine > Deployment > "Package WEB-INF/classes as a jar"
For me, on App Engine 1.9.4, this resulted in only a minor improvement in instance spin-up (about 5-10 %, if any).
Note that this will package all files in WEB-INF/classes (not only .class ones). Following the change, I got an error message during instantiation about not being able to read the logging.properties file anymore; probably because the new jar file hasn't been read at that time:
Unable to read the java.util.logging configuration file, WEB-INF/classes/logging.properties
As a workaround, I changed the path in appengine-web.xml to
WEB-INF/logging.properties
and configured the maven-war-plugin to copy the file to that location:I think the easiest way to do this would be to have a separate project that you write all the code in as well as store any other dependencies. When you're ready to deploy, Eclipse's export to runnable JAR file can repack all the dependencies and your classes into a single JAR file, which you would then use as your one dependency in your deployable Google App Engine project which would basically consist of any config files in the WEB-INF folder as well as other static resources + the one big JAR file.
Alternatively to the eclipse export, you can set that up as a Maven or Ant build which can also do the repacking.
One way this can be achieved if by doing the deployment through Ant, as described in: https://developers.google.com/appengine/docs/java/tools/ant
Next you can modify the ant build.xml file to call the ant command for building the jar file. Just before the actual deployment you can either delete or move the compiled artifacts away. The build jar-file should be placed in the WAR/WEB-INF/lib folder.
Drawback of this solution is that you have to deploy through the build.xml, i.s.o. through the appengine eclipse plugin.
I doubt it. WAR is just a ZIP file, which gets unpacked when it's deployed on the server. So there is an additional step, meaning the process can be equally fast (if unpacked when uploaded) or slower (if unpacked when instance is spun up).
I don't know how (or if) you can integrate it into eclipse, but it's fairly trivial to do with ant:
I will add that I did not experience a 3X reduction in app startup time. I posted some experimental numbers in this thread:
https://groups.google.com/d/msg/google-appengine/dStBW4wIemY/K69f9ufDiN0J
What I found is that instead of varying wildly from 20-45s, it made my app consistently load in 20s. It has not subsequently remained this consistent, but I still jar my classes as a standard part of deployment now.
What we did in Eclipse was:
You can configure the jar builder to execute automatically as class files change (which in turn are usually automatically recompiled as your source files change).
There are some downsides, though. For some reason the google eclipse plugin gets confused by your changing the output directory of the java compiler. This means you will have to manually point to the war directory when deploying, and I believe you'll have to manually copy some GAE jars into the war/WEB-INF/lib folder.