by Philip Yurchuk | Mar 29, 2013 | Software
This is making the rounds and is pretty interesting:
http://www.techempower.com/blog/2013/03/28/framework-benchmarks/
My framework of choice, Grails, doesn’t look spectacularly fast, although I already knew that. However, it is nice to see that it is notably faster than RoR (which appears to be a complete dog) and Django, and will probably improve quite a bit with v2.2 on Groovy 2.0 and Java 7.
However, it seems a big part of the performance lag is because it’s built on Spring, and to my surprise Spring isn’t a great performer, either. It is nice to see that straight up Servlets and Vert.x are beasts, so another score for our dear JVM.
Another thing that caught my attention is that Grails’s ranking improves quite a bit once you move it from EC2 to dedicated hardware. IaaS and PaaS save you some admin work, but also costs you some dev time, but at some point it looks like you’ll get a nice gain from dedicated hardware. It could make something like Rackspace managed hosting on dedicated hardware look reasonable.
With the attention it’s getting, I also expect a shakeup as framework providers help the benchmarkers improve performance. It will be interesting to see how this plays out.
UPDATE 2/2/2014
Round 8 of the web performance benchmarks are out and Grails is looking good. (more…)
by Philip Yurchuk | Aug 15, 2011 | Software
I recently switched from Eclipse 3.6 to STS 2.7.1 (based on Eclipse 3.7). Ditching my old .project and workspace settings files along with the move has made for a smoother experience; it seems these files get corrupted over time, and I’m too lazy to do the research to fix them. However, the upgrade resulted in performance issues. For instance, it hung for ~10 seconds every time I saved web.xml, and there were various random pauses. It’s not the hardware: I’m on a Core i7 Quad with 6GB RAM running Win7 x64. I realize you are getting more tooling with STS, but performance was much worse than I experienced with 3.6.
Well, it had slipped my mind that I had updated my 3.6 eclipse.ini settings with those I had found in an excellent Stack Overflow answer from VonC on optimal JVM settings for Eclipse. It hasn’t been updated for 3.7 (nor does it mention STS), but after some experimenting and research it appears to work well for it. Here are my settings, and below I add some commentary on what they do, which is missing from the original answer (although I still suggest you read that, as it covers other situations/issues that may affect you). Keep in mind I’m not a JVM tuning expert, YMMV, etc. Here are the contents of my sts.ini:
-vm
C:/Java/SDKs/jdk1.6.0_24x64/bin/javaw.exe
-startup
plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar
–launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.100.v20110502
-product
com.springsource.sts.ide
–launcher.defaultAction
openFile
–launcher.XXMaxPermSize
384M
-vmargs
-Dosgi.requiredJavaVersion=1.6
-Xmn128m
-Xms256m
-Xmx768m
-Xss4m
-XX:PermSize=128m
-XX:MaxPermSize=384m
-XX:CompileThreshold=1000
-XX:+CMSIncrementalPacing
-XX:+UnlockExperimentalVMOptions
-XX:+UseG1GC
-XX:+UseFastAccessorMethods
-XX:CompileThreshold=1000
This is the number of method invocations/branches before compiling. This is normally set to 10,000, so we’re changing it dramatically, but the original suggestion was leading to errors so I raised it. You will notice on startup that it takes longer, and your CPU usage jumps. However, your performance after that is much better. Those 10s save times for web.xml? Gone after this. I’m willing to take a hit at the beginning for better productivity while coding.
-XX:ReservedCodeCacheSize=64m
Related to the above, I was getting the error “Unhandled event loop exception / out of space in CodeCache for adapters” due to setting the compile threshold to 5. This is another solution to that problem, and may be redundant.
-Xss4m
This is stack size, and was previously set to 1MB, now up to 4MB per thread. Doing this will increase the overall memory used.
-XX:+UnlockExperimentalVMOptions
-XX:+UseG1GC
-XX:+UseFastAccessorMethods
These enable parallel garbage collection. I saw my CPU utilization reach 100% after this, which is rare on a Core i7 Quad. It felt like I was finally using it to its potential.
Again, I’m not an expert. I’ve found it’s more sluggish at first, but response times quickly improve. For me, it’s a clear net gain. Not documented are the things I turned off in preferences because I wasn’t using them (Maven is disconnected, etc.). Visit Windows >> Preferences and filter on startup, see if there’s anything you can get rid of. Finally, I must give credit to my sources outside the original article:
http://ugosan.org/speeding-up-eclipse-a-bit-with-unlockexperimentalvmoptions/
http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html
http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
http://performance.netbeans.org/howto/jvmswitches/
