1 2 Previous Next 15 Replies Latest reply on Jan 30, 2007 10:50 AM by Norman Richards

    Seam + EJB3 performance

    Vladimir Kovalyuk Apprentice

      I'm concerned about impressive stack traces.
      Considering SFSB as backing beans for JSF we need to take into account a lot of interceptors introduced by EJB3 (JBOSS implementation) and Seam.
      So I'd like to raise question about possible optimization on that matter. I believe that hundred calls costs a lot.

      There is another side of this question. I realized that I like to back JSF page by SFSB with extended persistence context in a Seam conversational context. It allows me to forget about LazyInitializationException and display on the page (or pageflow) whatever I want.
      But having investigated a lot I realized that number of interactions between JSF and SFSB is pretty big. Every bean dereference leads to impressive work of interceptors. And now I understand that I want either approach of omitting numerous interactions with SFSB or optimization in JBOSS and Seam when only required interceptions are made.

        • 1. Re: Seam + EJB3 performance
          Vladimir Kovalyuk Apprentice

          And I don't find it convenient when I need to scroll a hundred lines in stack trace or Threads Window in order to find out what is the caller of my method.

          • 2. Re: Seam + EJB3 performance
            Norman Richards Master

            Do you observe any performance issues or are you just guessing?

            • 3. Re: Seam + EJB3 performance
              Vladimir Kovalyuk Apprentice

              To be honest the latter.
              If I were able to perform true performance tests I'd provided you with figures.
              I thought you already have them.
              I just wanted to draw attention to the fact that contents of callstack between caller and callee is a very long journey and must cost a lot, even not taking into account some sorts of fine grained optimizations like branch predictions, cache locality and so on (that might cost even 30% of performance, you shouldn't ignore even that, ask Intel).
              You decide whether it is important. I believe technical risks should be eliminated as soon as possible, otherwise they could stop project success.

              And I believe that overhead of supporting contexts should be significantly cheaper than cost of useful business code. When I see 150-200 lines in stack trace and sole business method among them I don't find it reasonable.

              • 4. Re: Seam + EJB3 performance
                Norman Richards Master

                I think it is well understood that there is good bit of overhead involved. The tests so far have indicated that the performance is quite reasonable in practice. If you observe actual performance issues we'd be very interested to know of them.

                • 5. Re: Seam + EJB3 performance
                  Vladimir Kovalyuk Apprentice

                  It seems that I do.
                  There are menu with pop-up sub-menus on the top, tree with context menus on the left panel, and list of contents on the right panel. You can see that sort of design in Windows Explorer for instance.
                  Usually the page is rendered (starting from second attempt) immediately, I mean so very quickly I don't know how long it takes.
                  But when I tried to fill the tree with 30 elements and content of its nodes with 25 elements I saw that page is rendered more slowly, say about one minute.
                  The page asks backing SFSB beans for menu. every node, every context menu item for node, every item in the list and every context menu item for the list. So, I can suppose that overall number of interactions is about 400 (or twice as more due to JSF lifecycle ...). If I try to use normal persistence context instead of extended then LazyInitException occurs.
                  But when I use extended context I'm concerned about why my page is rendered so long.
                  I understand that I need to measure the time of interaction but actually I don't know how to do it.

                  • 6. Re: Seam + EJB3 performance
                    Norman Richards Master

                    I can't believe that it would take a minute to render even a data set several orders of magnitude larger. Do you have a simple test case that can demonstrate the behavior?

                    • 7. Re: Seam + EJB3 performanceL
                      Christian Bauer Master

                      Enable the SQL log. I'm 99% sure that you simply execute hundreds of SQL queries when the tree is rendered. Read up on explode()/CONNECT BY operators in SQL, and workarounds with "nested set" and "materialized path" (use Google). In Hibernate, you can also think about batch fetching.

                      Do not optimize or even think about any method call stacks before you optimize the interaction with the database system. If you want to know more about this, specific to Hibernate, read http://www.manning.com/bauer2

                      • 8. Re: Seam + EJB3 performance
                        Vladimir Kovalyuk Apprentice

                        Christian, thanks a lot for hints. It's interesting topic.
                        Being impressed by long SQL statements generated by Hibernate and understanding that most of them are not required I decided that I need to try an idea of SFSB as backing bean. I annotated all the relations among entities as fetch=lazy. So all the requests that are generated during page rendering are single select without joins. Tree-related requests are generated only when expanding a node. Thus I don't think that Hibernate or DB is the cause.

                        Norman, I'm afraid I need to measure whole project. I realized that there is other potential causes of performance loss. For instance it seems that facelets always compiles inclusions and source components in debug mode. Please take my apologies for not being well-prepared when raising this question.

                        I understand that Seam and EJB3 requires some reasonable overhead. But from my point of view a hundred lines of stack traces doesn't seem reasonable. I understand that interceptors can be less time consumptive in comparison with the others sources of overhead. I believe this is a question of reasonable trade-off.

                        • 9. Re: Seam + EJB3 performance
                          Christian Bauer Master

                           

                          Being impressed by long SQL statements generated by Hibernate and understanding that most of them are not required I decided that I need to try an idea of SFSB as backing bean. I annotated all the relations among entities as fetch=lazy. So all the requests that are generated during page rendering are single select without joins. Tree-related requests are generated only when expanding a node. Thus I don't think that Hibernate or DB is the cause.


                          Of course it is the cause. Enable the SQL log and count the number of queries. You are just guessing here.


                          • 10. Re: Seam + EJB3 performance
                            Vladimir Kovalyuk Apprentice

                            Christian, I'm not guessing. Here is my persistence.xml:

                            <?xml version="1.0" encoding="UTF-8"?>
                            <persistence xmlns="...">
                             <persistence-unit name="codename">
                             <provider>org.hibernate.ejb.HibernatePersistence</provider>
                             <jta-data-source>java:/codenameDatasource</jta-data-source>
                             <properties>
                             <property name="hibernate.hbm2ddl.auto" value="update"/>
                             <property name="hibernate.show_sql" value="true"/>
                             <property name="jboss.entity.manager.factory.jndi.name" value="java:/codenameEntityManagerFactory"/>
                             </properties>
                             </persistence-unit>
                            </persistence>
                            

                            There is single SQL statement in the log that looks similar to "select fields from table where parent_id=? and (isTemplate=0)". Nothing special. Is it enough to figure out what SQL is generated?

                            As I wrote I'm going to analyze Facelets overhead. I'm intensively using source components. I think problem is in debug mode. In production mode it caches all the xhtmls.
                            I like Seam. I found "Step Filters" in Eclipse. I hope it will help me to cope with debugging inter-EJB calls.


                            • 11. Re: Seam + EJB3 performance
                              Christian Bauer Master

                              You can NOT have a single SQL select to load a tree that is deeper than two levels and has more than 2 nodes (unless you use a proprietary SQL explode() operator).

                              Please post again when you have used a profiler and once you have some numbers.

                              • 12. Re: Seam + EJB3 performance
                                fhh Expert

                                Just to add some information from the db perspective:


                                Being impressed by long SQL statements generated by Hibernate and understanding that most of them are not required I decided that I need to try an idea of SFSB as backing bean. I annotated all the relations among entities as fetch=lazy. So all the requests that are generated during page rendering are single select without joins. Tree-related requests are generated only when expanding a node. Thus I don't think that Hibernate or DB is the cause.


                                This IS a database problem. A join can be an expensive database operation but that is what RDBMs are made for. A per-row subselect is even worse but if you do a single select for _every_ row you eventually want to fetch you will kill any database.

                                Why? First of all you have to parse the statements. This is very expensive if your database or JPA provider does not support PreparedStatements (Does Hibernate?).

                                Secondly the database will analyze the query to find out which is the most efficient way to fetch the data. If you send 500 single queries instead of one "big" query it will do that 500 times - and will get the wrong result anyway.

                                If you have a table with 50000 rows with an indexed pk that is fetched lazily in the way you describe then the database will look at the index and read the block which contains the the row indentified by the index for every single query. Each of this operation is fast but this will happen 50000 times. Since the blocks contains more than one row, blocks will have to be read again and again.

                                If you do this in one big select, it will just read all the blocks and send it to you. No index is needed and each block is only read once. This is way faster.

                                So the idea behind lazy loading Lazy loading is not to avoid joins but rather to avoid fetching unneccessary data. Imagine you have an entity relationship between an Entity called "country" which has a collection "citizens". Now your database has all 180 countries and 6,500,000,000 persons.

                                Now you want to list all countries. If "citizens" was fetched eagerly you would retrieve 6,500,000,000 rows from the database to display information about the 180 countries. This would be ridicolous. If you fetch lazily, you will only get 180 rows at the beginning. The records in the table holding the citizens are only retrieved if they are actually needed.

                                I hope this explains the concept behind lazy loading.

                                Regards

                                Felix




                                • 13. Re: Seam + EJB3 performance
                                  Vladimir Kovalyuk Apprentice

                                  If DB issues are considered to be so serious why not to make one more seam with db4o? http://www.db4o.com

                                  Christian, I feel a little bit confused. The log contains single SQL statement that is not related to the tree, due to the fact that tree model is kept in SFSB (visible nodes only).

                                  Aaaah! Something happened with me on yesterday evening. Rendering takes a second, not a minute. Sorry Norman, about a second.

                                  • 14. Re: Seam + EJB3 performance
                                    Christian Bauer Master

                                    DB4O is a network database, by design such a database management system offers no data independence (and I see no reason why it should offer better performance or scalability, except in benchmarks of the vendor).

                                    Seam is for enterprise application development with shared relational databases.

                                    Can we end this thread now?

                                    1 2 Previous Next