IMO, usage of the negative value is debatable, since it means the semantic of this parameter will change with its sign. But the feature itself is definitely useful.
Let's suppose the "flush_all -num" operation only deprecates a low number of items, and it is required to guarantee that no item is older then a given threshold on all the nodes. For large memcached installations, flushing a unique node has almost no impact on the performance of the database. However, the flush operations have to be executed sequentially with some delay. The higher delay, the less impact. In this case, a "flush_all -num" could help to decrease the total duration of the operation, because some flushes (or perhaps all of them) can be parallelized. For small memcached installations, the duration of the operation is not a concern. However the impact on the database is. Considering a 2 nodes installation, a normal flush on one node implies to loose 50 % of the cache. In this case, a "flush_all -num" will decrease the impact on the database, because much less items will be deprecated. So in both cases, I can see a clear benefit of the feature. On Feb 11, 12:25 pm, "colin.pit...@gmail.com" <colin.pit...@gmail.com> wrote: > I find this feature a must have ! > Currently, if you need for any reason to ensure your cache only > contains fresh data (say for the final phase of a modification in your > data format), you have to possibilities: > - having set a TTL when updating items in your application at the > very first version, and never having removed it, and wait this TTL > with the new version running > - do a full flush, which means having a "memcached outage" > > Moreover, current behaviour of TTL in flush is really misleading. > Judging by the behavior of TTL in update/set/replace, you would say > the TTL means items not updated since TTL will be deleted (i.e. the > same feature Jean-Charles done, but without the negativeness). In fact > it's not the case. It's only a delay before the flush. If I want to > flush in 10 s, I just do sleep 10 && memflush. From applicative side, > it give flexibility as you don't have to fork or spawn to have the > flush done later asynchronously, but I don't see the flush as an > applicative feature, more an administrative operation. > > I agree that modifying the flush so that flush(10) remove all items > not updated during the last 10 seconds would be violent as it would > break compatibility. That's why I like the idea of using negative > values. It remains logical (flush(-10) acts as if flush had been done > 10 seconds ago) and compatible with old behaviour.
