[Test] Added log.txt to gitignore for sentinel tests.
[Test] Added log.txt to gitignore for cluster tests.
[Test] Speed up creation of redis-server instances.
[Test] Replaced comment with windows-specific "if" condition.
On Windows, genClientPeerId used to return the hardcoded string "MASTER:0"
instead of the ip:port value, it is now fixed so the windows-only case in
the test is not needed anymore.
This is only an initial refactoring of the headers, the final goal is to
have hiredis completely independent from the QFork code in order to build
it as a standalone lib that can be used in other projects.
After a client connection fails with error "Accepting client connection: accept:
Unknown error" the server stops accepting new client connections because another
accept isn't queued.
Fix for issue https://github.com/MSOpenTech/redis/issues/275
An existing fix was not working in Release mode because the compiler
optimization was removing the code that forces the VEH to map the memory page.
[Change] Updated the ReleasePackagingTool to include all .pdb files.
[Change] Updated the nuget/chocolatey templates to conform with the guidelines:
- Replaced the Redis logo with the Redis icon.
- Changed the package title.
- Changed the package description.
- Removed the package summary to use a short version of the decription
instead.
[Change] Updated license.txt to 2015.
The previos attempt to process each client at least once every ten
seconds was not a good idea, because:
1. Usually because of the past min iterations set to 50, you get much
better processing period most of the times.
2. However when there are many clients and a normal setting for
server.hz, the edge case is triggered, and waiting 10 seconds for a
BLPOP that asked for 1 second is not ok.
3. Moreover, because of the high min-itereations limit of 50, when HZ
was set to an high value, the actual behavior was to process a lot of
clients per second.
Also the function checking for timeouts called gettimeofday() at each
iteration which can be costly.
The new implementation will try to process each client once per second,
gets the current time as argument, and does not attempt to process more
than 5 clients per iteration if not needed.
So now:
1. The CPU usage of an idle Redis process is the same or better.
2. The CPU usage of a busy Redis process is the same or better.
3. However a non trivial amount of work may be performed per iteration
when there are many many clients. In this particular case the user may
want to raise the "HZ" value if needed.
Btw with 4000 clients it was still not possible to noticy any actual
latency created by processing 400 clients per second, since the work
performed for each client is pretty small.
Enrico Giordani