I don't understand why you say the semantic would change: flush_all +10 <=> flush_all executed in 10 seconds flush_all -10 <=> flush_all executed 10 seconds ago
Or am I missing a subtil difference ? On Feb 14, 5:32 pm, Didier <[email protected]> wrote: > 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, "[email protected]" <[email protected]> > 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.
