Sonarqube web UI profiles management is slow with Oracle

Question

Installing SonarQube with Oracle on a virtualized environment (production), the profiles management is very slow compared to other installation with same distribution.

I will be grateful of some feedbacks about response time of this functionality when many profiles used on this architecture (Virtualized Linux + Oracle).

Tests below and a quick analysis to give some informations / case reproduction.

---

Distribution :

• SonarQube 3.7.3 with 39 plugins (jar files in extensions/plugins/)
• 9 languages profiles : C#/C++/Flex/Java/JavaScript/PHP/Python/Web/XML (Problem increases with number of profiles)
• clean installation (no projects analysed, profiles by default)

Scenario :

• Calling profiles page (as nemo profiles page), second call reported after cache filled, only 1 user on platform
• Log 'rails' in INFO in logback.xml

VM virtualized :

• Linux SLES 11 (patch 2) x86 64b
• DELL R815 / 16 core AMD (guaranteed for SonarQube VM : 1 core & 8 Go)

Tests on VM environment :

• 8093ms (View: 7219, DB: 864) : server on VM / Oracle on VM
• 2206ms (View: 1851, DB: 346) : server & H2 Embedded on same VM

=> Response time acceptable with H2 (CPU frequency not very high on VM), so no CPU/IO/RAM saturation. But some suspicions with Oracle about View part.

Personal tests :

• 2054ms (View: 542, DB: 1506) : server on Laptop Dell Vostro 3300 / MySql on NAS Qnap TS-219
• 808ms (View: 528, DB: 273) : server & HsqlDB on Laptop Dell Vostro 3300

=> Distant Database has no impact on View part (with MySQL in this case)

For fun & info, SonarQube works (starting and profiles consultation) on Qnap TS-219 (CPU armv5tel !!) with Java Service Wrapper Linux CPU armel v3.5.22

• 13762ms (View: 10877, DB: 2832) : server & H2 Embedded on NAS Qnap TS-219
• 13622ms (View: 10581, DB: 2997) : server & MySQL on NAS Qnap TS-219

=> Qnap TS-219 is not enough for SonarQube (CPU saturation ;-)).

---

With connecting JVisual in JMX remote for taking some thread dump, 75% have this stack (other are equivalent until RuntimeCache.getConstantFrom) :

 java.lang.Thread.State: RUNNABLE
    at java.lang.Throwable.getStackTraceElement(Native Method)
    at java.lang.Throwable.getOurStackTrace(Throwable.java:591)
    - locked <5512520e> (a java.lang.Exception)
    at java.lang.Throwable.getStackTrace(Throwable.java:582)
    at java.lang.Thread.getStackTrace(Thread.java:1479)
    [...]
    at org.jruby.RubyException.prepareBacktrace(RubyException.java:160)
    [...]
    at org.jruby.exceptions.RaiseException.<init>(RaiseException.java:141)
    [...]
    at org.jruby.Ruby.newNameError(Ruby.java:3243)
    at org.jruby.RubyModule.const_missing(RubyModule.java:2647)
    at org.jruby.RubyModule$i$1$0$const_missing.call(RubyModule$i$1$0$const_missing.gen:65535)
    [...]
    at rubyjit.ActiveSupport::Dependencies::ClassConstMissing#const_missing_1F94EEFD25B9D6ED4A2256A01713AC5D8AAE19F9.__file__(/[sonar-dir]/sonar-3.7.3/war/sonar-server/WEB-INF/gems/gems/activesupport-2.3.15/lib/active_support/dependencies.rb:118)
    at rubyjit.ActiveSupport::Dependencies::ClassConstMissing#const_missing_1F94EEFD25B9D6ED4A2256A01713AC5D8AAE19F9.__file__(/[sonar-dir]/sonar-3.7.3/war/sonar-server/WEB-INF/gems/gems/activesupport-2.3.15/lib/active_support/dependencies.rb)
    [...]
    at org.jruby.RubyModule.fastGetConstantFromConstMissing(RubyModule.java:2974)
    at org.jruby.ast.executable.RuntimeCache.getConstantFrom(RuntimeCache.java:418)
    at org.jruby.ast.executable.AbstractScript.getConstantFrom0(AbstractScript.java:292)
    at rubyjit.ArJdbc::Oracle#sql_literal?_35B81FE146BCEA62ED756B5BE2D767870ADF57AC.rescue_1$RUBY$SYNTHETIC__file__(/[sonar-dir]/sonar-3.7.3/war/sonar-server/WEB-INF/gems/gems/activerecord-jdbc-adapter-1.1.3/lib/arjdbc/oracle/adapter.rb)
    at rubyjit.ArJdbc::Oracle#sql_literal?_35B81FE146BCEA62ED756B5BE2D767870ADF57AC.__file__(/[sonar-dir]/sonar-3.7.3/war/sonar-server/WEB-INF/gems/gems/activerecord-jdbc-adapter-1.1.3/lib/arjdbc/oracle/adapter.rb:162)
    at rubyjit.ArJdbc::Oracle#sql_literal?_35B81FE146BCEA62ED756B5BE2D767870ADF57AC.__file__(/[sonar-dir]/sonar-3.7.3/war/sonar-server/WEB-INF/gems/gems/activerecord-jdbc-adapter-1.1.3/lib/arjdbc/oracle/adapter.rb)
    [.......]
    at org.jruby.evaluator.ASTInterpreter.INTERPRET_METHOD(ASTInterpreter.java:74)
    [...]
    at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
    at java.lang.Thread.run(Thread.java:662)

---

Hypothesis :

• Many time to generate java exception (CPU cost not negligible) ? (or programming by exception is a desired process)
• Especially with Oracle connector ? (Or the Oracle dialect used to generate request could explain these responses time when many profiles)

Perhaps I see problems where there are not ... but this response time with Oracle on this page (and more generally on profiles management) could be a little strange.

Thanks in advance for feedbacks or ideas.

Answer 1

The discussion has switched to the SonarQube user mailing list : http://sonar.markmail.org/thread/gbmj5dwyrrysujfo