An Afternoon of Code Golf in Lua to Achieve 4x Performance in Redis
amplitude.engineering
amplitude.engineering
Given all this problems, and in order to avoid introducing new commands, probably what could be done is to introduce options into HICNRBY, so that it can model both the variadic thing (only switching to a different reply when some option is given) and also to have specific options in order to switch on/off the reply of the incremented values and so forth.
Commands designed recently, after the old errors, have such capabilities. For instance BITFIELD is pretty powerful, and is a command doing increments: https://redis.io/commands/bitfield
https://en.wikipedia.org/wiki/Code_golf
There is an entire StackExchange site for it, which is interesting to look around in: https://codegolf.stackexchange.com
I have a question regarding "deployment" of Lua scripts (I've never used Redis for more than toys, so I may be wrong on something). I would assume a caller would do something like this just after the Redis cluster is up:
- calculate script's SHA
- EVALSHA a script
- script is not there
- EVAL script
And then later in the lifetime of the caller:
- calculate script's SHA
- EVALSHA script
Which means you wouldn't need to care about the script size, nor would you need to fiddle with your deployment pipeline.
Am I missing something ?
twemproxy independently exposes some statistics, it's probably safer to do it that way.
# Commandstats
cmdstat_info:calls=1,usec=57,usec_per_call=57.00
cmdstat_cluster:calls=8,usec=211,usec_per_call=26.38
cmdstat_zrange:calls=4,usec=1990,usec_per_call=497.50