14 Replies Latest reply on Jul 23, 2004 5:58 AM by myname

    "on-load" read-ahead strategy returns counterintuitive resul

    ravi-ryali

      Hi,

      My server code has been deployed on JBoss 3.2.1 running on Win2K. I am using CMP to load data from the database. When I use the following strategy in my CMP query using EJB-QL

      <read-ahead>
      on-load
      <page-size>5</page-size>
      </read-ahead>

      it takes me around 10 sec to load 2000 rows from the database. But when I increase the page-size to 10, the response time increases to 15 sec. The server's performance is best when I am using page-size of 1. These results look counter-intuitive to me. By increasing the page-size, am I not reducing the number of SQL requests to the database and hence, doesn't my response time have to improve? I believe that there is also a constraint from the pre-load cache point of view but is there a way we can increase the size of that cache? I would appreciate if any one could let me know what I am missing here.

      On another note, I would appreciate if you could direct me as to how to increase CMP performance. I have made my methods read-only, kept them out of transactions, and I am using read-ahead. Is there anything else which can improve the performance?

      Any suggestion or pointer is sincerely appreciated.

      Thanks,
      Ravi


        • 1. Re:
          aloubyansky

          Just remove read-only and access entities in a transaction.

          • 2. Re:
            ravi-ryali

            I appreciate your response. I am sorry to bug you on this but I have not quite understood the logic here. Do you mean to say that by including the method in a transaction or by not making it read-only, I will have a faster response? Could u please let me know how read-only or a transaction affect read-ahead strategy?

            Thank you,
            Ravi

            • 3. Re:
              aloubyansky

              Read-ahead cache is a per transaction cache. So, it makes sense to preload only the data that is going to be used in the transaction. If there is no transaction then preloaded data is thrown away after the invocation.

              read-only in jboss.xml has almost the same effect as running w/o transactions. Read-only instance is not associated with the transaction (hence, is not synchronized at commit), is locked only for the duration of the invocation, and is evicted from the cache at the end of the invocation. It means each invocation even in the same tx will reload the instance from the db.
              On-find read-ahead makes sense for read-only instance only if it is accessed once (one invocation) in the transaction: finder preloads the instance, the next invocation on the instance will load data from the read-ahead cache but after this invocation the instance will be evicted from the cache and the next invocation will reload the instance from the db.

              • 4. Re:
                aloubyansky

                If you use commit option A then the instance won't be evicted from the cache after a read-only invocation.

                • 5. Re:
                  ravi-ryali

                  Alex,

                  Thank you very much for your response. Thanks to you, I could cut down the response time to less than 3 seconds from almost 20 seconds. That is 85% reduction. Like you said, I enlisted the operation in a transaction and used read-ahead. But I was wondering on a couple of things. I am sure you could help me out here too.

                  1. When I look at the server log, I see SQL statements like the one below,

                  Executing SQL: SELECT AdvertiserID, Name, Address, AgencyID FROM Advertiser WHERE (AdvertiserID=?) OR (AdvertiserID=?).

                  This becomes a very ineffcient statement if the page-size grows to 500. 'IN' clause might be very effective there. Is there a way for me to use 'IN' clause there to speed up the SQL statement? Can that be configured?

                  2. Is there a benchmark as to what is optimal performance? If the performance of CMP is close to retrieving the data using a JDBC call, can I call it the most optimized CMP call? I mean, how much ever I optimize CMP, it cannot be faster than a JDBC call, right?

                  Your responses will be greatly appreciated.

                  Thanks,
                  Ravi

                  • 6. Re:
                    aloubyansky

                    1. No, it's not configurable. I might look look at using IN but not in the nearest future unless someone comes up with a patch. But keep in mind that there also are compound primary keys that should still use OR like
                    (col1=? and col2=?) [or (col1=? and col2=?)]. I would recommend using on-find where possible.

                    2. CMP is implemented on top of JDBC. So it can't be faster than JDBC in loading data.

                    • 7. Re:
                      gozilla

                      Alexey,


                      read-only in jboss.xml has almost the same effect as running w/o transactions. Read-only instance is not associated with the transaction (hence, is not synchronized at commit), is locked only for the duration of the invocation, and is evicted from the cache at the end of the invocation. It means each invocation even in the same tx will reload the instance from the db.


                      When CMP handles read-only that way (in option-B), isn't it completelly defeating the usefullness of it ?
                      Read-only is also used to avoid TX locking.
                      I can understand purging the cache on TX demarcations, or on exceptions, but why doing it during a TX ?

                      This change of behaviour between 3.2.1 and 3.2.3 is a performance killer for beans running in B mode.
                      To get decent performance, we have to go back to TX deadlocks if we cannot go for A mode.

                      Do I miss something ?

                      Francois


                      • 8. Re:
                        myname

                        Francois,

                        yes you miss something. You might have a look at

                        http://www.jboss.org/index.html?module=bb&op=viewtopic&t=49002

                        and Adrian's comment
                        Don't use commit option B. I know it is the default configuration, but it is stupid.


                        I do not agree with him, but it seems as if our remarks do not are not really aheard ...

                        Regards

                        Volker

                        • 9. Re:
                          aloubyansky

                          I think this can be fixed by not evicting read-ahead data (per tx data) when loading instance from read-ahead. In this case, read-only (jboss.xml) instances will be reloaded from read-ahead instead of the database.
                          I will add a config option for this.

                          • 10. Re:
                            aloubyansky

                            The reason for eviction of a instance after a read-only (jboss.xml) invocation is that the transaction might perform mixed read-only and modifying invocations. There is a risk for cocurrent transactions getting uncommitted data.
                            The fix from my previous post should fix it.

                            • 11. Re:
                              myname

                              Alexey,

                              is that fix already available (and how to use it)?

                              Regards

                              Volker

                              • 12. Re:
                                aloubyansky

                                Not yet. I will you know when it is.

                                • 13. Re:
                                  aloubyansky

                                  This is implemented in 3.2.5. There is a new config option <clean-read-ahead-on-load> wich can optionally appear in [standard]jbosscmp-jdbc.xml in and .
                                  The default value in standardjbosscmp-jdbc.xml is false which fixes the problem with re-loading the instance from the db (it's reloaded from the read-ahead cache instead).

                                  • 14. Re:
                                    myname

                                    And it works as expected. Thank you, Alexey!

                                    3.2.5 seems very useable to me currently. Good job.

                                    Volker