atom feed8 messages in net.sourceforge.lists.exist-openRe: [Exist-open] Stress testing eXist...
FromSent OnAttachments
Ubbo VeentjerMay 17, 2011 7:12 am.txt, .txt, .txt
Casey JordanMay 17, 2011 9:57 am 
Ubbo VeentjerMay 18, 2011 4:47 am.jmx
Wolfgang MeierMay 18, 2011 4:59 am 
Ubbo VeentjerMay 18, 2011 5:11 am 
Wolfgang MeierMay 18, 2011 9:03 am 
Ubbo VeentjerMay 18, 2011 12:24 pm 
Wolfgang MeierMay 19, 2011 2:09 am 
Subject:Re: [Exist-open] Stress testing eXist-1.4.1-rev14438
From:Ubbo Veentjer (veen@sub.uni-goettingen.de)
Date:May 18, 2011 5:11:52 am
List:net.sourceforge.lists.exist-open

Hi Wolfgang,

we tried both, with a prefilled DB and with an empty one. In both cases we hit
the same bugs, so it does reveal the same errors with an empty database.

Thanks, Ubbo

On 18.05.2011 13:59, Wolfgang Meier wrote:

Hi Ubbo,

can I just run the test on an empty database or were there any documents in it?

I will look into the issue, but I first have to fix the other indexing bug we are currently struggling with.

Am 18. Mai 2011 13:47 schrieb Ubbo Veentjer <veen@sub.uni-goettingen.de>:

Hello,

find the JMeter file attached. It was developed by Thomas Selig from the FH Worms and tries to imitate our typical usage of eXist in TextGrid. Whereas I hope that in real world files won't be put and deleted in that frequency ;-).

The included TEI file originates from the Carl-Maria-von-Weber-Gesamtausgabe ( http://www.weber-gesamtausgabe.de ), who gave their OK for publishing it with the test if the originator statements stay intact.

Cheers, Ubbo

Am 17.05.2011 18:57, schrieb Casey Jordan:

Ubbo,

I am glad someone is doing this. I would be interested in the JMeter file.

Cheers,

Casey

On Tue, May 17, 2011 at 10:12 AM, Ubbo Veentjer <veen@sub.uni-goettingen.de> wrote:

Hello,

yesterday we have been running some stress tests against eXist-1.4.1rev-14438. The tests were done using JMeter with 4 multicore clients running 10 threads each, doing put, get and delete requests. So 40 concurrent clients tried to access the database.

After a short time failures like the one attached as stacktrace1.txt begin to show up in exist.log. They happen irregularly but do not stop the database from working.

Some time later the eXist-database itself crashes with one of the attached stacktraces 2 and 3 showing up in wrapper.log. The time until crash and which of these two errors occurs is kind of random. But it's reproducibly possible to crash exist with high load, and always errors similar to these two are thrown.

I'm not sure if this error is related to index corruptions discussed on this list. If you like, I can send the JMeter file of this test (would first have to check if there is non-public data included and possibly clean up a bit). I tried to reproduce the issue running JMeter and eXist locally on my laptop, but this only revealed stacktrace1. The dualcore CPU seems to be too weak to produce enough concurrency.

Thanks, Ubbo

------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay

------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay

------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay