initial TODO

[dormando]

Yeah I always do these...

• Finish renaming some variables

• Retry if lru-crawler busy

• Rest of socket error handling

• Shorten some of the reparsing code

• Rate limiting experiments (currently is none)

• STDOUT mode, for dumping to file or socat/netcat

• Commandline argument for data buffer size (currently 16 megabytes)

• TLS support for destination at least

• Also a performance fix that's a little more involved: if we're stuck waiting for any particular POLL value, but another socket is ready for data, and that data is for a full buffer, it'll keep waking up burning CPU.

• Allow buffering keylist to disk as to not block the LRU crawler for a long period of time, if expiration crawling is critical to a workload.

[dormando]

perf fix wasn't too bad..

dumping to an rpi over a 1gbps link now uses 5-9% CPU on my source machine. runs at 200mbps for 50 byte keys and 1gbps for 900k keys.

seems like the best place to put any kind of limiter will be on the destination output as bandwidth... I'll run more tests with mcshredder running the latency checker + a workload while running a source dump on an rpi when I get a chance. I highly doubt pulling 100k+ keys/sec could cause serious CPU burn, but slamming all of the outbound bandwidth certainly would.

[dormando]

Think I'm done for the day. I'll probably do the error checking next, but all it can realistically do is exit.