Re: [basex-talk] REST API performance, massive disk IO

2016-09-06 Thread Jens Erat
Hi Benedikt, sorry for not answering for a week. > our storage driver is the default aufs: > > Storage Driver: aufs > Root Dir: /var/lib/docker/aufs > Backing Filesystem: extfs > Dirs: 189 > Dirperm1 Supported: false > > ... based on ext4, also with default option (journaling only on

Re: [basex-talk] REST API performance, massive disk IO

2016-08-29 Thread Benedikt Wegmann
Hi Jens, our storage driver is the default aufs: Storage Driver: aufs Root Dir: /var/lib/docker/aufs Backing Filesystem: extfs Dirs: 189 Dirperm1 Supported: false ... based on ext4, also with default option (journaling only on metadata). However, we have a persistent volume for the

Re: [basex-talk] REST API performance, massive disk IO

2016-08-26 Thread Jens Erat
Hi Björn, which Docker storage driver are you using? In my own experiments, I recently realized BaseX does not play very well with copy-on-write, resulting in heavy fragmentation. If you're using BTRFS or ZFS, you should definitely make sure to disable copy on write for the BaseX database

Re: [basex-talk] REST API performance, massive disk IO

2016-08-24 Thread Braunschweig , Björn
alk@mailman.uni-konstanz.de Betreff: Re: [basex-talk] REST API performance, massive disk IO Hello Björn, I guess you use up to 64 parallel clients for performance reasons, i.e. to increase throughput? However, if you write indeed to a single database and all of these queries are updating you are in

[basex-talk] REST API performance, massive disk IO

2016-08-24 Thread Braunschweig , Björn
Hello everybody, I‘m using the basexhttp docker image: root@koala:/tmp# docker images | grep basexhttp basex/basexhttp8.4.1 54d1e00014493 months ago628.1 MB On ubuntu 14.04 [1] and the python client library: