Pool de connexions

SAS/ = 12 Septembre, 2008 - 19:02

Bonjour,

Peut-être devriez-vous envisager un pool de connexions avant de modifier l'architecture pour atteindre 500 cnx.

Librement,
Stéphane Schildknecht
Dalibo
PostgreSQLFr

Pool de connexions

ducteil/ = 16 Septembre, 2008 - 02:36

Bonjour,

J'avais déjà essayé pg-pool sur un serveur moins performant et avais remarqué des ralentissements, et même un blocage du service(et nous n’étions qu’une centaine).
Une augmentation de la ram, et quelques modifications de paramètres nous ont permis d’avoir un système stable. Mais je veux anticiper la charge de 500 users parallèles.

Comment faire pour tester pgpool ou PgBouncer en situation réelle ?
En supposant que ma trésorerie soit sans fin, faudrait-il mieux s'orienter vers une solution logiciel de "pool de connexions", ou une amélioration matériel du serveur (DD, ram, OS, noyau, etc.).

Je ne suis malheureusement pas le seul dans ce cas et nous sommes incapables d’avoir une vision claire sur ce problème.
Même de simples idées seraient appréciées.

Merci d’avance.

Cordialement
Olivier

Risques

SAS/ = 20 Septembre, 2008 - 05:57

Bonjour,

Il faut bien comprendre qu'un concentrateur de connexion comme pgpool va agir en ouvrant un nombre prédéfini et limité de connexions au serveur.
Ces connexions sont persistantes. Si dans votre code vous maintenez des connexions persistantes, alors vous allez vite bloquer le serveur, plus vite encore que sans concentrateur.

J'ai pour ma part déjà mis pgpool en place sur des architectures Web accueillant plusieurs milliers d'utilisateurs en simultané avec un réel gain.

Il me semble donc, que même si votre trésorerie était illimité, vous ne pourriez vous passer d'un pool de connexions. Qu'il soit géré par pgpool, pgbouncer ou même par Tomcat...

Librement,
Stéphane Schildknecht
Dalibo
PostgreSQLFr

Clients Lourds

ducteil/ = 20 Septembre, 2008 - 16:37

Bonjour

Vos réponses ont vraiment éclairé ma lanterne.

Nous gérons des sites sécurisés où nous avons des milliers de clients que se connectent sur une base analogue ; nous n’avons jamais rencontré de problèmes de perte puissance ou de gains, les requêtes relativement lourdes sont dans des transactions : nous n’avons pas eu à utiliser pas de connexions permanentes (PHP is magic !).
Par contre, nous sommes, dans le cas qui m’intéresse, dans un système de clients lourds pour notre application métier, et voudrions faire le meilleur choix pour notre prochain serveur SQL.
Le plus agaçant dans cette histoire est que
+ les sessions de connexions sont relativement courtes : la réplication dure moins d’une minute
+ nous sommes sur une base de moins de 4 Go (8 avec les indexes)
+ mais nous pouvons dépasser 150 connexions simultanées.

Si l’on part comme principe, qu’il nous faille un pool de connexion, et que nous voudrions être prêt pour les 500 connexions simultanées, sur quelles ressources (CPU, RAM, OS) devrais-je porter toute mon attention ?

Merci d’avance !

Cordialement
Olivier