search

mit-pdos / noria

Fast web applications through dynamic, partially-stateful dataflow
Apache License 2.0
4.99k stars 244 forks source link

Send write-ACKs only after process(..) is done #63

Closed ekmartin closed 6 years ago

ekmartin commented 6 years ago

This makes it possible to send back more information with the ACKs than what's currently being done. An AUTO_INCREMENT implementation could e.g. be handled in each base operator, by returning the newly selected ID from on_input.

This also helps with stuff like the persistent bases implementation, where writes are persisted in materialize (meaning that ACKs sent from persistence would be premature).

Unfortunately this seems to increase write latencies with about ~10% at the 95th and 99th percentiles, which is probably just a result of the domain having to do more work (such as materializing updates) before returning an ACK. Happy to hear other suggestions for how this could be implemented too.

ms705 commented 6 years ago

This seems like a reasonable change to me, and 10% additional write latency in the 95th percentile is an acceptable price to pay for the flexibility of being able to do more elaborate things in process before a write returns.

@jonhoo @fintelia I'm inclined to merge this. Any thoughts on the threading of the executor through various APIs? (that's what the bulk of the code changes are)

jonhoo commented 6 years ago

I am a little bit sad about thread Executor everywhere, but the alternative is using thread-local variables, which has its own set of issues. I think I'm fine with merging.

ekmartin commented 6 years ago

I can re-run the bencmarks on jerry later today and post the results here.

ekmartin commented 6 years ago

Seems to be about ~5-10%.

all-plot-batch all-plot-sjrn

And just the 95th: plot-batch plot-sjrn

jonhoo commented 6 years ago

Okay, so this seems to suggest that (as we suspected), this adds a little bit of latency, but doesn't really affect throughput. Seems good!