OFBiz
  1. OFBiz
  2. OFBIZ-4366

Accessing Ofbiz Entity UtilCache is time consuming

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: Release 4.0
    • Fix Version/s: Release Branch 4.0
    • Component/s: framework
    • Labels:
    • Environment:

      Producttion Environment Issue. In one particular request, we are accessing UtilCache object 200 times via Generic Delegator, findByConditionCache and findCache methods to read entity values.

      Description

      Its have been found that it is taking 3 to 4 seconds only for that. Is this some thing that how is built or ?

        Activity

        Hide
        Arun Kumar Sri added a comment -

        We have been using Ofbiz Framework for around 3 years. All these days, we are not using some expensive operation to access 300 in a single request.
        But now the some design constraints are forcing to do this. We will be changing the design to some how reduce this.
        How ever, at the same time, reading from UtilCache [a map within it] should not take this much seconds. Can you help us with this!

        Show
        Arun Kumar Sri added a comment - We have been using Ofbiz Framework for around 3 years. All these days, we are not using some expensive operation to access 300 in a single request. But now the some design constraints are forcing to do this. We will be changing the design to some how reduce this. How ever, at the same time, reading from UtilCache [a map within it] should not take this much seconds. Can you help us with this!
        Hide
        Jacques Le Roux added a comment -

        Sorry, though there is no official policy (we lack one, I will begin a discussion about it) the release 4.0 is not supported (much) anymore. So, except fro trivial question, don't expect much support on.

        2 other points:

        1. This is not a bug. Anyway a bug would more descriptive information. It's better to ask question on user ML.
        2. One way you could try is to replace the Minverva connection pool management by Apache DBCP. This has been done just after the rel. 4.0 because there were some problems with it. Unfortunately, IIRW, they were no performance issues. But you could still try to upgrade this part. Also I'd check how much memory you have available...
        Show
        Jacques Le Roux added a comment - Sorry, though there is no official policy (we lack one, I will begin a discussion about it) the release 4.0 is not supported (much) anymore. So, except fro trivial question, don't expect much support on. 2 other points: This is not a bug. Anyway a bug would more descriptive information. It's better to ask question on user ML. One way you could try is to replace the Minverva connection pool management by Apache DBCP. This has been done just after the rel. 4.0 because there were some problems with it. Unfortunately, IIRW, they were no performance issues. But you could still try to upgrade this part. Also I'd check how much memory you have available...
        Hide
        Arun Kumar Sri added a comment -

        I apologize for sticking with Version 4 and not moving for further versions as my client wont pay for that
        Apologize that i did not give much information whilst describing the bug.
        So the bug statement is: "Accessing UtilCache Object for more than 200 times in a single request is taking more than 4 seconds to fetch the cached entity results ".

        My application is deployed in Weblogic Server. I traced the code within Ofbiz and found that core component is using the connection pool that is created in Weblogic Server to connect to DB. Is this called as "minerve connection pool management".
        Then how do we change the implementation to Apache DBCP?

        I found it is taking around 8 ms to read the one value from Cache. UtilCache is a sycnhornized one.
        So imagine 1000 times we are reading the UtilCache object in a single request.
        (1000*8ms) is not desirable one for a webpage wher my customers would stop using either!

        So this some thing i can fix or should i change my implementation to not to use the UtilCache often .

        Any ideas would really help me.

        Show
        Arun Kumar Sri added a comment - I apologize for sticking with Version 4 and not moving for further versions as my client wont pay for that Apologize that i did not give much information whilst describing the bug. So the bug statement is: "Accessing UtilCache Object for more than 200 times in a single request is taking more than 4 seconds to fetch the cached entity results ". My application is deployed in Weblogic Server. I traced the code within Ofbiz and found that core component is using the connection pool that is created in Weblogic Server to connect to DB. Is this called as "minerve connection pool management". Then how do we change the implementation to Apache DBCP? I found it is taking around 8 ms to read the one value from Cache. UtilCache is a sycnhornized one. So imagine 1000 times we are reading the UtilCache object in a single request. (1000*8ms) is not desirable one for a webpage wher my customers would stop using either! So this some thing i can fix or should i change my implementation to not to use the UtilCache often . Any ideas would really help me.
        Hide
        Jacopo Cappellato added a comment -

        The release branch 4.0 is no more actively maintained.

        Show
        Jacopo Cappellato added a comment - The release branch 4.0 is no more actively maintained.

          People

          • Assignee:
            Jacques Le Roux
            Reporter:
            Arun Kumar Sri
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 0.05h
              0.05h
              Remaining:
              Remaining Estimate - 0.05h
              0.05h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development