La mauvaise foi règne encore chez les aficionados de PostGreSQL… L’entreprise Red Hat, que je croyais sérieuse, à effectué un benchmark entre PostGreSQL et SQL Server stupéfiant de mauvaise foi… Voici mes remarques. À noter, ce comparatif porte sur une version payante de PostGreSQL !

On trouvera le benchmark dont je parle « Comparing BenchmarkSQL Performance on Red Hat® Enterprise Linux 5 to Windows Server Enterprise » à l’URL :
https://www.redhat.com/pdf/rhel/bmsql-postgres-sqlsrvr-v1.0-1.pdf

Passons sur le choix du benchmark : le TPC-C qui date de 1992 (soit 23 ans…) est constitué d’une base de données qui comporte 9 tables et dont on peut trouver le détail à l’URL :
http://www.tpc.org/tpc_documents_current_versions/pdf/tpc-c_v5-11.pdf. Qui aujourd’hui utilise en production une base composée au plus de 9 tables ? En revanche il existe un benchmark plus moderne, le TPC-E composé de 33 tables nettement plus réaliste !

TUNING DES OS

À la page 10 dudit benchmark on trouve le paragraphe 3.3.1 (Operating System) qui montre comment à été optimisé Linux.

On y voit clairement que seul l’OS Linux a été optimisé. Quelles optimisations ont été faites pour Windows ? Aucune !

Or il est bien évident qu’une installation standard de Windows pour héberger SQL Server n’est pas optimale sans certains réglages :
Рd̩sactivation des services inutiles (ce qui a ̩t̩ fait pour Linux et pas pour Windows)
– désactivation du système d’économie d’énergie (qui n’existe pas sous Linux.. pas écolo les linuxiens !)
– activation de Turbo Boost
– activation de l’Instant File Initialization pour le service SQL Server
– activation du Lock Page in Memory pour SQL Server
…

TUNING DES SGBDR

À la page 11 figure le paragraphe 3.3.3 (Database) qui montre comment a été optimisé PostGreSQL.

On y voit clairement que seul PostGreSQL a été optimisé. Red Hat revendique même sa tromperie : « …no specific SQL Server tuning was performed » !

Or il est bien évident que plusieurs optimisations sont nécessaires :
– la ventilation du stockage des fichiers de données de la base tempdb (objets temporaires) en autant de fichiers d’égales longueur que de CPU (donc au moins 2);
– le dimensionnement correct des fichiers de la base de données à 40 Go pour les données et 10 Go pour les transactions avec à nouveau au moins 2 fichiers pour les données
– la limitation de la RAM utilisée par SQL Server à au moins 44 Go (max server memory);
– la limitation du parallélisme des requêtes à 4 (du fait que le serveur présente 2 CPU Quad Core et 4 LUN par agrégats RAID) et hausse du seuil de déclenchement à 12 (cost threshold for parallelism);
– le positionnement du paramètre « optimize for ad hoc workloads » à 1 sinon les plans de requête ne sont pas mis en cache !
– l’élévation du délai de report des écritures physique de données (checkpoint), paramètre « recovery interval », à 60 minutes pour coller au paramètre « checkpoint_timeout  » positionné à 1 heure dans PostGreSQL (un délai tout à fait anormal entre nous, car cela pourrait s’avérer dangereux en production…)
…

POSTGRESQL PLUS

Très discrètement, le document montre que la version testée de PostGreSQL n’est pas la version gratuite Open Source, mais la version payante fabriquée par EntrepriseDB et nommée « PostGreSQL PLUS.
Nous n’avons pas pu obtenir le prix d’une telle version directement sur le site d’EntrepriseDB, mais sur un autre document, provenant probablement du gouvernement britannique ce prix apparait être 3 265 £ par CPU (socket), soit environ 4 700 €…
En comparaison, SQL Server 2008 R2 version Web, suffisante pour ce benchmark, coute 4 246,41…

LES RÉSULTATS

Comme on s’y attendait, avec un tel paramétrage, PostGreSQL bât haut la main SQL Server ! haut la main ? pas si sûr…

Il faut vraiment y aller à la loupe pour voir la différence. En mesurant après impression avec une règle, j’ai constaté un écart relatif de 3 à 5 % mesuré sur les entrées 40 et 140 de l’histogramme…

Bref, il est très probable qu’avec les réglages manquants pour Windows et SQL Server, Red Hat n’aurait jamais publié un tel benchmark tant il aurait été défavorable à PostGreSQL fût-il PLUS !

Ce qui me navre c’est que je croyais naïvement que Red Hat était une entreprise sérieuse !

***

L’entreprise SQL Spot
Le site web sur le SQL et les SGBDR