BenchMark

We perform tests on a cheap cloud host, 1-core 2.6GHz Intel Xeon CPU, 4.0 G memory and 100GB HDD, without SSD acceleration. We put Swap files on a separate directory for the use of Lunar memory management unit. Here is what the system configured:

CPU:

[rocku@iz25dXXXsuZ ~]$ cat /proc/cpuinfo  
vendor_id        :  GenuineIntel  
cpu family       :  6  
model            :  62  
model name       :  Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz  
stepping         :  4  
cpu MHz          :  2593.427  
cache size       :  20480 KB  
......    

Memory:

[rocku@iz25dXXXsuZ ~]$ grep MemTotal /proc/meminfo  
MemTotal:        : 3921020KB  

OS:

[rocku@iz25dXXXsuZ ~]$ uname -a  
Linux iz25dXXXsuZ 2.6.32-573.18.1.e16.x86_64

GCC:

[rocku@iz25dXXXsuZ ~]$ gcc -v  
gcc version 4.8.4 (GCC)

JAVA:

[rocku@iz25dXXXsuZ ~]$ java -version  
java version 1.8.0_60  
Java(TM) SE Runtime Enviroment (build 1.8.0_60-b27)  
Java HotSpot(TM) 64-bit Server VM (build 25.60-b23, mixed mode)  

On the database side, we have real-time mode and virtual memory enabled, full index mode disabled. The maximum physical memory use for each searchable column will be 256MB = 1<<28, and maximum 256k = 1 << 18 hot records will be kept in cache. Can be more if your budget allows:

#....................#
cache_records_in_memory = 18

#....................#
full_index_mode = off  
rt_mode = on    
rt_mem_page_size = 12    
rt_virtual_mem_enabled = on  
rt_max_memory = 28  
rt_max_virtual_pte = 12  
rt_vm_swap = /data/rocku/DBTest/Swap  

Consult three modes of how LunarBase works to get a whole picture of it. At present, the full index mode is not supported officially.

Consult LunarMax to learn how LunarBase virtual memory system works, how it controls physical memory use, avoiding resource race on a server and what the performance is.

The testing data set has 10,000,000 order records, 1,000,000 users and 100,000 products. Join user data and order data by denormalizing columns into a materialized view named user_order_view. Then the view has joined columns name, payment, product, time_stemp, age, degree, address, favorite, score, among which name, payment and product are searchable.

#Report of system status:
Here is the system status when the test was running:

Cpu(s): 67.1%us, 34.2%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st,    
Mem:    3921020k total, 1850736k used, 70308k free,   14932k buffers    
Swap:         0k total,       0k used,     0k free,  601032k cached  

Be noticed, here the Swap printed out is the Linux Swap, not the LunarBase Swap.

PID    USER        PR NI    VIRT   RES   SHR  S  %CPU  %MEM  
18400  rocku       20  0   4634m  2.5G  1724  S  28.3  66.8  

Since we have 3 searchable columns, and each has memory limitation 256MB, so the total off-heap physical memory use is 768MB in this test. Java part uses 1.8G heap memory. You may specify the JVM heap memory use by proper starting up parameters.

#Report of Insertion:

dbname = /data/rocku/DBTest/RTSeventhDB  
total records = 10,000,000  
maximum 5000 insert takes 1138625519 ns  
minimum 5000 insert takes 94372679 ns  
average 5000 insert takes 395830329 ns 

Apparently, more searchable columns costs more time to insert.

#Report of range query and point query:
Group 1, small range, small cache, uniformly distributed query keys:

dbname = /data/rocku/DBTest/RTSeventhDB  
cache_records_in_memory = 1 << 18   
search table = order_user_view   
search columns = payment, name, product  
total records = 10,000,000  
average records in range = 1236 recs  
total searches = 25,000,000  
search result having maximum 1500 records takes(ms):  2981.41255 (ms)
average range query costs(ms):  25.0063029 (ms)  
average point query costs(ms):  0.016008400 (ms)   

Group 2, middle range, small cache, uniformly distributed query keys:

dbname = /data/rocku/DBTest/RTSeventhDB 
cache_records_in_memory = 1 << 18   
search table = order_user_view   
search columns = payment, name, product  
total records = 10,000,000  
average records in range = 2316 recs  
total searches = 25,000,000  
search result having maximum 2500 records takes(ms): 1998.1445 (ms)
average range query costs(ms): 310.5773 (ms)  
average point query costs(ms): 0.010(ms)   

Group 3, middle range, small cache, Gauss distributed query keys:

dbname = /data/rocku/DBTest/RTSeventhDB 
cache_records_in_memory = 1 << 18      
search table = order_user_view   
search columns = payment, name, product  
total records = 10,000,000  
average records in range = 2536 recs  
total searches = 25,000,000  
search result having maximum 2500 records takes(ms):  566.7258 (ms)
average range query costs(ms): 28.6333 (ms)  
average point query costs(ms): 0.012(ms)   

Apparently, Gauss distributed query has a higher cache hit rate than the uniformly distributed ones. In real applications, Gauss or other distributions with peaks simulate better the real hot/cold data model, say, well sold items, most active users/groups, etc.