Setup

  1. Version of Fedora
    1. 4.5.1-SNAPSHOT | Build #fd6f9da9 (2016-02-19) (https://github.com/fcrepo4/fcrepo4/pull/986 before squashing)
  2. Fedora Configuration
    1. JAVA_OPTS="-Dfcrepo.home=/var/lib/tomcat7/fcrepo4-data -Djava.awt.headless=true -Xmx8g"

    2. See below

  3. System details
    1. Fedora: VMWare VM configured with 4x 2.8GHz CPU, 16GB RAM
    2. JMeter: separate identical VM
    3. Network: 1000Mb/s ethernet

    4. OS: Ubuntu 14.04.3 LTS

    5. JVM: Oracle JDK 1.8.0_66-b17

    6. Servlet container: Tomcat 7.0.52

    7. 100GB disk, about 70GB free at beginning of test
  4. Initial State of the Repository
    1. empty
  5. Number of Client Threads
    1. 1

Test

$HOME/jmeter/bin/jmeter -Dfedora_4_server=lib-fedora1.princeton.edu -Dfedora_4_context=fcrepo/rest -Dfilesize_min=0 -Dfilesize_max=4096 -Dbinary_threads=1 -n -t $HOME/jmeter/fedora.jmx

Results

LevelDB

  1. Summary: 523,751 in 14,350s = 36.5/s, Avg: 22, Min: 8, Max: 3,738, Err: 1 (0.00%)
  2. Status: Test ended when LevelDB encountered a "Too many open files" error
  3. Logs:
    1. jmeter log: test2-leveldb.log
    2. jmeter data: test2-leveldb.csv.gz
    3. jmeter perf: test2-leveldb-perf.log

PostgreSQL

  1. Additional config: 
    1. JAVA_OPTS="${JAVA_OPTS} -Dfcrepo.modeshape.configuration=classpath:/config/jdbc-postgresql/repository.json"
    2. PostgreSQL 9.3 running on same VM as Fedora
  2. Summary: 3,959,096 in 293,495s = 13.5/s, Avg: 69, Min: 8, Max: 24243, Err: 1 (0.00%)
  3. Status: Test ended when Tomcat encountered "java.lang.OutOfMemoryError: GC overhead limit exceeded" error
    1. Restarting Tomcat restored the repository to a usable state
  4. Logs:
    1. jmeter log: test2-postgres.log
    2. jmeter data: test2-postgres.csv.gz
    3. jmeter perf: test2-postgres-perf.log
    4. fedora log: test2-postgres-fedora.log

PostgreSQL with UseG1GC

  1. Additional config: 
    1. JAVA_OPTS="${JAVA_OPTS} -Dfcrepo.modeshape.configuration=classpath:/config/jdbc-postgresql/repository.json -XX:+UseG1GC -XX:+DisableExplicitGC"
    2. PostgreSQL 9.3 running on same VM as Fedora
  2. Summary: 4,153,187 in 356,680s = 11.6/s, Avg: 81, Min: 8, Max: 66,544, Err: 1 (0.00%)
  3. Status: Test ended when the performance CRUD operations timed out
    1. Tomcat error log contains a WARN message at the same time: "WARN 12:55:39.576 (arjuna) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffff7f000101:aec8:573f1629:fc7cda in state  RUN"
  4. Logs:
    1. jmeter log: test2-postgres-gc1.log
    2. jmeter data: test2-postgres-gc1.csv.gz
    3. fedora log: test2-postgres-gc1-fedora.log

PostgreSQL with Modeshape5 branch

  1. Version of Fedora:
    1. modeshape5 branch as of 6/5/16, commit 7477d568
  2. Additional config:
    1. JAVA_OPTS="${JAVA_OPTS} -Dfcrepo.modeshape.configuration=classpath:/config/jdbc-postgresql/repository.json -XX:+UseG1GC -XX:+DisableExplicitGC"
    2. PostgreSQL 9.5 running on same VM as Fedora
      1. Note: PostgreSQL upgraded from 9.3 to 9.5 to fix an error only seen with the modeshape5 branch
  3. Summary: 7,779,352 in 280,285s = 27.8/s, Avg: 31, Min: 1, Max: 3,414, Err: 1 (0.00%)
  4. Status: Test ended when disk was filled up with PostgreSQL database files.
  5. Logs:
    1. jmeter log: test2-postgres-mode5.log
    2. jmeter data: test2-postgres-mode5.csv.gz
    3. jmeter perf: test2-postgres-mode5-perf.log

 

5 Comments

  1. Esmé Cowles, Can you share your JAVA_OPTS used for the PostgreSQL test?

  2. The full JAVA_OPTS are:

    -Dfcrepo.home=/var/lib/tomcat7/fcrepo4-data -Djava.awt.headless=true -Xmx8g
    -Dfcrepo.modeshape.configuration=classpath:/config/jdbc-postgresql/repository.json
    -Dfcrepo.ispn.postgresql.username=******** -Dfcrepo.ispn.postgresql.password=********

    1. These have been gaining favor:

      -XX:+UseG1GC -XX:+DisableExplicitGC

      See: Java HotSpot VM Options recommendations

      1. I was just updating my config with UseG1GC, so I've added both of those options and I'll retry Postgres first, then LevelDB to see what difference they make.

        1. It is also worth noting that Aaron Birkland's PR just went into master that should show significant memory benefits:

          Unable to locate Jira server for this macro. It may be due to Application Link configuration.