1. 23 Jul, 2015 1 commit
    • antirez's avatar
      SDS: use type 8 if we are likely to append to the string. · ea9bd243
      antirez authored
      When empty strings are created, or when sdsMakeRoomFor() is called, we
      are likely into an appending pattern. Use at least type 8 SDS strings
      since TYPE 5 does not remember the free allocation size and requires to
      call sdsMakeRoomFor() at every new piece appended.
      ea9bd243
  2. 20 Jul, 2015 1 commit
  3. 17 Jul, 2015 2 commits
  4. 16 Jul, 2015 4 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
    • antirez's avatar
      Add sdshdr5 to DEBUG structsize. · 3da97ea6
      antirez authored
      3da97ea6
  5. 15 Jul, 2015 1 commit
    • antirez's avatar
      SDS: New sds type 5 implemented. · 0ab27a45
      antirez authored
      This is an attempt to use the refcount feature of the sds.c fork
      provided in the Pull Request #2509. A new type, SDS_TYPE_5 is introduced
      having a one byte header with just the string length, without
      information about the available additional length at the end of the
      string (this means that sdsMakeRoomFor() will be required each time
      we want to append something, since the string will always report to have
      0 bytes available).
      
      More work needed in order to avoid common SDS functions will pay the
      cost of this type. For example both sdscatprintf() and sdscatfmt()
      should try to upgrade to SDS_TYPE_8 ASAP when appending chars.
      0ab27a45
  6. 14 Jul, 2015 4 commits
  7. 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
  8. 09 Jul, 2015 2 commits
    • antirez's avatar
      GEOENCODE / GEODECODE commands removed. · b96af595
      antirez authored
      Rationale:
      
      1. The commands look like internals exposed without a real strong use
      case.
      2. Whatever there is an use case, the client would implement the
      commands client side instead of paying RTT just to use a simple to
      reimplement library.
      3. They add complexity to an otherwise quite straightforward API.
      
      So for now KILLED ;-)
      b96af595
    • antirez's avatar
      Geo: -Ofast breaks builds on older GCCs. · 1e127842
      antirez authored
      1e127842
  9. 06 Jul, 2015 1 commit
  10. 03 Jul, 2015 1 commit
  11. 01 Jul, 2015 1 commit
  12. 29 Jun, 2015 12 commits
  13. 27 Jun, 2015 3 commits
  14. 26 Jun, 2015 2 commits
    • MOON_CLJ's avatar
      pfcount support multi keys · c2322357
      MOON_CLJ authored
      c2322357
    • 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
  15. 24 Jun, 2015 3 commits