server_names scaling

[SplitIce]

Thank you, that makes sense and a bit of testing reveals that is correct.


On Wed, Apr 16, 2014 at 8:59 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Wed, Apr 16, 2014 at 08:38:10PM +1000, SplitIce wrote:
>
> > Hi all,
> >
> > I have spent the day troubleshooting why one server in our network
> reloaded
> > / tested configuration extremely slowly.
> >
> > We have found that server_names scales very poorly, once a certain point
> is
> > reached (approx 5.5k entries globally, 5k entries for a single host)
> > performance drops from a <0.5s reload time to 15s+.
> >
> > The large host of ~5,000 entries is a malware domain zone and all server
> > names in this zone are using the wildcard name format.
> >
> > For now we have resolved this issue by fixing an inefficiency in our
> > configuration (namely using *.domain.com and domain.com) however I feel
> > this is most likely a bug or at-least an unintended behaviour.
> >
> > Relevant configuration entries:
> > server_names_hash_max_size 8000;
> > server_names_hash_bucket_size 128;
>
> With max_size 8000, and 5k entries - probability of collisions
> while building a cache is high (think of birthday paradox).  And
> bucket_size 128 isn't high enough to allow multiple collisions.
> As a result, nginx may (and likely will) spend a lot of time trying
> to build an optimal hash.
>
> Trivial solution is to use higher max_size and/or bucket_size.
>
> --
> Maxim Dounin
> http://nginx.org/
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20140416/68105cb2/attachment.html>