5 Replies Latest reply on Jun 20, 2006 3:38 PM by arshadnj

    JBPM Scalability

    arshadnj
    arshadnj Jun 6, 2006 5:43 PM

      I just ran a test on the sample (reference) web application provided by the jbpm-starters-kit-3.1.1. The test was to create an order using 'Cookie monster' login, later I traced the generated SQL statements. What I founds was around 40+ insert statements for the following JBPM tables JBPM_VARIABLEINSTANCE, JBPM_TOKENVARIABLEMAP, JBPM_SWIMLANEINSTANCE, JBPM_TIMER, JBPM_TASKINSTANCE, JBPM_LOG, JBPM_MODULEINSTANCE

      I am wondering did I miss something or is this the expected behavior? It is very expensive for my application, which is more complex than the sample application provided JBPM to handle 40+ insert statement + another set of update statements for each of the major transaction of the system.

      Can you please clarify this? Is there a way I can optimise this?

      Thanks,
      Arshad

      • 4266 Views
      • Tags:
        • 1. Re: JBPM Scalability
          arshadnj
          arshadnj Jun 7, 2006 10:00 AM (in response to arshadnj)

          I just ran a test on the sample (reference) web application provided by the jbpm-starters-kit-3.1.1.

          The test was to create an order using 'Cookie monster' login, later I traced the generated SQL statements.
          What I founds was around 40+ insert statements for the following JBPM tables JBPM_VARIABLEINSTANCE, JBPM_TOKENVARIABLEMAP, JBPM_SWIMLANEINSTANCE, JBPM_TIMER, JBPM_TASKINSTANCE, JBPM_LOG, JBPM_MODULEINSTANCE

          I am wondering did I miss something or is this the expected behavior? It is very expensive for my application, which is more complex than the sample application provided JBPM to handle 40+ insert statement + another set of update statements for each of the major transaction of the system.

          Can you please clarify this? Is there a way I can optimise this?

          Thanks,
          Arshad

            • Actions
          • 2. Re: JBPM Scalability
            tom.baeyens
            tom.baeyens Jun 7, 2006 6:50 PM (in response to arshadnj)

            there is a lot of room for optimisation. so far we focussed on getting it running out of the box on as many environments as possible.

            now we will be focussing on optimizing a bit and documenting in a wiki page to describe what the typical performance optimisation options are and what the tradeoff is.

              • Actions
            • 3. Re: JBPM Scalability
              arshadnj
              arshadnj Jun 8, 2006 1:33 PM (in response to arshadnj)

              I disabled the logging it reduced significantly the number of insert statements (cuz now it is not inserting inside jbpm_log table) but still around 40+ insert and update statements.

              I am wondering whether any one is using this product in production and how is the performance for typical application with around hundred thousand records?

                • Actions
              • 4. Re: JBPM Scalability
                bviveiros
                bviveiros Jun 20, 2006 11:24 AM (in response to arshadnj)

                How did you disable the logging? I'm trying to do the same.

                Thanks.

                  • Actions
                • 5. Re: JBPM Scalability
                  arshadnj
                  arshadnj Jun 20, 2006 3:38 PM (in response to arshadnj)

                  You can try commenting the following line inside jbpm.cfg.xml:

                  <service name="logging" factory="org.jbpm.logging.db.DbLoggingServiceFactory" />


                  Let me know if this doesn't work for you.

                  Btw, are you using this in production and how is your performance?

                  I didn't really try running any profilers or something yet to determine the performance issues but would appreciate hearing from other folks.

                  Thanks,
                  Arshad

                    • Actions