Re: dimensionnement

From: GUEDJ Patrick DSIC BI <patrick(dot)guedj(at)interieur(dot)gouv(dot)fr>
To: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: dimensionnement
Date: 2006-08-14 15:03:26
Message-ID: 200608141703.27190.patrick.guedj@interieur.gouv.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-fr-generale

Voici comment je procède habituellement pour ce genre de problème.

1 - Commencer par préciser si des fichiers sont joint à ces formulaires, et
leur taille.

2 - En ce qui concerne la densité des requêtes arrivant au serveur il est
préférable de considérer qu'il n'en arrive jamais deux simultanément, mais de
calculer le nombre moyen de requêtes par minute en période de pointe. En
effet, dans un interval de temps suffisamment petit il n'arrive jamais deux
évènements simultanément (cf théorie sur les processus stochastiques).

Avec 10 000 requêtes par jour, en considérant que 1/3 des requêtes arrivent
pendant l'heure de pointe (1/3 résulte de mon expérience, prendre une autre
valeur le cas échéant après une étude le justifiant), cela fait 10 000 * 1/3
= 3 333 requêtes par heure. Soit 56 requêtes par minute.

3 - A partir de là initialiser la base avec 20 Go de données, puis organiser
une simulation injectant dans l'application 56 requêtes par minute avec une
dispersion aléatoire de la durée séparant chaque requête (un loi
exponentielle à priori), en commençant par utiliser des machines pas trop
chères, en particulier pour la bd. Il existe des outils (jmeter ...)
permettant de le faire assez facilement, quant on connaît l'outil. Mais cela
peut aussi être programmé.

4 - Si le temps de réponse est ok, le problème est réglé. Sinon il vaut mieux
commencer par optimiser le code applicatif et les réglages systèmes (index
dans la base, mémoire allouée ...), avant d'envisager d'augmenter la
puissance des machines.

Procéder ainsi, plutôt que d'acheter a-priori de grosses machines, présente
deux avantages :

a - ne pas dépenser inutilement de l'argent dans du matériel alors que le
composant à optimiser est peut être applicatif (la performance est celle du
maillon le plus faible de la chaîne) ;

b - disposer d'une simulation qui peut être rejouée aussi souvent que
nécessaire pour s'assurer que les performances ne vont pas se dégrader après
une opération de maintenance (modification du code ...), ou si une
augmentation de la charge est prévue (nb de requêtes/minute, taille des
fichiers joints ...).

Patrick

Le Mercredi 9 Août 2006 13:38, gpap(at)ifrance(dot)com a écrit :
> Bonjour
>
> Il me faudrait un serveur pour héberger postgres. Ma base de données
> fera dans les 20Go. Il y aura environ 10000 accès par jour avec des
> pointes de 15 accès simultanément.
>
> Je ne connais pas encore l'appli web qui utilisera cette appli. En gros
> les données qui seront lu/ecrit proviendrait d'un formulaire.
>
> Que me conseillez vous comme dimensionnement de serveur ?
>
> Cordialement
>
> Gertrude

In response to

Browse pgsql-fr-generale by date

  From Date Subject
Next Message Benoît Barbier 2006-08-27 11:42:42 Synchroniser une base MS SQL avec PostgreSQL
Previous Message gpap 2006-08-09 11:38:57 dimensionnement