kellabyte

#Setup

• Benchmark client: Linux, gigabit LAN, running Wrk benchmark tool.
• Haywire server: Windows 7, Intel Core i7 930. Haywire running in Release mode.

Haywire is running in single threaded mode (using a IOCP pool for IO) with Haywire event-loop fan-out disabled (broken right now). So this means Haywire won't use all the available cores yet.

#Native results

• CPU: Peak 5%
• RAM: 2.5MB

kellabyte

cmake_minimum_required(VERSION 2.8)

# create_source_group(relativeSourcePath sourceGroupName files)
#
# Creates a source group with the specified name relative to the relative path
# specified.
#
# Parameters:
#    - sourceGroupName: Name of the source group to create.
#    - relativeSourcePath: Relative path to the files.

kellabyte

kellabyte

Indexes are 8 (to make it small enough to read) sorted 32bit integer segments. Each integer represents the record_id that matches the term. Each segment is stored in a Key/Value store.

Index A represents the rows that have the term "Canada" in a Country column. Index B represents the rows that have the term "Ontario" in a Province column.

Segments from both indexes will be read off disk using a Key/Value store and intersected to evaluate a conjunction query.

Index A | Index B
-----------------
     Segment 1

---

kellabyte

cmake_minimum_required(VERSION 2.6)

# create_source_group(relativeSourcePath sourceGroupName files)
#
# Creates a source group with the specified name relative to the relative path
# specified.
#
# Parameters:
#    - sourceGroupName: Name of the source group to create.
#    - relativeSourcePath: Relative path to the files.

kellabyte

$ likwid-perfctr -C S0:0@S1:0 -g MEM ./example 1

412,892,333/sec

+-----------------------------+-------------+---------+
|           Metric            |   core 0    | core 1  |
+-----------------------------+-------------+---------+
|     Runtime (RDTSC) [s]     |   7.81101   | 7.81101 |
|    Runtime unhalted [s]     | 0.00114729  | 5.27201 |

| CPI | 1.40394 | 2.24556 |

kellabyte

$ likwid-topology -g

-------------------------------------------------------------
CPU type:       Intel Core 2 45nm processor
*************************************************************
Hardware Thread Topology
*************************************************************
Sockets:        2
Cores per socket:       4

Threads per core: 1

kellabyte

I'm running some SSE and AVX instructions on Harpertown and Sandy Bridge systems and I noticed the Sandy Bridge system was able to scale to more cores before the performance flat lined. The Harpertowm system did not improve when using 2 threads over 1 thread. So I started to look into why.

Running with 1 thread:
likwid-perfctr -C S0:0@S1:0 -g MEM ./example 1

+-----------------------------+-------------+---------+
|           Metric            |   core 0    | core 1  |
+-----------------------------+-------------+---------+
|     Runtime (RDTSC) [s]     |    7.795    |  7.795  |

| Runtime unhalted [s] | 0.00113065 | 5.25528 |

kellabyte

Running 10s test @ http://skynet1:8080
  24 threads and 24 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   292.17us   91.68us  16.32ms   98.52%
    Req/Sec     3.44k   204.55     4.89k    58.86%
  Latency Distribution
     50%  285.00us
     75%  323.00us
     90%  347.00us

99% 389.00us

kellabyte

Plaintext 8 threads

Connections: 8		Haywire		Requests/sec:  57334.75
Connections: 8		Go		    Requests/sec:  42901.57
-------------------------------------------------------
Connections: 16		Haywire		Requests/sec:  71460.01
Connections: 16		Go		    Requests/sec:  71891.07
-------------------------------------------------------
Connections: 32		Haywire		Requests/sec:  78421.15
Connections: 32		Go		    Requests/sec:  89202.96

---