Ivan, would you mind commenting a bit further on the results please? I just
woke up and still need a cup of tea, but It looks like it consistently takes
twice as long to do an insert under load...
Thanks,
Mark
On Fri, Feb 13, 2009 at 4:10 AM, Ivan Shcheklein <[email protected]>wrote:
> Hi guys,
>
> Access to the database takes place via a Java web application running in
>> Tomcat 6.0. We cache sessions internally for re-use, but act with a single
>> user on the database. In the test scenario, we used two client
>> apps and two web apps on different machines, and one Sedna database on a
>> third machine. Thus, the shared resources were the network, the Sedna
>> server and the database. As soon as we started the second client app,
>> performance dropped down from 200ms to 1000ms for inserting an indexed XML
>> doc (we had already stored around 550.000 pairs of XML doc + image
>> at that time).
>>
>
> I've reproduced the issue. That is what I've got:
>
> ===========================================
> 1. No index, random id, one client
> ...
> 499990 : 0.0139999389648
> 499991 : 0.0149998664856
> 499992 : 0.0140001773834
> 499993 : 0.0149998664856
> 499994 : 0.0130000114441
> 499995 : 0.0139999389648
> 499996 : 0.0139999389648
> 499997 : 0.0130000114441
> 499998 : 0.0139999389648
> 499999 : 0.0140001773834
>
> 2. No index, random id, two clients (already 500.000 loaded)
> ...
> 509990 : 0.0240001678467
> 509991 : 0.0250000953674
> 509992 : 0.0239999294281
> 509993 : 0.0240001678467
> 509994 : 0.0260000228882
> 509995 : 0.0240001678467
> 509996 : 0.0239999294281
> 509997 : 0.0250000953674
> 509998 : 0.0239999294281
> 509999 : 0.0239999294281
>
> 3. Index by id, one client (already 520.000 loaded)
> ...
> 539990 : 0.0139999389648
> 539991 : 0.0139999389648
> 539992 : 0.0139999389648
> 539993 : 0.0150001049042
> 539994 : 0.0139999389648
> 539995 : 0.0139999389648
> 539996 : 0.0130000114441
> 539997 : 0.0139999389648
> 539998 : 0.0139999389648
> 539999 : 0.0140001773834
>
> 4. Index by id, two clients (already 540.000 loaded)
> ...
> 549990 : 0.0239999294281
> 549991 : 0.0250000953674
> 549992 : 0.0239999294281
> 549993 : 0.0250000953674
> 549994 : 0.0249998569489
> 549995 : 0.0240001678467
> 549996 : 0.0299999713898
> 549997 : 0.0239999294281
> 549998 : 0.0240001678467
> 549999 : 0.0249998569489
>
> 5. All Indexes, one client (already 560.000 loaded)
> ...
> 569990 : 0.0510001182556
> 569991 : 0.0499999523163
> 569992 : 0.0499999523163
> 569993 : 0.0520000457764
> 569994 : 0.0510001182556
> 569995 : 0.0499999523163
> 569996 : 0.0500001907349
> 569997 : 0.050999879837
> 569998 : 0.0539999008179
> 569999 : 0.050999879837
>
> 6. All Indexes, two clients (already 570.000 loaded)
> ...
> 579990 : 0.0999999046326
> 579991 : 0.0980000495911
> 579992 : 0.0980000495911
> 579993 : 0.116000175476
> 579994 : 0.101000070572
> 579995 : 0.101999998093
> 579996 : 0.144999980927
> 579997 : 0.0980000495911
> 579998 : 0.0980000495911
> 579999 : 0.0969998836517
> ===========================================
>
> As you can see, we have at least 50% performance in cases 2,4,6.
>
> If you still have this problem, please, try to run queries via se_term.
>
> Ivan Shcheklein,
> Sedna Team
>
>
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Sedna-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sedna-discussion
