castor
  1. castor
  2. CASTOR-732

Performance test-suite for JDO

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.9.5.3
    • Fix Version/s: 0.9.9 M1
    • Component/s: JDO
    • Labels:
      None
    • Environment:
      Operating System: All
      Platform: PC
    • Bugzilla Id:
      1590
    • Number of attachments :
      3

      Description

      I'm proposing that we create a performance test-suite.

        Activity

        Hide
        Stein M. Hugubakken added a comment -

        Created an attachment (id=439)
        Unfinished test-suite

        Show
        Stein M. Hugubakken added a comment - Created an attachment (id=439) Unfinished test-suite
        Hide
        Stein M. Hugubakken added a comment -

        Sorry, I should have attached the file as application/zip, not
        application/octet-stream.

        The goal of the test-suite is to construct a directory/file-structure for some
        target-directory and then it's timing marshalling/unmarshalling of this
        structure for both xml and datatabase.

        Attached is what I got so far, but I have problem with ToDatabasePerf and mapping.

        It works for marshalling/unmarshalling xml, but I have problem with writing the
        root-node to database, exception thrown is:
        org.exolab.castor.mapping.MappingException: Field element,
        "org.castor.perf.AbstractItem" not found!

        The mappingfile-location is hardcoded in AbstractPerf.getMapping().

        First you must run XMLMarshallingPerf with a target-directory as argument for
        creating the the xml-file named out.xml.

        Then you can run XMLUnmarshallingPerf to unmarshal the out.xml and this works
        ok, but if you try ToDatabasePerf you'll get the exception.

        The problem is the AbstractItem-type, is it in relation with
        http://www.castor.org/jdo-project.html#Polymorphism ?

        Suggestions for how it can be solved?

        Show
        Stein M. Hugubakken added a comment - Sorry, I should have attached the file as application/zip, not application/octet-stream. The goal of the test-suite is to construct a directory/file-structure for some target-directory and then it's timing marshalling/unmarshalling of this structure for both xml and datatabase. Attached is what I got so far, but I have problem with ToDatabasePerf and mapping. It works for marshalling/unmarshalling xml, but I have problem with writing the root-node to database, exception thrown is: org.exolab.castor.mapping.MappingException: Field element, "org.castor.perf.AbstractItem" not found! The mappingfile-location is hardcoded in AbstractPerf.getMapping(). First you must run XMLMarshallingPerf with a target-directory as argument for creating the the xml-file named out.xml. Then you can run XMLUnmarshallingPerf to unmarshal the out.xml and this works ok, but if you try ToDatabasePerf you'll get the exception. The problem is the AbstractItem-type, is it in relation with http://www.castor.org/jdo-project.html#Polymorphism ? Suggestions for how it can be solved?
        Hide
        Werner Guttmann added a comment -

        Stein, yes you are suffering from 'polymorphism' .. . Just looking at your
        mapping file, here's what seems to be the problem:

        <field name="children" type="org.castor.perf.AbstractItem"
        collection="collection" get-method="getChildren" set-method="addChild">
        <sql many-key="parent_id"/>
        <bind-xml auto-naming="deriveByClass" node="element" />
        </field>

        DatingService.close() does not have a filedMolder to ClassMolder-mapping for
        AbstractItem when trying to resolve above relation. It only has such mappings
        for classes enlisted in mapping.xml through their corresponding <class>
        definitions. Can't you enlist AbstractItem as well, and then use the extends
        relationship for the remainder ?

        Show
        Werner Guttmann added a comment - Stein, yes you are suffering from 'polymorphism' .. . Just looking at your mapping file, here's what seems to be the problem: <field name="children" type="org.castor.perf.AbstractItem" collection="collection" get-method="getChildren" set-method="addChild"> <sql many-key="parent_id"/> <bind-xml auto-naming="deriveByClass" node="element" /> </field> DatingService.close() does not have a filedMolder to ClassMolder-mapping for AbstractItem when trying to resolve above relation. It only has such mappings for classes enlisted in mapping.xml through their corresponding <class> definitions. Can't you enlist AbstractItem as well, and then use the extends relationship for the remainder ?
        Hide
        Ralf Joachim added a comment -

        As requirements for performance tests are quite a bit different between XML and
        JDO I want to seperate developement of both parts. Therefor I want to change
        this to be the XML one and create a new JDO one.

        Any comments?

        Show
        Ralf Joachim added a comment - As requirements for performance tests are quite a bit different between XML and JDO I want to seperate developement of both parts. Therefor I want to change this to be the XML one and create a new JDO one. Any comments?
        Hide
        Stein M. Hugubakken added a comment -

        Fine by me.

        Show
        Stein M. Hugubakken added a comment - Fine by me.
        Hide
        Werner Guttmann added a comment -

        Ralf, Stein's work actually is a test suite for JDO, afair. Having said that,
        Stein, can you please have a look at the latest patches I have attached to bug
        1881, as they add (partial) support for polymorphism (Database.load() only), and
        see whether they enable you to proceeed ?

        Show
        Werner Guttmann added a comment - Ralf, Stein's work actually is a test suite for JDO, afair. Having said that, Stein, can you please have a look at the latest patches I have attached to bug 1881, as they add (partial) support for polymorphism (Database.load() only), and see whether they enable you to proceeed ?
        Hide
        Ralf Joachim added a comment -

        Werner, If you like this to be the JDO side, why not .

        I think we need to do a lot more than Stein did so far.

        • readonly / readwrite access
        • objects w/o relations and those with different types of relations
        • 1:1 / 1:n / n:m relations
        • unidirectional / bidirectional relations
        • differnent types of mapping polymorph objects (when supported)
        • all objects in cache or not in cache
        • queries / load / create / delete / updates (short and long transaction)
        • lazy and not lazy loading

        We can add tests step by step and calculate an overall performance index as well
        as indices according to special needs.

        I intend to contribute some focusing on readonly queries as I found some
        performance problems there.

        Gregory, can you add some to show up the improvements of the new cache
        implementation.

        Show
        Ralf Joachim added a comment - Werner, If you like this to be the JDO side, why not . I think we need to do a lot more than Stein did so far. readonly / readwrite access objects w/o relations and those with different types of relations 1:1 / 1:n / n:m relations unidirectional / bidirectional relations differnent types of mapping polymorph objects (when supported) all objects in cache or not in cache queries / load / create / delete / updates (short and long transaction) lazy and not lazy loading We can add tests step by step and calculate an overall performance index as well as indices according to special needs. I intend to contribute some focusing on readonly queries as I found some performance problems there. Gregory, can you add some to show up the improvements of the new cache implementation.
        Hide
        Werner Guttmann added a comment -

        > I think we need to do a lot more than Stein did so far.
        Yoz are definitely right that a lot of tests need to be added, bug please keep
        in mind that Stein could not proceed with his work due to missing support for
        polymorphism. Which either has been added already or still needs to be added
        (in case of OQL queries).

        Show
        Werner Guttmann added a comment - > I think we need to do a lot more than Stein did so far. Yoz are definitely right that a lot of tests need to be added, bug please keep in mind that Stein could not proceed with his work due to missing support for polymorphism. Which either has been added already or still needs to be added (in case of OQL queries).
        Hide
        Werner Guttmann added a comment -

        Stein, could you please provide an updated (unified if possible) patch ?

        Show
        Werner Guttmann added a comment - Stein, could you please provide an updated (unified if possible) patch ?
        Hide
        Werner Guttmann added a comment -

        Stein, I am just trying to integrate the patch provided by you with the
        polymorphism preview as offered last week. Here's a couple of small questions:

        a) Why do you need both parent and parent_id properties in AbstractPerf ?
        b) Is this a result of you trying to work-around missing support for polymorphism.
        c) If that's not the case, what's the genuine meaning behind these instance
        members ?
        d) If it is, how should and could out.xml be modified to be in-line with support
        for polymorphism.

        Show
        Werner Guttmann added a comment - Stein, I am just trying to integrate the patch provided by you with the polymorphism preview as offered last week. Here's a couple of small questions: a) Why do you need both parent and parent_id properties in AbstractPerf ? b) Is this a result of you trying to work-around missing support for polymorphism. c) If that's not the case, what's the genuine meaning behind these instance members ? d) If it is, how should and could out.xml be modified to be in-line with support for polymorphism.
        Hide
        Werner Guttmann added a comment -

        Oops, forgot to mention that I modified all occurences to "parent_id" in the
        mapping file with a filed mapping as folows:

        <field name="parent" type="org.castor.perf.AbstractItem">
        <sql name="parent_id" />
        </field>

        Show
        Werner Guttmann added a comment - Oops, forgot to mention that I modified all occurences to "parent_id" in the mapping file with a filed mapping as folows: <field name="parent" type="org.castor.perf.AbstractItem"> <sql name="parent_id" /> </field>
        Hide
        Stein M. Hugubakken added a comment -

        I'll see what I can do about the performance tests.

        I'm not sure we should use the "current" patch, but rather start from scratch.

        Is it an idea to base a performance test-suite on JUnit since they too should be
        independent of one another?

        Show
        Stein M. Hugubakken added a comment - I'll see what I can do about the performance tests. I'm not sure we should use the "current" patch, but rather start from scratch. Is it an idea to base a performance test-suite on JUnit since they too should be independent of one another?
        Hide
        Werner Guttmann added a comment -

        Whatever you prefer ... . Re: JUnit, why not ?

        Show
        Werner Guttmann added a comment - Whatever you prefer ... . Re: JUnit, why not ?
        Hide
        Stein M. Hugubakken added a comment -

        What about using an existing framework?
        http://opensourcetesting.org/performance.php

        Show
        Stein M. Hugubakken added a comment - What about using an existing framework? http://opensourcetesting.org/performance.php
        Hide
        Ralf Joachim added a comment -

        Test 1:n relations

        Show
        Ralf Joachim added a comment - Test 1:n relations
        Hide
        Ralf Joachim added a comment -

        Finished measurements and added TestAll suite

        Show
        Ralf Joachim added a comment - Finished measurements and added TestAll suite
        Hide
        Ralf Joachim added a comment -

        Stein, if you like to continue your original aproache I suggest to open a new issue for this work.

        Show
        Ralf Joachim added a comment - Stein, if you like to continue your original aproache I suggest to open a new issue for this work.

          People

          • Assignee:
            Ralf Joachim
            Reporter:
            Stein M. Hugubakken
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: