Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    JPA Datasource : can't get dropExtraFields to work

    Hi everyone,

    I'm using JPA datasources, and I noticed the fetch operations to be very slow. Looking at the console in the RPC tab, I noticed that the DSReponse comes with all the datasource fields, which raises 2 performance issues in my opinion :
    - bandwith usage
    - useless server side processing. Measured around 10 seconds between the "INFO DSResponse - DSResponse: List with 42 items" log, and the actual data showing on the browser (IE10 in dev mode, on localhost). Not sure what happens during those precious seconds, probably Records creation from entities ?

    I tried to flag my datasources with dropExtraField option set, but it has no effect.

    Can anyone help me please with either or both of these questions :
    -Does JPA Datasource support the dropExtraField flag ?
    -How can I improve server side processing ?

    Thanks a lot in advance,

    Fz


    I'm using Version: v8.3d_2012-10-24/PowerEdition Deployment (built 2012-10-24)

    #2
    dropExtraFields not dropExtraField as you had it.

    Most likely you are loading huge trees of related entities, and as soon as you specify this property your performance problem will be fixed, with nothing else to optimize.

    Comment


      #3
      Thank you for this rapid answer.

      Unfortunately it was spelled correctly in the datasources declaration files, here's the header :

      Code:
      <DataSource ID="intervention" serverType="jpa"
      	beanClassName="com.domain.Intervention"
      	schemaBean="com.domain.Intervention"
      	dropExtraFields="true">
      If you need any other information (e.g. a full test case), please let me know.

      Bests,

      Fz

      Comment


        #4
        You should check the data being returned from the server in the RPC tab.

        If you see a large amount of data with a bunch of nested objects, you've either still not correctly set dropExtraFields or one of the fields you've specified as being delivered to the client is an object field connected to a bunch of other structures. If the latter, see the JPA and Hibernate Relations overview on options for loading and saving relation fields.

        If there's not much data but its still slow, one of your getter methods must be taking a very long time.

        Comment


          #5
          Thank you isomorphic.

          Actually there are not nested objects etc, just too many fields sent to the client. I tried using a second "light" datasource definition with only the fields I need, but the DSResponse keeps sending all the entity's fields.

          So there may be an issue with one of my getters, I will investigate and let you know if I can improve it.

          Thanks

          Fz

          Comment


            #6
            Hi,

            Can you post complete entity and data source definition ?

            What data base do you use?

            Regards,
            Alius

            Comment


              #7
              Hello Alius,

              Sorry for the late reply, I was away for a while. It finally appeared that the performance issue was related to the "includeFrom" property, which I replaced with a valueXPath property. I don't know why, but with this small change the performance is now really much better.

              If it can help anyone...

              Fz

              Comment


                #8
                That's interesting that that was your experience, however, we would strongly recommend that no other user try to troubleshoot performance problems by starting with changing includeFrom fields to valueXPath fields. They actually use the same underlying mechanism, but includeFrom would be expected to be faster.

                faycalz' results could be due to lots of things (bad JPA/Hibernate configs, not actually testing valueXPath vs includeFrom as the only difference, etc) and we think it's very unlikely another user would hit the same performance benefit. Instead, start with the common performance issues listed in the FAQ.

                Comment

                Working...
                X