History log of /6.0.3/phosphor/tests/ (Results 1 - 25 of 157)
Revision (<<< Hide revision tags) (Show revision tags >>>)Date Author Comments
(<<< Hide modified files)
(Show modified files >>>)
Revision tags: v5.5.0
96501c5701-Jun-2018 Dave Rigby <daver@couchbase.com>

Add category_onoff_bench

Add a new benchmark suite which measures the cost of enabling /
disabling trace events via the category feature.

Includes test varints for basic TRACE_E

Add category_onoff_bench

Add a new benchmark suite which measures the cost of enabling /
disabling trace events via the category feature.

Includes test varints for basic TRACE_EVENT0 macro, along with
TRACE_LOCKGUARD_TIMED.

Example output:

Run on (24 X 1222.46 MHz CPU s)
2018-06-01 09:30:30
------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations
------------------------------------------------------------------------------------------
CategoryOnOffBench/Macro/1 114 ns 114 ns 4938250
CategoryOnOffBench/Macro/0 7 ns 7 ns 107491918
CategoryOnOffBench/Macro/1/threads:24 9 ns 203 ns 2718312
CategoryOnOffBench/Macro/0/threads:24 1 ns 11 ns 69343896
CategoryOnOffBench/LockguardTimedFast/1 117 ns 117 ns 5971601
CategoryOnOffBench/LockguardTimedFast/0 35 ns 35 ns 20201763
CategoryOnOffBench/LockguardTimedFast/1/threads:24 11 ns 237 ns 2367048
CategoryOnOffBench/LockguardTimedFast/0/threads:24 2 ns 52 ns 11621904
CategoryOnOffBench/LockguardTimedSlow/1 215 ns 215 ns 3150389
CategoryOnOffBench/LockguardTimedSlow/0 35 ns 35 ns 20142427
CategoryOnOffBench/LockguardTimedSlow/1/threads:24 19 ns 432 ns 1325832
CategoryOnOffBench/LockguardTimedSlow/0/threads:24 3 ns 55 ns 13389768
LockGuardBaseline 30 ns 30 ns 23235754
LockGuardBaseline/threads:24 2 ns 55 ns 10051872
NullBench 3 ns 3 ns 240751619
NullBench/threads:24 0 ns 4 ns 160179696

This demonstrates that all three macro variants tested (TRACE_EVENT0;
TRACE_LOCKGUARD_TIMED with fast and slow lock) have minimal overhead
when the macro is disabled.

- compare TRACE_EVENT0 to NullBench (which just measures benchmark
overhead). Single-threaded/multi-threaded:

------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations
------------------------------------------------------------------------------------------
CategoryOnOffBench/Macro/0 7 ns 7 ns 107491918
NullBench 3 ns 3 ns 240751619

CategoryOnOffBench/Macro/0/threads:24 1 ns 11 ns 69343896
NullBench/threads:24 0 ns 4 ns 160179696

- compare TRACE_LOCKGUARD_TIMED fast/slow to LockGuardBaseline (which
measures mutex lock/unlock cost) - lock()/unlock() is most of the
cost. Single-threaded/multi-threaded:

CategoryOnOffBench/LockguardTimedFast/0 35 ns 35 ns 20201763
CategoryOnOffBench/LockguardTimedSlow/0 35 ns 35 ns 20142427
LockGuardBaseline 30 ns 30 ns 23235754

CategoryOnOffBench/LockguardTimedFast/0/threads:24 2 ns 53 ns 11450304
CategoryOnOffBench/LockguardTimedSlow/0/threads:24 2 ns 56 ns 13618128
LockGuardBaseline/threads:24 2 ns 56 ns 10606656

We can also see the cost of LockguardTimed (when enabled) over a
vanilla lock guard - the cost of the mutex lock/unlock increases by
~4x in both single and multi-threaded configs:

------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations
------------------------------------------------------------------------------------------
CategoryOnOffBench/LockguardTimedFast/1 117 ns 117 ns 5971601
LockGuardBaseline 30 ns 30 ns 23235754

CategoryOnOffBench/LockguardTimedFast/1/threads:24 11 ns 237 ns 2367048
LockGuardBaseline/threads:24 2 ns 55 ns 10051872

Finally, we can also see the cost of "fast" vs. "slow" locks - when we
actually need to add 3x trace event macros to the log file; this adds
~100ns compared to the cost of performing the timing.

Note however that we'd typically consider a lock to only be "slow" if
it exceeded some number of milliseconds; so the cost of an extra 100ns
is negligible.

------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations
------------------------------------------------------------------------------------------
CategoryOnOffBench/LockguardTimedFast/1 117 ns 117 ns 5971601
CategoryOnOffBench/LockguardTimedSlow/1 215 ns 215 ns 3150389
LockGuardBaseline 30 ns 30 ns 23235754

CategoryOnOffBench/LockguardTimedFast/1/threads:24 11 ns 237 ns 2367048
CategoryOnOffBench/LockguardTimedSlow/1/threads:24 19 ns 432 ns 1325832
LockGuardBaseline/threads:24 2 ns 55 ns 10051872

Change-Id: I8c0ba6126d606edeb3b02a6103724c063832413a
Reviewed-on: http://review.couchbase.org/95014
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Tim Bradgate <tim.bradgate@couchbase.com>
Reviewed-by: Will Gardner <willg@rdner.io>

show more ...

5dfc7d2212-May-2018 Dave Rigby <daver@couchbase.com>

Ensure TRACE_LOCKGUARD{,_TIMED} locks mutex even when disabled

Unlike all other Phosphor macros, TRACE_LOCKGUARD{,_TIMED} have a
side-effect - they lock & unlock the given mutex. As such

Ensure TRACE_LOCKGUARD{,_TIMED} locks mutex even when disabled

Unlike all other Phosphor macros, TRACE_LOCKGUARD{,_TIMED} have a
side-effect - they lock & unlock the given mutex. As such, when
phosphor is compiled out they need to still perform this operation.

Fix this; and add a unit test for the expected behaviour.

Change-Id: Ia13135965ddd955d48694d2c558b7ae10920cc0e
Reviewed-on: http://review.couchbase.org/94109
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>

show more ...

39206c2e08-May-2018 Dave Rigby <daver@couchbase.com>

Add timed lockguard support

Add support for recording mutex wait and held times; but *only* if
either time exceeds a given threshold.

Identifying mutex contention (where one thr

Add timed lockguard support

Add support for recording mutex wait and held times; but *only* if
either time exceeds a given threshold.

Identifying mutex contention (where one thread is waiting a long time)
is extremely useful in tracking down performance issues, however the
median times are typically fast, and so if we logged events for all
mutex locks we'd quickly consume the whole trace log. Instead, if we
only record trace events for locks which are slower than some limit,
we can discount much of the "noise" and focus on the signal.

This patch also renames "lock.acquire" to "lock.wait" as IMHO that's a
clearer (and more concise) name for that the span represents.

Note that care must still be taken in using these macros, as each one
requires 3x calls to steady_clock::now(); even if no trace_event is
recorded. As such, consider adding to a non-default category, and only
enabling on-demand.

Change-Id: I4884cd8a2e4381ab16fb9ecfab0478546d52f0ef
Reviewed-on: http://review.couchbase.org/93889
Reviewed-by: Trond Norbye <trond.norbye@gmail.com>
Tested-by: Build Bot <build@couchbase.com>

show more ...

c00373e208-May-2018 Dave Rigby <daver@couchbase.com>

Use Complete event type for LOCKGUARD events

Change the implementation of TRACE_LOCKGUARD to use 2x Complete
events, instead of the previous 2x SyncStart, 2x SyncEnd events.

Cha

Use Complete event type for LOCKGUARD events

Change the implementation of TRACE_LOCKGUARD to use 2x Complete
events, instead of the previous 2x SyncStart, 2x SyncEnd events.

Change-Id: I532d68413417da65d773a210b201fb06d94c6c22
Reviewed-on: http://review.couchbase.org/93886
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Trond Norbye <trond.norbye@gmail.com>

show more ...

195e116e08-May-2018 Dave Rigby <daver@couchbase.com>

Use Complete event type for scoped events

Use the new Complete trace type to implement the scoped (TRACE_EVENT*
/ TRACE_FUNCTION*) event macros. This reduces the number of TraceEvent

Use Complete event type for scoped events

Use the new Complete trace type to implement the scoped (TRACE_EVENT*
/ TRACE_FUNCTION*) event macros. This reduces the number of TraceEvent
objects needed for these events by half; well worth the modest (1
word) increase in size to support Complete events (needed to add 64bit
duration field).

Implemented by adding a RAII-style ScopedEventGuard class; which
captures the arguments for a trace event, and if enabled logs the
event in it's destructor.

Note this change required the removal of the TRACE_EVENT() (varargs)
macro; as we now need to capture the types of the args (as the call to
logEvent() happens at the end of the scope).

Change-Id: I975927385616887a26ea8f894a1d06c08e322ecf
Reviewed-on: http://review.couchbase.org/93879
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Tim Bradgate <tim.bradgate@couchbase.com>

show more ...

cfd8018409-May-2018 Dave Rigby <daver@couchbase.com>

TracingOnOffMacro: Change macro to TRACE_EVENT

Change from the 'instant' event macro to the scoped event macro; as
this is much more commonly used and hence more representative.

TracingOnOffMacro: Change macro to TRACE_EVENT

Change from the 'instant' event macro to the scoped event macro; as
this is much more commonly used and hence more representative.

Change-Id: I4d4f3a9a192b6ae0ccbc44a021631c9dc9422b09
Reviewed-on: http://review.couchbase.org/93919
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Trond Norbye <trond.norbye@gmail.com>

show more ...

cd65876008-May-2018 Dave Rigby <daver@couchbase.com>

Introduce Complete event type

Add a new event type which logically combines a pair of SyncStart and
SyncEnd events into a single 'Complete' event.

In a trace that most of the ev

Introduce Complete event type

Add a new event type which logically combines a pair of SyncStart and
SyncEnd events into a single 'Complete' event.

In a trace that most of the events are duration events, using complete
events to replace the duration events can reduce the size of the trace
to about half.

This patch adds Complete events to the core of Phosphor; exposing them
via new TRACE_EVENT_COMPLETE* macros.

Change-Id: Ib445ea37d58ed5fb5f6b690c9c31d19337a09c56
Reviewed-on: http://review.couchbase.org/93877
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Trond Norbye <trond.norbye@gmail.com>

show more ...

6cfacecc20-Aug-2017 Will Gardner <willg@rdner.io>

Remove shared chunk tenant support

Shared chunk tenants were originally added as a workaround for
ForestDB being used by Go components that would create very
shortlived threads.

Remove shared chunk tenant support

Shared chunk tenants were originally added as a workaround for
ForestDB being used by Go components that would create very
shortlived threads.

With the likelyhood of phosphor now being used in ForestDB being
slim this patch removes the support for that.

As a side effect of doing this we now register a thread when it
tries to replace a chunk if it has not previously registered. There
is a (slight) potential for a SEGV to occur if a thread were to
subsequently terminate without deregistering and if tracing then
stopped as the TraceLog would try to evict a ChunkTenant allocated
in freed thread local storage.

This should not be an issue in KV-Engine as all threads (except
the main thread) are guaranteed to have registered and the
main thread stops tracing before exiting.

This will be resolved in a follow-up patch which will adjust the
way thread registration works to have ChunkTenant adopt RAII
(and instigate a temporary workaround for MacOS until a new
enough version of XCode is used to allow C++11 `thread_local`).

Change-Id: Ib1f53598dfadcdcb7842863505045ab63cd37724
Reviewed-on: http://review.couchbase.org/82500
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>

show more ...

Revision tags: v5.0.0
bcc011a630-Jul-2017 Will Gardner <willg@rdner.io>

Remove Sentinel

Removes the Sentinel now that it has been replaced by the ChunkLock.

Also renames/updates locations that once referred to the ChunkLock
(like config options).

Remove Sentinel

Removes the Sentinel now that it has been replaced by the ChunkLock.

Also renames/updates locations that once referred to the ChunkLock
(like config options).

Change-Id: Ibbb912f35ae08718a7dba8b14c2dd46fa0375207
Reviewed-on: http://review.couchbase.org/81566
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>

show more ...

db031a8a22-Jun-2017 Will Gardner <willg@rdner.io>

Replace Sentinel with ChunkLock (re-apply)

(Re-apply - previous version 9eb4d31 failed on gcc 4.9
environments. Fixed by making the failing static_assert
Apple-only).

Replace Sentinel with ChunkLock (re-apply)

(Re-apply - previous version 9eb4d31 failed on gcc 4.9
environments. Fixed by making the failing static_assert
Apple-only).

This patch replaces the Sentinel with the ChunkLock

This is to account for fundamental limitations with the way the
Sentinel synchronisation type works in terms of invalidating
the reference to the buffer.

Change-Id: I940b0629c8973c3d3693d2df9ef61a976fcae225
Reviewed-on: http://review.couchbase.org/80555
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>

show more ...

777a881912-Jul-2017 Dave Rigby <daver@couchbase.com>

Revert "Replace Sentinel with ChunkLock"

This patch fails to build on a number of GCC 4.9 architectures:

phosphor/include/phosphor/chunk_lock.h>:206:15: error:
'is_trivi

Revert "Replace Sentinel with ChunkLock"

This patch fails to build on a number of GCC 4.9 architectures:

phosphor/include/phosphor/chunk_lock.h>:206:15: error:
'is_trivially_constructible' is not a member of 'std'

This reverts commit 9eb4d31ebf1501e97aa8a3b353b628934d81e14c.

Change-Id: Ied9ebdbdb341d33eb3e02ed92b14a7246b2a4f29
Reviewed-on: http://review.couchbase.org/80553
Reviewed-by: Dave Rigby <daver@couchbase.com>
Tested-by: Dave Rigby <daver@couchbase.com>

show more ...

270ad14122-Jun-2017 Will Gardner <willg@rdner.io>

Replace Sentinel with ChunkLock

This patch replaces the Sentinel with the ChunkLock

This is to account for fundamental limitations with the way the
Sentinel synchronisation type

Replace Sentinel with ChunkLock

This patch replaces the Sentinel with the ChunkLock

This is to account for fundamental limitations with the way the
Sentinel synchronisation type works in terms of invalidating
the reference to the buffer.

Change-Id: If0df4dca07b11037aa121ffc8c93167d5923f31b
Reviewed-on: http://review.couchbase.org/79895
Reviewed-by: Dave Rigby <daver@couchbase.com>
Tested-by: Build Bot <build@couchbase.com>

show more ...

5c7d953220-Jan-2017 WillGardner <willg@rdner.io>

Introduce ChunkLock as a Sentinel replacement

This adds phosphor::ChunkLock as a replacement to phosphor::Sentinel
in an upcoming patch. It uses a different name for two reasons:

Introduce ChunkLock as a Sentinel replacement

This adds phosphor::ChunkLock as a replacement to phosphor::Sentinel
in an upcoming patch. It uses a different name for two reasons:

a) The old name could be confused with a sentinel value
b) It allows replacing Sentinel over multiple patches

Change-Id: I4e34f30ca674601eebf975be1b99625a68b8a87d
Reviewed-on: http://review.couchbase.org/72287
Reviewed-by: Dave Rigby <daver@couchbase.com>
Tested-by: Build Bot <build@couchbase.com>

show more ...

0556aacb21-Jun-2017 Will Gardner <willg@rdner.io>

Move `ThreadGate` to its own file as `Barrier` and use it generally

ThreadGate is renamed to Barrier (the more universal name for the
synchronisation primative).

It is then used

Move `ThreadGate` to its own file as `Barrier` and use it generally

ThreadGate is renamed to Barrier (the more universal name for the
synchronisation primative).

It is then used for both the library threaded_test and the
category_registry_bench.

Change-Id: I1e75a49af671f2fc2f295799d0d43d435b69a63b
Reviewed-on: http://review.couchbase.org/79859
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>

show more ...

defa788619-Jun-2017 Will Gardner <willg@rdner.io>

Add getStats methods to the TraceLog and CategoryRegistry

This patch extends usage of phosphor::StatsCallback to the
TraceLog and CategoryRegistry.

Change-Id: Ief828437a093c23cc

Add getStats methods to the TraceLog and CategoryRegistry

This patch extends usage of phosphor::StatsCallback to the
TraceLog and CategoryRegistry.

Change-Id: Ief828437a093c23cc4d5215496c5ce09e567c835
Reviewed-on: http://review.couchbase.org/79652
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>

show more ...

2b3d296619-Jun-2017 Will Gardner <willg@rdner.io>

Implement the registry benchmark using condition variables

The benchmark was previously becoming deadlocked when run under
ThreadSanitizer on the CV slaves with more than 2 threads.

Implement the registry benchmark using condition variables

The benchmark was previously becoming deadlocked when run under
ThreadSanitizer on the CV slaves with more than 2 threads.

The reason behind this is unknown but forcing more of the logic
to be done under mutual exclusion via use of a condition variable
instead of an atomic and a busy loop seems to resolve this.

Change-Id: Ie48cda8dab11851c23a8866dd36f99ec7f576eed
Reviewed-on: http://review.couchbase.org/79653
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>

show more ...

a6a21dcc05-Jun-2017 Will Gardner <willg@rdner.io>

MB-20466 Remove MSVC2013 workarounds

This patch removes a bunch of code working around missing/broken
functionality in MSVC2013.

Change-Id: I7e5fd80d55327691549dbdf2f64c6a14af9d

MB-20466 Remove MSVC2013 workarounds

This patch removes a bunch of code working around missing/broken
functionality in MSVC2013.

Change-Id: I7e5fd80d55327691549dbdf2f64c6a14af9d6a6d
Reviewed-on: http://review.couchbase.org/79060
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>

show more ...

1fae1f1317-Jan-2017 WillGardner <willg@rdner.io>

Add stats for Trace Buffers

Change-Id: Idd7b98e90703544c50294a96c4a3f2b1070ccd4c
Reviewed-on: http://review.couchbase.org/72111
Tested-by: buildbot <build@couchbase.com>
Reviewed

Add stats for Trace Buffers

Change-Id: Idd7b98e90703544c50294a96c4a3f2b1070ccd4c
Reviewed-on: http://review.couchbase.org/72111
Tested-by: buildbot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>

show more ...

be1001eb29-Dec-2016 WillGardner <willg@rdner.io>

Don't wait to stop tracing when the buffer is full

Previously threads would wait to acquire the TraceLog mutex in
order to stop tracing when the current trace buffer becomes full.

Don't wait to stop tracing when the buffer is full

Previously threads would wait to acquire the TraceLog mutex in
order to stop tracing when the current trace buffer becomes full.

This can actually be quite expensive if the lock is being used for
anything other than stopping tracing that takes any decent length
of time as it will result in logEvent calls blocking on all
threads with full chunks until the lock is released.

Further it's a minor waste of time if another thread is already
in the process of shutting down tracing as it will end up
acquiring the lock only to discover that tracing has already been
stopped.

Change-Id: I27a771ea450316a45613b5379d139f6fc6a82856
Reviewed-on: http://review.couchbase.org/71401
Tested-by: buildbot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>

show more ...

ae0ee7bc14-Jan-2017 WillGardner <willg@rdner.io>

Add threaded stopping tests

There are currently no tests which exercise a TraceLog stopping
tracing with multiple threads. This adds two basic tests which
stops tracing both external

Add threaded stopping tests

There are currently no tests which exercise a TraceLog stopping
tracing with multiple threads. This adds two basic tests which
stops tracing both externally and internally from the TraceLog
(ie. from explicit stop() and from the trace buffer becoming full).

Change-Id: I72acd324059b7e87791295ae691f9513dd6a656f
Reviewed-on: http://review.couchbase.org/72016
Tested-by: buildbot <build@couchbase.com>
Reviewed-by: Jim Walker <jim@couchbase.com>

show more ...

2febccbf15-Jan-2017 WillGardner <willg@rdner.io>

Fix non-server builds

Change-Id: I096e72b0957710f5870c11376761982fe80dd7d6
Reviewed-on: http://review.couchbase.org/72019
Tested-by: buildbot <build@couchbase.com>
Reviewed-by: D

Fix non-server builds

Change-Id: I096e72b0957710f5870c11376761982fe80dd7d6
Reviewed-on: http://review.couchbase.org/72019
Tested-by: buildbot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>

show more ...

7fd3204e09-Nov-2016 Dave Rigby <daver@couchbase.com>

Include correct process ID in events

This is useful when combining multiple thread runs (from different
proceses) into a merged trace file.

Change-Id: I7205ddd9b11990653177bdec4

Include correct process ID in events

This is useful when combining multiple thread runs (from different
proceses) into a merged trace file.

Change-Id: I7205ddd9b11990653177bdec4b1d33393389d2a6
Reviewed-on: http://review.couchbase.org/69733
Tested-by: buildbot <build@couchbase.com>
Reviewed-by: Will Gardner <willg@rdner.io>
Reviewed-by: Jim Walker <jim@couchbase.com>

show more ...

203de21618-Nov-2016 Daniel Owen <owend@couchbase.com>

MB-21726: Set environment before running tests

If the PHOSPHOR_TRACING_START environment variable is set the
export_test, trace_log_test and memory_usage_test fail.

This patch f

MB-21726: Set environment before running tests

If the PHOSPHOR_TRACING_START environment variable is set the
export_test, trace_log_test and memory_usage_test fail.

This patch fixes the problem by ensuring that the environment variable
is cleared before running any of the module tests or library tests.

To specify the enviroment it is best to have our own implementation of
main. Therefore the use of gtest_main is removed for these tests.

In addition the Win32 implementation of setenv is moved into the file
containing main function (test_main.cc) allowing the removal of a
duplicate copy of the function.

Change-Id: I4e36d356ec02b4fc4517d62e4b32363be8ec296c
Reviewed-on: http://review.couchbase.org/70095
Reviewed-by: Will Gardner <willg@rdner.io>
Reviewed-by: Dave Rigby <daver@couchbase.com>
Tested-by: buildbot <build@couchbase.com>

show more ...

e04007f014-Nov-2016 Daniel Owen <owend@couchbase.com>

TRACE_LOCKGUARD: Provide the ability to event trace locks

Add a new macro which takes a std::mutex or similar (it needs to
provide a lock and unlock function), a category and a name. The

TRACE_LOCKGUARD: Provide the ability to event trace locks

Add a new macro which takes a std::mutex or similar (it needs to
provide a lock and unlock function), a category and a name. The
category and name match those used in the existing trace macros
e.g. TRACE_EVENT0.

The macro provides a scoped lock (i.e. the inputted lock is unlocked
on leaving the current scope). In addition, the macro generates 4
events, that are used to record the duration of acquiring the lock,
and the duration the lock is held.

The acquiring phase is marked by a start and end event which has the
name <input name> + ".acquire". The held phase is marked by a start
and end event which has the name <input name> + ".held".

A test for the new macro is also provided.

Change-Id: Ifde30a17cb4f7c4bc9d94b8ac46d82edee17c901
Reviewed-on: http://review.couchbase.org/69898
Tested-by: buildbot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>

show more ...

336ad82317-Nov-2016 Dave Rigby <daver@couchbase.com>

Use #CPU-based thread count for benchmarks

A number of the benchmarks used a fixed (32) upper bound for the
number of threads to create. While this useful for cross-machine
compariso

Use #CPU-based thread count for benchmarks

A number of the benchmarks used a fixed (32) upper bound for the
number of threads to create. While this useful for cross-machine
comparisons, when running on machines whose CPU count is much less
than 32 (and/or virtualized hardware), running 32 threads can have a
significant detremental effect on the benchmark runtimes.

For example, running 32 threads on a 4-core Xen VM (ubuntu12-cv-05)
the following numbers are seen for chunk_replacement_benchmark:

Run on (4 X 2497.18 MHz CPU s)
2016-11-17 01:07:12
Benchmark Time CPU Iterations
--------------------------------------------------------------------
RegisterTenants/threads:1 1818 ns 1810 ns 388889
RegisterTenants/threads:2 3336 ns 6638 ns 106060
RegisterTenants/threads:4 2522 ns 9034 ns 82352
RegisterTenants/threads:8 58773 ns 212704 ns 24560
RegisterTenants/threads:16 321890 ns 1152500 ns 1600
RegisterTenants/threads:32 224536907 ns 675466250 ns 3200

Compare these to a 24 core physical machine (same underlying hardware):

Run on (24 X 2601 MHz CPU s)
2016-11-17 01:08:37
Benchmark Time CPU Iterations
--------------------------------------------------------------------
RegisterTenants/threads:1 2449 ns 2447 ns 248977
RegisterTenants/threads:2 3939 ns 7005 ns 157626
RegisterTenants/threads:4 2351 ns 9031 ns 70964
RegisterTenants/threads:8 2020 ns 11125 ns 60800
RegisterTenants/threads:16 2143 ns 17306 ns 52800
RegisterTenants/threads:32 2319 ns 16904 ns 36256

The times are comparable up to 4 threads (num CPUs for VM), but
degrade rapidly - the 32 thread test takes over 2milliseonds for an
iteration!

To allow benchmarks to be run on a wide range of hardware, remove the
fixed upport bound of 32, and instead use an upper bound of 2x the
number of CPUs.

To permit comparison between different sized machines, the upper bound
calculation can be overridden by setting the env var
PHOSPHOR_BENCH_NUM_THREADS - for example setting
PHOSPHOR_BENCH_NUM_THREADS=32 will give the same behaviour as before
this patch.

Change-Id: I793dff1473a26bd76546f6c5fab9f6965ef1c6cb
Reviewed-on: http://review.couchbase.org/70011
Reviewed-by: Daniel Owen <owend@couchbase.com>
Tested-by: buildbot <build@couchbase.com>
Reviewed-by: Will Gardner <willg@rdner.io>

show more ...

1234567