Add connection options to the all handlers to allow for TCP connections
muayyad-alsadi opened this issue · 7 comments
it seems that l2 only work with unix socket, can't we pass a tcp port?
func Regular(sock string) handlers.HandlerConst {
return func() (handlers.Handler, error) {
conn, err := net.Dial("unix", sock)
sorry, thought I had responded to this earlier.
At the moment, yes it can only use a unix domain socket as this is the configuration we are using internally. It'd be fairly easy to add an option for a tcp socket as well.
I'll create an issue to this effect.
Not sure why I created a duplicate issue, that was not the right thing to do.
Anyway, this is probably not too much work to do. The logic would be fairly straightforward and since unix and tcp sockets have the same interface, it shouldn't change the code outside more than a couple files.
This might add some more config options on the command line, though, so it's starting to get quite complicated. It's probably a good reason to push for a config file as well.
After the current PR I'm preparing gets merged I can take a look at implementing this. Of course if anyone else wants to take a stab at it then by all means go ahead.
can you tell us more about your setup.
what do you use as l1 and l2? how much ram (memcached -m XYZ)? do you use twemproxy ?
We do not use twemproxy.
The L1 is memcached and the L2 is an in-process storage mechanism based on RocksDB. That component is not currently open source. L1 takes up about 20 GB in RAM and the L2 uses about 400 GB on disk with ~200GB usable for storing data. L2 also uses up some RAM for the RocksDB bloom filters and indices.
If you want to get an overview of how the system works overall, this talk I gave at Strange Loop last year describes the larger picture: https://www.youtube.com/watch?v=Rzdxgx3RC0Q
this awesome
Speaks a subset of the memcached text and binary protocols
let's say we have L2 that speaks text-only protocol, does rend allow text-only protocol? would it detect that? if not is there a way to force it to use text-only protocol for external l2?
No, at the moment it assumes the backends can speak the binary protocol. This was done for efficiency purposes as the binary protocol is definitely faster in the rend implementation. Enabling text to a backend would take quite a bit of work and it would not be used at Netflix at all. If you wanted to, you could try creating a handler implementation that does speak text, but it's likely going to be a little bit slower. As well the textprot package does not have a way, currently, to generate commands and understand responses in the same way that the binprot package does, so you'll have less built-in support. The text protocol isn't really that hard, though, so it's unlikely to be a real barrier.
The only spot text is supported is at the incoming connections, and we basically only use that for debugging purposes with human-scale traffic.
@muayyad-alsadi ping!
If you have more you'd like to discuss, please let me know. For the moment I'm going to close this issue because it has not seen any activity for quite a while.