3 Replies Latest reply on Dec 12, 2008 5:10 AM by manik

    jbosscache performance

    rich11

      I am doing a performance testing using jbosscache, and here is the problem:

      I basically add some test data in jboss cache and try to evaluate the perform of read. But it is interesting to found that cache read can be slow once a while, and it took 1328 millisecond to perform 1000 read, which is very bad. Here is part of result of cache read in millisecond:

      0
      15
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      16
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      16
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0
      0

      I am doing a simple read as:

      Node rootNode1 = cache.getRoot();
      Fqn p1 = Fqn.fromString("/c3");
      Node n1 = rootNode1.getChild(p1);
      Object cc = n1.get(key);

      My configure file is:

      
      <?xml version="1.0" encoding="UTF-8"?>
      <jbosscache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:jboss:jbosscache-core:config:3.0">
      
      <locking isolationLevel="READ_UNCOMMITTED" lockAcquisitionTimeout="15000"/>
      <transaction transactionManagerLookupClass="org.jboss.cache.transaction.GenericTransactionManagerLookup"/>
      <jmxStatistics
       enabled="false"/>
      <eviction wakeUpInterval="0">
      <default algorithmClass="org.jboss.cache.eviction.LRUAlgorithm">
      <property name="maxNodes" value="50"/>
      <property name="timeToLive" value="-1"/>
      </default>
      </eviction>
      </jbosscache>
      
      
      

      Any suggestion?


      Thanks,

      Rich

        • 1. Re: jbosscache performance
          manik

          Note that JBC3 only supports REPEATABLE_READ and READ_COMMITTED. So your READ_UNCOMMITTED setting effectively gets upgraded to READ_COMMITTED.

          What's the purpose of setting your eviction wakeup interval to 0? You realise that the eviction thread will not run with such a setting, so your eviction settings after that are pointless.

          Finally, in your test, is this run with a single thread? Do you have anything else happening at the same time, e.g., writers? Have you tried profiling this? If you don't have any other concurrent activity, especially writes, the spikes you see could be GC spikes, as it does seem to be pretty regular. What memory settings have you configured your VM with?

          • 2. Re: jbosscache performance
            rich11

            Thank you for your reply.

            I changed config file to use REPEATABLE_READ, as well as wakeUpInterval. But that does not impact the result much. BTW, I use default JVM setting.

            We plan to use jboss cache to share some data in cluster environment. 99% will be read activity, and the data in cache is most Hashmap. We will access cache up to 20 thousand times per transaction, but like to keep response time as fast as possible.

            How do I tune Jboss cache (and JVM) to get best performance?

            Thanks,

            Rich

            • 3. Re: jbosscache performance
              manik

              READ_COMMITTED would actually give you better performance if you don't require REPEATABLE_READ guarantees.

              wakeUpInterval - if you don't need eviction, then remove the whole eviction XML block. From your initial post it seems as though you were not using it and hence didn't need it? If you do need it then that's a different story.

              Do your reads happen inside of a transaction? E.g., do you do :

              1. Start tx
              2. Read stuff
              3. End tx

              Or were you using "transactions per second" to mean "operations per second"?

              Regarding JVM tuning, that's a whole science in itself and will depend on a bunch of parameters including, but not limited to, system architecture (32 vs 64 bit), operating system, JVM version and vendor, operating environment (e.g., app server config) memory requirements of your application itself, amount of and type of data cached, etc.