You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During the performance tests, it is useful to use a server which generates coherent timestamps for measuring the latency in message delivery, for example: constant latency under heavy stress = great scalability.
with
latency = timestamp at publish - timestamp at receive
The Timestamp server should be reachable by any test Publisher or any test Consumer on the creation and reception of the messsage. To get a valid timestamp the Timestamp server, the Publisher or Consumer needs to
connect to the server, using its address, a port number
ask for a timestamp using the API
Implementation
Communication with the Timestamp server should be made using REQ-REP zeromq sockets. This has the following advantages:
REQ-REP guarantees a response, or fails otherwise
REQ requests are queued on the server
The returned timestamp will consist in the Java call System.currentTimeMillis() (or System.nanoTime(), to check with the relevance wrt the system clock), which returns the timestamp based on the system time, synchronized by NTP.
The size of the timestamp is 8 bytes.
Usage
On the physical host, the system time is synchronized with NTP. To be absolutely rigourous, we should manually force the synchronization of NTP and let the host run for at least 1 hour before launching the tests to let NTP successfully model the synchronization drift.
Back then, it has been established that in that configuration, a single timestamp server can largely handle up to 2400 timestamp requests per minute. Recommandation is thus to sample the timestamps on a subset of messages during the load tests.
The text was updated successfully, but these errors were encountered:
During the performance tests, it is useful to use a server which generates coherent timestamps for measuring the latency in message delivery, for example: constant latency under heavy stress = great scalability.
with
latency = timestamp at publish - timestamp at receive
The timestamp server is not intended to be run on a VM and must solely be run on a physical host to avoid time drifting issues from the hypervisors. (see http://www.vmware.com/files/pdf/techpaper/Timekeeping-In-VirtualMachines.pdf for detailed explanation)
Tasks:
Timestamp server API
The Timestamp server should be reachable by any test Publisher or any test Consumer on the creation and reception of the messsage. To get a valid timestamp the Timestamp server, the Publisher or Consumer needs to
Implementation
Communication with the Timestamp server should be made using REQ-REP zeromq sockets. This has the following advantages:
The returned timestamp will consist in the Java call System.currentTimeMillis() (or System.nanoTime(), to check with the relevance wrt the system clock), which returns the timestamp based on the system time, synchronized by NTP.
The size of the timestamp is 8 bytes.
Usage
On the physical host, the system time is synchronized with NTP. To be absolutely rigourous, we should manually force the synchronization of NTP and let the host run for at least 1 hour before launching the tests to let NTP successfully model the synchronization drift.
Back then, it has been established that in that configuration, a single timestamp server can largely handle up to 2400 timestamp requests per minute. Recommandation is thus to sample the timestamps on a subset of messages during the load tests.
The text was updated successfully, but these errors were encountered: