feat: momento apis - set_if_absent, set_if_present_and_not_equal, item_get_type

[nidhidhamnani]

Adding momento's set_if_absent, set_if_present_and_not_equal, and item_get_type apis to be able to load test it

Testing

Both set_if_absent and set_if_present_and_not_equal fall under set_if api internally, hence 8K tps instead of 4K.

[krispraws]

One question about old and new values for SetIfPresentAndNotEqual, and one minor nit about DRYing up the metrics for conditional writes.

[krispraws]

If you generate different values for old_value and new_value, the result will always be stored. Is that intentional?

[brayniac]

There might not be a good alternative. We don't really have any place we're keeping history for each key to do some % of overwrite. Similar problem as testing something like a CAS operation. You might be able to fake something with two keyspaces? But the workload generation isn't really designed with this in mind.

If there's need in the future, what I'd consider is some mechanism for playing workload from a file and trying to make that flexible in terms of whether exact or random out of N values are used in each place. Then you could dial in some very specific patterns by generating that file or getting some prod trace and replaying it.

For now, maybe a comment acknowledging this behavior and that it's expected would be good?

[krispraws]

sounds good

[krispraws]

I wonder if we could move some of this boilerplate code into record_result!. Especially for conditional write responses where we do not care about the actual value of the item in the response and just want to record metrics for stored vs not_stored. The macro already seems to have some logic based on 3 arguments being passed to it

[brayniac]

I think you could, but it'd need enough other code to support inspecting arbitrary enums to check stored/not_stored (some sort of trait that's implemented for each conditional write response enum?) that I don't know if it'd save any real code.

record_result!() could maybe still be used here for the EX and TIMEOUT - it'd expect to increment something like SET_IF_ABSENT_OK - which should exist since the request! macro does some paste magic to generate _OK, _EX, and _TIMEOUT metrics for the same base request type. Then this could be a record_result!() and an

record_result!(...);

if let Ok(Ok(r)) = r { 
    match r { 
        /// enum variant handling 
    }
 }

Might be worth making that change

[brayniac]

Same here as with my comment above. record_result + if let might make this cleaner)