Réf. : [Hsqldb-user] HSQLDB In-Process mode Vs Server mode, for update operations

Could you please specify the JVM options that you passed to the command
line (-Xmx -Xms -server ...?) and
the version of the JVM used?

I'm also performing stress tests on HSQLDB 1.7.2 alpha for large amount of
records (1,000,000 records for tables with about 50 columns).

TIA,
Loïc




Internet
ambarish.nagarajan@xxxxxxxxx@lists.sourceforge.net - 12/12/2003 06:41


Veuillez répondre à hsqldb-user@xxxxxxxxxxxxxxxxxxxxx

Envoyé par :      hsqldb-user-admin@xxxxxxxxxxxxxxxxxxxxx

Pour : hsqldb-user

cc :


Objet :     [Hsqldb-user] HSQLDB In-Process mode Vs Server mode, for update
       operations




   Hi,
           We want to use HSQLDB to store around 5 million records. We
   conducted a few tests on HSQL DB mainly related to performance on HSQL
   version 1.7.1. The tests were run on a Intel(R) Pentium(R) 4 CPU 1.50GHz
   machine with Linux OS installed.

   The application, that we wish employ HSQL with, will potentially be
   loading the database with numerous update requests. As a consequence,
   main intention on conducting the test, was to see whether running HSQL
   in Standalone(in-process) mode offered any significant performance
   improvements versus running it in the Server mode, for intensive data
   update operations (updates of around 100 K records on a table having 500
   K to 5000 K records).


      We used org.hsqldb.test.TestCacheSize.java for the purpose of
   carrying out the tests for updates. We enhanced thsi code to measure
   performance for updates,deletes and selects.

      The TEST table was created as a CACHED table, as per the schema
   definition in org.hsqldb.test.TestCacheSize.java & indexes for the
   columns LASTNAME & ZIP were created prior to running the tests.The
   following were the HSQL DB settings that were altered from their
   defaults,

           hsqldb.cache_scale=16
           hsqldb.log_size=600

      Shown below are the results (time unit in milliseconds) that we
   obtained on performing the trials,

               Operation
               HSQL Server Mode                HSQL In-Process Mode

               (localhost)
               
--------------------------------------------------------------------------------------------------------------------------------------------------------------

               Insert Time  (500000 records):                  249284 ms
               94725 ms

               Update Time(100000 records):                     19290 ms
                17069 ms

               Select Time(100000 records):                     13666 ms
                                  5510 ms

                        Delete Time(100000 records):
   9851 ms                                  8795 ms

       As evident from the above readings, the performance of updates
   dosen't appear to be significantly better on running HSQL in the
   In-process mode.

       We also tried another approach. The intention was to see whether
   having the data inserted in 5 separate tables instead on just one would
   have any benificial effect on the performance of update operations.

       Shown below are the results (time unit in milliseconds) that we
   obtained on having data distributed among 5 tables, each having the same
   schema as TEST table,


                   Operation
   HSQL In-process Mode

   
--------------------------------------------------------------------------------------------------------------------------------------------

                   Insert Time(100000 records per table):
   143605 ms

                   Update Time(100000 records of table #5):
    33845 ms

                   Select Time(100000 records of table #5):
   7460 ms

                   Delete Time(100000 records of table #5):
   20976 ms

      We were surprised to see that the performance in the above case was
   much worse compared to having a single table.

      We would be delighted if we could have clarifications on the
   following issues in light of the above results,

           1)  Is there any optimization/parameters taht can be tuned that
   could make the performance of update operations using HSQL In-process
   mode/ HSQL Server mode better?

           2) Why only selects are showing significant performance
   improvement in the case of In-Process mode and not other queries?

           3) Why is the performance of update operations significantly
   less, on having the data distributed between 5 tables (last trial)
   rather than having all records in the same table ?

     Thanks for your help,

     Ambarish







This message and any attachments (the "message") is intended solely for the 
addressees and is confidential. 
If you receive this message in error, please delete it and immediately notify 
the sender. Any use not in accord with 
its purpose, any dissemination or disclosure, either whole or partial, is 
prohibited except formal approval. 
The internet can not guarantee the integrity of this message. BNP PARIBAS (and 
its subsidiaries) shall (will) not 
therefore be liable for the message if modified. 

                ---------------------------------------------

Ce message et toutes les pieces jointes (ci-apres le "message") sont etablis a 
l'intention exclusive de ses 
destinataires et sont confidentiels. Si vous recevez ce message par erreur, 
merci de le detruire et d'en avertir 
immediatement l'expediteur. Toute utilisation de ce message non conforme a sa 
destination, toute diffusion 
ou toute publication, totale ou partielle, est interdite, sauf autorisation 
expresse. L'internet ne permettant pas 
d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) 
toute responsabilite au titre de ce 
message, dans l'hypothese ou il aurait ete modifie.



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click