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

Reply via email to