1. 17 Jul, 2015 3 commits
  2. 16 Jul, 2015 3 commits
    • antirez's avatar
      Client timeout handling improved. · 25e1cb3f
      antirez authored
      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.
      25e1cb3f
    • Jiahao Huang's avatar
      92c146df
    • antirez's avatar
      Clarify a comment in clientsCron(). · e0bb454a
      antirez authored
      e0bb454a
  3. 14 Jul, 2015 1 commit
    • antirez's avatar
      DEBUG HTSTATS <dbid> added. · 0f64080d
      antirez authored
      The command reports information about the hash table internal state
      representing the specified database ID.
      
      This can be used in order to investigate rehashings, memory usage issues
      and for other debugging purposes.
      0f64080d
  4. 13 Jul, 2015 2 commits
    • antirez's avatar
      EXISTS is now variadic. · 4c7ee0d5
      antirez authored
      The new return value is the number of keys existing, among the ones
      specified in the command line, counting the same key multiple times if
      given multiple times (and if it exists).
      
      See PR #2667.
      4c7ee0d5
    • antirez's avatar
      Geo: fix command table keys position indexes for three commands. · 5c4fcaf3
      antirez authored
      GEOHASH, GEOPOS and GEODIST where declared as commands not accepting
      keys, so the Redis Cluster redirection did not worked.
      
      Close #2671.
      5c4fcaf3
  5. 09 Jul, 2015 3 commits
  6. 06 Jul, 2015 1 commit
  7. 03 Jul, 2015 1 commit
  8. 01 Jul, 2015 1 commit
  9. 29 Jun, 2015 14 commits
  10. 27 Jun, 2015 3 commits
  11. 26 Jun, 2015 1 commit
    • antirez's avatar
      Geo: from lat,lon API to lon,lat API according to GIS standard · fa9d62d3
      antirez authored
      The GIS standard and all the major DBs implementing GIS related
      functions take coordinates as x,y that is longitude,latitude.
      It was a bad start for Redis to do things differently, so even if this
      means that existing users of the Geo module will be required to change
      their code, Redis now conforms to the standard.
      
      Usually Redis is very backward compatible, but this is not an exception
      to this rule, since this is the first Geo implementation entering the
      official Redis source code. It is not wise to try to be backward
      compatible with code forks... :-)
      
      Close #2637.
      fa9d62d3
  12. 24 Jun, 2015 5 commits
    • antirez's avatar
      03ce1896
    • antirez's avatar
      Geo: GEOHASH command test. · 5fd756bf
      antirez authored
      5fd756bf
    • antirez's avatar
    • antirez's avatar
      Geo: Fix geohashEstimateStepsByRadius() step underestimation. · 55c4a365
      antirez authored
      The returned step was in some case not enough towards normal
      coordinates (for example when our search position was was already near the
      margin of the central area, and we had to match, using the east or west
      neighbor, a very far point). Example:
      
          geoadd points 67.575457940146066 -62.001317572780565 far
          geoadd points 66.685439060295664 -58.925040587282297 center
          georadius points 66.685439060295664 -58.925040587282297 200 km
      
      In the above case the code failed to find a match (happens at smaller
      latitudes too) even if far and center are at less than 200km.
      
      Another fix introduced by this commit is a progressively larger area
      towards the poles, since meridians are a lot less far away, so we need
      to compensate for this.
      
      The current implementation works comparably to the Tcl brute-force
      stress tester implemented in the fuzzy test in the geo.tcl unit for
      latitudes between -70 and 70, and is pretty accurate over +/-80 too,
      with sporadic false negatives.
      
      A more mathematically clean implementation is possible by computing the
      meridian distance at the specified latitude and computing the step
      according to it.
      55c4a365
    • antirez's avatar
      Geo: GEORADIUS fuzzy testing by reimplementing it in Tcl. · cf89a19f
      antirez authored
      We set random points in the world, pick a random position, and check if
      the returned points by Redis match the ones computed by Tcl by brute
      forcing all the points using the distance between two points formula.
      
      This approach is sounding since immediately resulted in finding a bug in
      the original implementation.
      cf89a19f
  13. 23 Jun, 2015 2 commits