Commit 08e4226e59 broke redis-benchmark.
Made time function initialization automatic on first execution.
Added explicit initialization of time functions in redis-benchmark, to
avoid additional cost on first benchmark execution.
Addressing https://github.com/MSOpenTech/redis/issues/188
- Made gettimeofday use GetSystemTimePreciseAsFileTime when available
- Introduced definitions for gettimeofday_fast and gettimeofday_precise,
so that calls can be specialized based on specific usage requirements
- Introduced GetHighResRelativeTime, for high-resolution relative time
measurements on all Windows versions.
Slave processes were not using the master process log file.
On Unix this is relying on the server.logfile variable being available
to the slave processes through fork(), and reopening the logfile
in the slaves (on every log event).
On Windows we don't use server.logfile and require an explicity call
to setLogFile.
I resorted to explicitly passing the logfile to the slaves as a
command line argument, so the logfile argument (and logging) can be
available to the slave before qfork and globals setup have completed.
Writing to the same file atomically from multiple processes requires
using CreateFile with FILE_APPEND_DATA, instead of fopen, which provides
atomicity on Unix but not on Windows.
Also changed the implementation to not reopen the logfile on every
log event, and not flushing the file on every write. Performance is
dramaticaly improved this way.
Redis-benchmark on windows seems to be not able to calculate the time granularity in micro seconds.
Came across this article http://msdn.microsoft.com/en-us/library/windows/desktop/dn553408(v=vs.85).aspx and updated the benchmark for latency measurements accordingly.
Windows:
Following is output from windows for micro seconds taken for each request. Where for any request taking less than 1 ms is being calculated as 0
redis-benchmark.exe -h <azurerediscache> -a pwd -c 1 -d 1024 -t get -n 10
0,0,0,0,0,0,0,0
Linux:
src/redis-benchmark -h <azurerediscache> -a pwd -c 1 -d 1024 -t get -n 10
792,800,808,820,837,845,888,891,971,2498
After the change on windows now it shows following:
796,809,887,890,893,943,944,974
It is not clear if files open in append only mode will automatically fix
their offset after a truncate(2) operation. This commit makes sure that
we reposition the AOF file descriptor offset at the end of the file
after a truncated AOF is loaded and trimmed to the last valid command.
Recently we introduced the ability to load truncated AOFs, but
unfortuantely the support was broken since the server, after loading the
truncated AOF, continues appending to the file that is corrupted at the
end. The problem is fixed only in the next AOF rewrite.
This commit fixes the issue by truncating the AOF to the last valid
opcode, and aborting if it is not possible to truncate the file
correctly.
The code to check the number of voters was never updated to follow the new
Sentinel specification, so the number of voters was computed using only
the set of Sentinels that provided a vote.
This means that there is a changing majority on partitions, even if
usually the issue is not triggered because of the configured quorum
check (what was broken was the other implicit check that requires anyway
half of the known sentinels to agree in order to start a failover).
The original implementation was modified in order to allow to
selectively announce a different IP or port, and to rewrite the two
options in the config file after a rewrite.
When aof-load-truncated option was introduced, with a default of "yes",
the past behavior of the server to abort with trunncated AOF changed, so
we need to explicitly configure the tests to abort with truncated AOF
by setting the option to no.
Because of the new ability to start with a truncated AOF, we need
to correctly release all the memory on EOF error. Otherwise there is a
small leak, that is not really a problem, but causes a false positive in
the tests that detect memory leaks.
Alexis Campailla