OK, but now I'm somewhat confused. You weren't able to reproduce 25%
performance, so thats good, but isn't 50% also a cause for concern? Why
would Sedna take twice as long to process an insert when being hit with two
threads? Even if, as you say, transactions are almost serial, there should
be a hardly noticeable slowdown as Sedna would just ignore one request as it
handles another, no?
Maybe I'm looking at this too simplistically: if Senda can do 100
inserts/second with one thread, shouldn't it be able to do almost 100
inserts/second when two threads are doing inserts at the same time? If not,
does that mean there is a linear slowdown as the thread increase? 10 threads
are going to slow to 1/10 of the speed of normal? 20 threads to 1/20th?
Thanks,
Mark
On Fri, Feb 13, 2009 at 7:18 AM, Ivan Shcheklein <[email protected]>wrote:
> Mark,
>
>
>
>> 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...
>
>
> Yep. 50% performance was expected as we bulk load into one collection.
> Actually, in such a case transactions are executed almost serially, since
> collection is permanently locked.
>
> The question was: "why do we have 20-25% performance?". Unfortunately (or
> fortunately :)), I failed to reproduce this. If problem still exists, it's
> likely either in driver or in network/hardware. That's why I suggested
> firstly to try to run clients using se_term.
>
>
> Ivan Shcheklein,
> Sedna Team
>
> Sure.
>
>>
>> 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
