On Tue, Feb 13, 2018 at 8:19 AM, Graham Leggett <minf...@sharp.fm> wrote: > On 09 Feb 2018, at 7:12 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > [Why] would you compare 8192 byte strings as identifiers? > > I just checked the code, and as I suspected the “name” field isn’t a name, > or an identifier, it’s actually a URL prefix.
Ah ha! > When a balancer is found to match, the “balancer:foo” is removed, and > replaced by the name, with the rest of the URL postfixed to it. > > As you can see - we’re currently arbitrarily limiting the length of the URL > prefix to 256 characters, because 640k is big enough for everybody. Got it. I had misunderstood, thanks for clarifying. Must this replacement be stored in a fixed SHM buffer? Or can this be stored in the member data in pconf, in its minimal buffer length? We might lose display details from a prior graceful restart generation. Guess I need to examine the dynamic reconfig feature set. >> On Feb 8, 2018 2:39 PM, "Jim Jagielski" <j...@jagunet.com> wrote: >>> >>> Another, much more extensive and intrusive fix would be to create >>> each ind field dynamically and tuck away in the proxy_worker_shared >>> struct the SHM field to be attached to which holds the actual dynamically >>> allocated string. Better on SHM usage (our current usage is sloppy >>> regarding >>> SHM utilization due to the fixed char arrays, most of which aren't >>> full) but more complex in other ways. >>> >>> Idea would be to use the actual name and generate a hash from >>> that, use the hash as the SHM filename, create the SHM using >>> that filename (hash) to dynamically allocate the host string >>> and then store in proxy_worker_shared the hash (filename) used. >>> Attach to that SHM as needed. >>> >>> Cleanup would need some thought… > > Another option for the name is to store a URL prefix length and a hash of > the prefix. If the hash of the prefix matches, we have a match. Would this > work, would it be too expensive to hash on every hit, would it be safe > enough? > For the hostname, the field only has to be 256 characters long (because > RFC1035 says it must be) and that’s manageable. I have created a patch to do > this and it works for me. I'm ok with comparing the 256 characters of the URL, although a hash could be a great optimization, hashing is already a key asset of Maglev LB; https://research.google.com/pubs/pub44824.html
