Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: dimensionnement



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



Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group