Performance test on Jetty/HSQLDB with a single wiki between 7.4.5 and 8.4.4
Environment
- Ubuntu 16.10 64b
- Quad core i7-6700HQ
- Oracle JDK 1.8.0_111 64b
- Dumbbench 0.10
- standard jetty+hsqldb
- permdir in a SSD
- only main wiki
- configuration
- Admin user:
- hidden documents enabled
- Admin user:
- import
Most of response time statistics are made with Dumbbench, you can install it using cpan.
For example on Debian/Ubuntu:
$ sudo cpanm Dumbbench
Unless specifically indicated otherwise all the tests are executed with a fully initialized instance (core extensions don't run anymore, SOLR index is fully up to date, etc.) and logged in with Admin user. Basically except for a few special tests we are using an instance that already been started and run until the proc is flat for some time.
Login with Admin user:
Tests
Summary
Jetty startup takes longer mostly because of:
- Let's Encrypt certificate registration (which recreate the certificate store). This module is not embedded anymore in 9.0.
- Full loading of core extensions. Small price to pay to have a much more reliable core extension index (in most cases there is no guessed or missing core extension anymore). The size of the wiki has no impact on time spent (the number of core extensions does not change).
The skin is a lot slower than in 7.4.5.
A lot of work has been done to improve Solr UI display (a bit less obvious with the slowness of the skin).
The memory has been reduced a lot compared to 8.3 thanks to optimization in the way to create Extension instances to reduce a lot the duplications (only one instances kept for identical instances of Version, ExtensionDependency, etc.). The difference is even more important in very big wikis like http://myxwiki.org which contains a huge number of installed extensions cached in memory.
"similar": difference is lower than 10%
"slightly": difference is lower than 20%
Speed
Memory
Actions | Difference |
---|---|
Heap Memory after jetty startup | similar |
Heap Memory after full SOLR index | similar |
Jetty startup
Unit: seconds
You get this from the log with the line looking like 2016-10-19 16:52:25.309:INFO:oejs.Server:main: Started @8434ms.
- 7.4.5: 8
- 8.4.4: 10
First access
First HTTP request after restarting Jetty.
First access to not existing page without UI
(/xwiki/bin/get/NoSpace/NoPage)
Unit: seconds
Firefox network statistics to load the root resource (image/js/css/etc. resources are not taken into account).
- 7.4.5: 5
- 8.4.4: 5
First access to not existing page with UI
(/xwiki/bin/view/NoSpace/NoPage)
Unit: seconds
Done by hand with a chronometer (image/js/css/etc. resources are not taken into account).
- 7.4.5: 11
- 8.4.4: 15
Reload
XWiki is doing nothing on background and everything is both in server and client cache already. Values are calculated using dumbbench (image/js/css/etc. resources are not taken into account).
Reload of not existing page without UI
Unit: milliseconds
- 7.4.5: 6.5
- 8.4.4: 6.2
Reload of not existing page with UI
Unit: milliseconds
- 7.4.5: 60
- 8.4.4: 81
Reload of empty page without UI
Unit: milliseconds
- 7.4.5: 6.5
- 8.4.4: 6.4
Reload of empty page with UI
Unit: milliseconds
- 7.4.5: 65
- 8.4.4: 79
Reload of Main.WebHome without UI
Unit: milliseconds
- 7.4.5: 44
- 8.4.4: 8
Reload of Main.WebHome with UI
Unit: milliseconds
- 7.4.5: 107
- 8.4.4: 85
SOLR
Full SOLR reindex
Unit: seconds
Delete the data/solr folder, restart, load home page and calculate the time of activity of the SOLR index thread using Yourkit (Yourkit is slowing down a bit all that but what is important is the difference anyway).
- 7.4.5: 50
- 8.4.4: 55
SOLR sync
Only the thread determining what need to be indexed and not the actual indexing.
when index is empty
Unit: seconds
- 7.4.5: < 1
- 8.4.4: < 1
when there is nothing to do
Unit: seconds
- 7.4.5: < 1
- 8.4.4: < 1
Search
XWiki is doing nothing on background and everything is both in server and client cache already. Values are calculated using dumbbench (image/js/css/etc. resources are not taken into account).
Unit: milliseconds
Result of search finding lots of results
Login with Admin user and make sure hidden document display is enabled.
- 7.4.5: 198
- 8.4.4: 153
Result of search finding one result
- 7.4.5: 165
- 8.4.4: 113
Rendering
Page with 1000 macros without UI
Unit: milliseconds
- 7.4.5: 75
- 8.4.4: 64
Page with 1000 html macros without UI
Unit: milliseconds
- 7.4.5: 774
- 8.4.4: 645
Heap Memory
Attach Yourkit to get the information.
Unit: MB
Heap Memory after jetty startup
Start jetty and wait until java is not doing anything on both (wait for potential initialization of various stuff like core extension cache, etc). Force garbage collector before looking at the values.
- 7.4.5: 41 used, 480 allocated
- 8.4.4: 46 used, 556 allocated
Heap Memory after full SOLR index
Delete the data/solr folder, restart, load home page then wait until nothing is happening in background. Force garbage collector before looking at the values.
Unit: MB
- 7.4.5: 160 used, 505 allocated
- 8.4.4: 159 used, 807 allocated