Discussion :

[Aizen64]

Bonjour,

j'ai lu quelques infos sur le sujet et pourtant j'ai bien du mal à trouver une réponse claire à ma question, est-ce potentellement délicat pour un serveur dédié aujourd'hui de gérér des dizaines de milliers d'utilisateurs avec du SELECT ? Prenons un exemple, un site acceulllant 50 000 utilisateurs.

Bien sur, tout dépend des ressources du serveur, j'ai juste tendance à penser que vu la puissance de calcul actuelle, faire ce type d'opération n'est pas si compliqué.

Quelqu'un a des infos claires sur le sujet à partager ?

[Arkhena]

Bonjour,

"50 000 utilisateurs qui font du SELECT", ça ne veut malheureusement pas dire grand chose (même si je suis bien consciente que vous avez galéré pour obtenir ne serait-ce que cette information).
Ce qui est important, c'est
- le nombre d'utilisateurs simultanés (en moyenne et en pointe)
- le temps de réponse moyen des SELECT effectués
- s'il y a des écritures en même temps qui risquent de poser des verrous sur les données lues
- le dimensionnement de la machine (ou des machines en cas de load balancing sur des Hot Standbys)

En gros, le nombre de connexions simultanées maximum est lié au paramètre max_connections (https://www.postgresql.org/docs/9.6/...onnection.html) qu'on peut setter différemment en fonction du matériel qu'on a.

Cordialement,

Arkhena

[SQLpro]

Pour information, en pratique, PostGreSQL a du mal à supporter plusieurs centaines d'utilisateurs simultanés, et dans ce cas, même en lui rajoutant un "pooler" de connexion comme PGpool.

Les gros SGBDR commerciaux supportent en pratique plusieurs dizaines de milliers de connexions simultanées, car il utilisent un pooler interne mais il faut que le serveur soit bien dimensionné. Par exemple sur le serveur d'Eurydile (registre du commerce) nous avions des pointes à plus de 30 000 connexions simultanées sur un serveur à 64 cœurs hyperthreadé (donc 128 vcore). Mais c'est du MS SQL Server !

A +

[alassanediakite]

Pour information, en pratique, PostGreSQL a du mal à supporter plusieurs centaines d'utilisateurs simultanés, et dans ce cas, même en lui rajoutant un "pooler" de connexion comme PGpool...

Encore de la désinformation gratuite. Et encore une confirmation de ce que vaut l'homme et de ce qu'il dit.

[NULL008]

@sqlpro vous été payé de microsoft pour faire ces types de publicités ?

[Arkhena]

Pour information, en pratique, PostGreSQL a du mal à supporter plusieurs centaines d'utilisateurs simultanés, et dans ce cas, même en lui rajoutant un "pooler" de connexion comme PGpool.

Bonjour SQLPro,

Je ne demande qu'à vous croire, mais je suis comme Saint Thomas... Pouvez-vous m'expliquer ce qui vous fait penser cela ?

Cordialement,

Arkhena

[SQLpro]

Un exemple simple... Demandez vous pourquoi "le bon coin" utilise plus de 100 serveurs postGreSQL en // pour leur service d'annonce là ou d'autres sites beaucoup plus lourds (fnac.com, cdiscount, ventresprivées...) n'en utilise qu'un seule et en plus avec gestion de transactions financières (panier, commandes, factures, BL, etc...) ?

Citez moi une seule application documentée avec plusieurs milliers d'utilisateurs en transactionnel sous PostGreSQL et sur un seul serveur et je ferais mon mea culpa !

A +

[gorgonite]

Un exemple simple... Demandez vous pourquoi "le bon coin" utilise plus de 100 serveurs postGreSQL en // pour leur service d'annonce là ou d'autres sites beaucoup plus lourds (fnac.com, cdiscount, ventresprivées...) n'en utilise qu'un seule et en plus avec gestion de transactions financières (panier, commandes, factures, BL, etc...) ?

Donc "le bon coin" perdrait volontairement plusieurs milliers d'euros par an en infrastructure juste pour éviter un SGBDR commercial... tout en restant gratuit pour pas mal de particuliers. Sont-ils subventionnés par de généreux mécènes anti-SQL server ?
Est-ce vraiment la seule raison ? Ont-ils une autre contrainte qui ne serait pas supportée par un seul serveur avec SGBDR commercial ?

Cela semble assez peu plausible, pour des raisons purement idéologiques, non ?

[alassanediakite]

Un exemple simple... Demandez vous pourquoi "le bon coin" utilise plus de 100 serveurs postGreSQL en // pour leur service d'annonce là ou d'autres sites beaucoup plus lourds (fnac.com, cdiscount, ventresprivées...) n'en utilise qu'un seule et en plus avec gestion de transactions financières (panier, commandes, factures, BL, etc...) ?

Citez moi une seule application documentée avec plusieurs milliers d'utilisateurs en transactionnel sous PostGreSQL et sur un seul serveur et je ferais mon mea culpa !

A +

Faisons l'inverse...
Donne-nous l'aveu officiel de "le bon coin" sur ce choix, on fera le mea-culpa.
@+

[skuatamad]

- s'il y a des écritures en même temps qui risquent de poser des verrous sur les données lues

Non, les SELECT ne sont pas bloqués par les écritures concurrentes.

Table-level Lock Modes

ACCESS EXCLUSIVE

Conflicts with locks of all modes (ACCESS SHARE, ROW SHARE, ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, and ACCESS EXCLUSIVE). This mode guarantees that the holder is the only transaction accessing the table in any way.

Acquired by the ALTER TABLE, DROP TABLE, TRUNCATE, REINDEX, CLUSTER, and VACUUM FULL commands. This is also the default lock mode for LOCK TABLE statements that do not specify a mode explicitly.

Tip: Only an ACCESS EXCLUSIVE lock blocks a SELECT (without FOR UPDATE/SHARE) statement.

[SQLpro]

Non, les SELECT ne sont pas bloqués par les écritures concurrentes.

Tout dépend du mode de verrouillage...
Par défaut dans PostGreSQL, le mode de verrouillage est le mode optimiste qui se traduit par un versionnement de lignes et donc ne bloque pas les écritures, sauf dans le cas de la lecture des métadonnées.

Dans certaines bases, c'est le mode pessimiste par défaut (Access, Sybase, MS SQL Server). Donc une lecture bloque les écritures.

Certaines bases permettent les deux, il suffit de les paramétrer correctement. C'est le cas de SQL Server.

Mode optimiste...

• Avantage : pas de blocage des écritures par les lectures
• Inconvénient : perte possible de mise à jour, volumétrie accrue due à la génération des versions de ligne, augmentation de la durée des traitements du fait de la génération des copies pour les versions

Mode pessimiste...

• Avantage : une fois engagée, la mise à jour sera effectuée, durée transactionnelle moindre, volumétrie stable
• Inconvénient : blocage des écritures par les lectures

Le mieux étant évidemment de pouvoir jouer sur les deux, ce que PG ne sait pas faire.... Et la gestion des copies de lignes est assez mal faite dans PG (VACUUM...)

A +