2 Replies Latest reply on Jun 8, 2011 2:27 PM by Bill Robinson

    Double Your CLI Speed (with nearly no effort)

      I've been interested in ways to speed up BladeLogic for quite a few years - even back in 2008 I was trying to figure out how to scale the app*.


      While working on a performance issue in my environment, I wrote some code to track JVM memory usage, and I've used that to evaluate the impact of various JVM settings on JLI*** performance.


      In a nutshell, I was able to double performance by tuning the JVM.


      Here's the data.


      With the "stock" settings, by benchmark took 62 seconds to complete.  The "stock" settings give the JVM 256 megs of ram to work with.

      By removing the memory limits on the JVM, my benchmark dropped to 35 seconds, a speed bump of seventy seven percent.

      By hard-coding the JVM to use two gigs, my benchmark dropped to 32 seconds, a speed bump of ninety four percent.


      You could probably write a book on Java memory usage; a cursory review of the Sun/Oracle forums will provide plenty of food for thought****.  But it appears that removing the artificial limit of 256 megabytes from the JLI JVM has significant benefits.  The law of diminishing returns also shows us that the most generous settings yield diminishing results.  For instance, when I let Java manage the JVM it used 881 megabytes, but when I set a hard limit of two gigs it yielded an incremental (but significant) improvement.


      * an article I wrote back when I worked for BladeLogic:  https://communities.bmc.com/communities/thread/38089

      ** here's the post from earlier today, about JLI logging:  https://communities.bmc.com/communities/message/185556#185556

      *** JLI is basically the BladeLogic CLI accessed via Jython.  A lot of articles simply refer to it as "Jython."

      **** info on Xmx/Xms: http://forums.oracle.com/forums/thread.jspa?threadID=968695

        • 1. Re: Double Your CLI Speed (with nearly no effort)

          All BladeLogic environments are different, therefore I would advise benchmarking these settings for yourself.  You can adjust the JVM heap used by the JLI by editing the shell script which starts jython.  In my environment it's called "bljython."  Note that you can easily use multiple scripts, just adjust the scripts which call bljython accordingly.


          Here's my benchmark.  It is very simple - it just pulls a list of servers, and times how long it takes to execute via Java's runtime library.  (If I'm not mistaken, the memory listed in the app server logs is for the app server JVMs, not the JLI JVM.)  You could substitute any command which you like, or a whole suite of commands.  I chose this command because it was causing issues in my environment, failing due to a lack of memory.


          The first line in this jython script should point to your customized shell script.  IE, create two or three shell scripts, each with unique Xmx and Xms settings, then run the benchmark for each setting.  This should help you determine what setting gives you the best balance of speed and memory usage.


          #! /usr/bin/env /bladelogic/nsh/br/bljython

          import bladelogic.cli.CLI as blcli
          from java.lang import Runtime
          import time


          def listServers(startTime):
               cmd = []

               maxMemory = (Runtime.getRuntime().maxMemory()/1048576);
               freeMemory = (Runtime.getRuntime().freeMemory()/1048576);
               allocatedMemory = (Runtime.getRuntime().totalMemory()/1048576);
               logtime2=time.strftime("%a %m/%d %H:%M:%S",time.localtime(time.time()))
               print "JVM Free Memory = %sM, allocated memory = %sM, maximum memory = %sM.\n" % (freeMemory, allocatedMemory, maxMemory)
               print "Program started at %s; this command finished at %s." % (startTime, logtime2)


          # main

          logtime1=time.strftime("%a %m/%d %H:%M:%S",time.localtime(time.time()))

          cli = blcli.CLI()
          blcliResult = cli.connect()


          for i in range (5):

          • 2. Double Your CLI Speed (with nearly no effort)
            Bill Robinson

            What OS and Arch were you running this on, and what arch was the jvm?


            so are you setting both Xmx and Xms to 2g? 


            the only problem w/ 2g is that if you spin up a bunch of blcli (like a nsh job) you could hoze your appserver, though the same is possible w/ the 256m heap, it would just happen a little faster