10 Replies Latest reply on Feb 13, 2002 7:23 AM by vincent

    Faster Data Access

    ronster

      I'm trying to find the fastest and least resource intensive way of bringing back a read-only catalog listing to a web page.

      I've tried using the Fast-Lane Reader pattern and created a stateless session bean which returns a RowSet to my controller servlet's action bean.

      This has proved to be the fastest method the EJB way, but it is still significantly slowing then if I access the data directly from my action. Jmeter tests for the same query gives me, for 50 threads avg 1600ms for direct and 2100ms for using EJB, for 100 threads avg 3500ms direct and 4800ms EJB.

      I've tried using opitimized=true but it does not seem to make any difference.

      Am I doing anything wrong? Or is this always going to the case? And the only benefit for going the EJB way is that all my logic and data access is held in the container.

      Thanks in advance for any thoughts.

        • 1. Re: Faster Data Access
          vincent

          > I'm trying to find the fastest and least resource
          > intensive way of bringing back a read-only catalog
          > listing to a web page.
          >
          > I've tried using the Fast-Lane Reader pattern and
          > created a stateless session bean which returns a
          > RowSet to my controller servlet's action bean.
          >
          > This has proved to be the fastest method the EJB way,
          > but it is still significantly slowing then if I
          > access the data directly from my action.

          Do you mean calling the method that gives you the RowSet directly ?

          > Jmeter tests
          > for the same query gives me, for 50 threads avg
          > 1600ms for direct and 2100ms for using EJB, for 100
          > threads avg 3500ms direct and 4800ms EJB.
          >
          > I've tried using opitimized=true but it does not seem
          > to make any difference.

          Do you run servlet/ejb in one EAR ? or war/ejb-jar separated ?

          >
          > Am I doing anything wrong? Or is this always going to
          > the case? And the only benefit for going the EJB way
          > is that all my logic and data access is held in the
          > container.

          I would say the contrary : you have done all perfectly well ;) You add 500 msec / 50 = 10 msec per session bean calls. In this you have transaction starts (try NotSupported as trans attribute if you did not use it.), security checking, instantiation of session bean (do you use the new container pool feeder ?)
          Also try to turn log4j to INFO only (I read somewhere a factor 10 in perf improvement here !)

          Now promise me: you come back with results ! I want to see "1600ms for direct and 1601ms for ejb"

          • 2. Re: Faster Data Access
            ronster

            setting log4j to INFO did not help

            where do I set NotSupported as trans attribute?

            can you tell me more about the new container pool feeder?

            In answer to your questions...
            yes, I create the rowset from the datasource within my action
            I'm using servlet/ejb in same ear

            thanks
            Ron

            • 3. Re: Faster Data Access
              ronster

              I've now got it down to comparable performances

              low 1600ms for direct and high 1600ms for ejb

              I've put the ejb lookup in a static method for the action

              eg.
              static DomFastLane catalog;

              static {
              try {
              InitialContext iniCtx = new InitialContext();
              Object ref = iniCtx.lookup("DomFastLaneEJB");
              DomFastLaneHome home = (DomFastLaneHome) ref;
              catalog = home.create();
              } catch (Exception e) {
              e.printStackTrace();
              }
              }
              }

              this caches the JNDI lookup so it happens only once

              thanks Vincent for pointing me to look in this direction

              would still be interested in ideas in making this go even faster, if anyone has ideas...

              thanks
              Ron

              • 4. Re: Faster Data Access
                vincent

                NotSupported is one of the transaction attribute you can set on method in ejb-jar.xml - read an EJB book ;) The other are required, Supports, ...
                Anyway, i don't think it will give you a big saving, leave this one for the end.

                What is strange is the log4j that did not change anything...Can you try without any log4j.properties anywhere (you must receive an error at stratup) to be sure another one is not taken... You are running 2.4 or 3.0 My remarks applied to 3.0, when 2.4 you have INFO by default I think.

                Pool feeder : the session beans will be instantiate at startup of container. You need latest jboss 2.4/3.0 and chnage standardjboss.xml

                <container-pool-conf>
                 <MaximumSize>50</MaximumSize>
                 <feeder-policy>org.jboss.ejb.plugins.TimedInstancePoolFeeder</feeder-policy>
                 <feeder-policy-conf>
                 <increment>2</increment>
                 <period>5000</period>
                 </feeder-policy-conf>
                </container-pool-conf>
                

                For the container "Standard Stateless SessionBean".
                Put a message in setSessionContext(), start JBoss you will see 50 times the message. OK ?

                EAR means for sure no Serialization, that is already one p... less in the a...


                • 5. Re: Faster Data Access
                  vincent

                  Sorry I forgot THE MOST IMPORTANT ONE:

                  How do you get the home interface of your session beans from your servlet ? (new InitialContext()....)

                  Only one time I hope, I mean you cache it in a singleton ?

                  This will really be the first think to do ! Look at ServiceLocator pattern on Sun or TSS.

                  • 6. Re: Faster Data Access
                    vincent

                    YOU ONLY PROVE ONE THING :

                    Calling an EJB in JBOSS is as fast as calling a Java Class.

                    :-)

                    • 7. Re: Faster Data Access
                      ronster

                      it rocks...

                      by using the pool feeder and singleton pattern, i'm getting below 1600ms via EJB

                      many thanks
                      Ron

                      • 8. Re: Faster Data Access
                        vincent

                        If you have some more time to spend:
                        Make an entity bean with a finder matching your sql.
                        Deploy it as read-only or use commit-option A
                        Specify read-ahead true
                        Mark it as NotSupported (not spec compliant but what the fuck)
                        Now call it through your session beans.
                        ...and come back with numbers

                        Then you'll begin to love entity beans as well :)

                        • 9. Re: Faster Data Access
                          ronster

                          unfortunately this seems to be slower avg 2200ms for 50 threads

                          I've made an entity bean (CMP) with finder method
                          deployed it as read-only and specified read-ahead true
                          also marked it as NotSupported

                          But, surely, they would not have come up with the Fast-Lane Reader pattern if this can be faster?


                          > If you have some more time to spend:
                          > Make an entity bean with a finder matching your sql.
                          > Deploy it as read-only or use commit-option A
                          > Specify read-ahead true
                          > Mark it as NotSupported (not spec compliant but what
                          > the fuck)
                          > Now call it through your session beans.
                          > ...and come back with numbers
                          >
                          > Then you'll begin to love entity beans as well :)

                          • 10. Re: Faster Data Access
                            vincent

                            Hey great ! Happy to fight this one :)

                            > unfortunately this seems to be slower avg 2200ms for
                            > 50 threads

                            Against 1600 ms that is not that bad.

                            >
                            > I've made an entity bean (CMP) with finder method
                            > deployed it as read-only and specified read-ahead
                            > true
                            > also marked it as NotSupported
                            >
                            > But, surely, they would not have come up with the
                            > Fast-Lane Reader pattern if this can be faster?

                            Yes, entity cmp still sucks a bit for "batch" read.
                            IMHO a small bit only.
                            Most of the time the "they"'s tell that difference is a factor 10 (or even 100) times slower. Here we didn't even have a factor 2 ! Wow.

                            Maybe if you take read-ahead off and read-only true you will be faster :

                            50 * [select pk from table where true (findAll)]
                             + y * [select * from table where pk='pky' (ejbLoad on first call)]
                            

                            where y is the number of data to read

                            Now we have
                            50 * [ select * from table where true (findAll+readahead) ]
                            


                            But here it will become cheating ;)
                            You also need to measure on the long run (50==> 5000), refresh your reading sometimes (no more read-only), ...
                            Here we will go too far I guess.