Bonjour Messieurs,
(je passe en FR et hors ML et je top-poste!!!).
Pierre, je suis déjà en contact avec plusieurs autres Pierre de chez Critéo
(le prénom, c'est un critère de recrutement chez vous???)
En tant que "dev" et "mainteneur" du server state, je ne suis pas surpris
pas la lenteur de chargement, par contre l'ampleur de cette lenteur
m'étonne beaucoup.
En fait, c'est un parcours de liste fait à base de strcmp de mémoire, donc
si tu as beaucoup de backend qui eux-même ont beaucoup de serveurs, c'est
en effet pas super optimal.
On avait fait comme ça car on pensait que le serveur state ne serait pas
utilisé "at scale" comme vous le faites.
Pierre: Combien as-tu de backend et de serveur (en moyenne) par backend,
dans une seule et même configuration
Il n'y a qu'un seul moyen de virer tous ces warnings, c'est de forcer l'id
des backend et des serveurs dans ta conf (paramêtre 'id').
(j'ai prévu de passer chez Critéo la semaine prochaine, je te ferais signe,
on pourra voir ton problème en live).
Willy: Il me semble que les backends sont déjà stockés dans des ebtree.
Pourrait-on stocker aussi les serveurs dans des ebtrees pour accélerer la
recherche?
Ou mieux, faire un arbre qui avec en point d'entrée "<backend>/<server>" ?
Baptiste
On Wed, Oct 3, 2018 at 2:00 PM Pierre Cheynier <p.cheyn...@criteo.com>
wrote:
> Hi Willy,
>
> > Not really. Maybe we should see how the state file parser works, because
> > multiple seconds to parse only 30K lines seems extremely long.
>
> I would even say multiple minutes :)
>
> > I'm just thinking about a few things. Probably that among these 30K
> servers,
> > most of them are in fact tracking other ones ? In this case it could make
> > sense to have an option to only dump servers which are not tracking
> > others, as for a reload it can make quite some sense. Is this the case
> > for you ?
>
> What do you mean by "tracking other ones"?
>
> What I can tell is that, for historical reasons, we named all server the
> same way for each backends (ie. srvN) in the configuration template, and
> are using "server templates" to add MAINT servers in the pool so that they
> can be added at runtime later.
>
> This naming thing can be changed now, but I don't know this issue could be
> related or not.
>
> What we're doing basically when getting a new event:
> * if it requires to delete / update / add server(s) in one or multiple
> pools we only use the runtime API and try to reuse free slots.
> * if a backend/frontend has to be created / updated / deleted OR if the
> free slots for a given backend is full we reload using a configuration
> template.
> * in Jinja2 this template looks like (simplified):
>
> backend be_foo
> <options>
> {%- for server in servers %}
> server srv{{loop.index0}} {{server.address}}:{{server.port}} weight
> {{server.weight}}{%- if server.tls %} ssl{%- endif %} check port 8500
> {%- endfor %}
> # Create 25 free slots, servers are numbered from N to N+25
> server-template srv {{ servers|length }}-{{ servers|length + 25 }}
> 0.0.0.0:0 check disabled
>
> Doing this I noticed that we have a lot of 'bad reconciliations'
> triggering warning logs, such as:
>
> [WARNING] can't find server 'srv28' with id '29' in backend with id '9' or
> name 'be_test'
> [WARNING] backend name mismatch: from server state file: 'be_foo', from
> running config 'be_bar'
>
> I don't know if these inconsistencies (that clearly have to be fixed) can
> cause additional delays.
>
> Thanks,
>
> Pierre
>
