5 Replies Latest reply on Jul 16, 2002 3:21 PM by Dain Sundstrom

    read-ahead->on-find->page-size performance issues

    razafinimanana Newbie

      I'm using JBoss 3.0 on NT4 with Oracle 8.1.7. My database
      is accessed remotly (on another computer). I order to
      increase performance, and avoid several remote-call to
      Oracle, I use "load-group","read-head", and "on-find" features (I have about 166 records to retreive).
      After setting my "ejb-jar.xml" with previous features, I have reduced response time. But the more I reduced "page-size" the more the application is fast ??

      <read-ahead>
      on-load
      <page-size>10</page-size>
      <eager-load-group>basic</eager-load-group>
      </read-ahead>

      IS BETTER THAN

      <read-ahead>
      on-load
      <page-size>100</page-size>
      <eager-load-group>basic</eager-load-group>
      </read-ahead>

      Can someome explain me/know the right usage of "page-size" ???

      Regards

      Anjarivo RAZAFINIMANANA

        • 1. Re: read-ahead->on-find->page-size performance issues
          Dain Sundstrom Master

          This is covered in the JBossCMP documentation available from FlashLine ($10).

          • 2. Re: read-ahead->on-find->page-size performance issues
            razafinimanana Newbie

            I've bought the "full-package" at 60$ for 6months.
            On your manual "JBossCMP" page 48 we can read:
            "...the page size is set to four, JBoss will execute..
            SELECT ... WHERE (id=0) OR (id=1) OR (id=2) OR (id=3)
            AND
            SELECT ... WHERE (id=4) OR (id=5) OR (id=6) OR (id=7)"
            What I understand is "page-size" allow JBoss to retreive
            a chunk of Data in one operation. But according to my
            experience It seems that the smallest is "page-size" the
            better it is to retreive data ??? In ideal world, it SHOULD be the opposite ;-) (less network traffic, less "SELECT" instruction on server side, produce better
            performance ! )

            • 3. Re: read-ahead->on-find->page-size performance issues
              razafinimanana Newbie

              I've bought the "full-package" at 60$ for 6months.
              On your manual "JBossCMP" page 48 we can read:
              "...the page size is set to four, JBoss will execute..
              SELECT ... WHERE (id=0) OR (id=1) OR (id=2) OR (id=3)
              AND
              SELECT ... WHERE (id=4) OR (id=5) OR (id=6) OR (id=7)"
              What I understand is "page-size" allow JBoss to retreive
              a chunk of Data in one operation. But according to my
              experience It seems that the smallest is "page-size" the
              better it is to retreive data ??? In ideal world, it SHOULD be the opposite ;-) (less network traffic, less "SELECT" instruction on server side, produce better
              performance ! )

              • 4. Re: read-ahead->on-find->page-size performance issues
                razafinimanana Newbie

                I've bought the "full-package" at 60$ for 6months.
                On your manual "JBossCMP" page 48 we can read:
                "...the page size is set to four, JBoss will execute..
                SELECT ... WHERE (id=0) OR (id=1) OR (id=2) OR (id=3)
                AND
                SELECT ... WHERE (id=4) OR (id=5) OR (id=6) OR (id=7)"
                What I understand is "page-size" allow JBoss to retreive
                a chunk of Data in one operation. But according to my
                experience It seems that the smallest is "page-size" the
                better it is to retreive data ??? In ideal world, it SHOULD be the opposite ;-) (less network traffic, less "SELECT" instruction on server side, produce better
                performance ! )

                • 5. Re: read-ahead->on-find->page-size performance issues
                  Dain Sundstrom Master

                  I find this hard to believe, but I guess that is the way your database works. Simply compare the size of the query with the amount of raw data required for the response.

                  Since there is no other way to block load data you will have to either load all of you data on-find or not use optimized loading. Do you have a better solution?