Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subtask of #52: Timestamp server for testing #107

Open
nltran opened this issue Jan 17, 2013 · 0 comments
Open

Subtask of #52: Timestamp server for testing #107

nltran opened this issue Jan 17, 2013 · 0 comments

Comments

@nltran
Copy link
Collaborator

nltran commented Jan 17, 2013

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:

  • Define API for Timestamp server
  • Implementation
  • Start-stop scripts for running on physical hosts

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

  • 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant