Tentative de mini-bench comparant MySQL et SQL Server - SQL/NoSQL - Programmation
Marsh Posté le 27-07-2005 à 01:35:13
Script de test :
Supprimé en attendant la version finale du nouveau bench
Marsh Posté le 27-07-2005 à 01:35:42
Le fichier my.cnf
Code :
|
Je posterai demain dans la soirée un script de génération de la base et des données testées. Là je suis trop naze pour faire ça.
Marsh Posté le 27-07-2005 à 01:51:54
Autre point avant de me coucher...
La requête SELECT exécutée une seule fois était plus rapide avec SQL Server qu'avec MySQL. Le résultat me semble donc assez étrange. Il semblerait que MySQL conserve en cache l'intégralité du jeu de requête, et n'a donc effectué qu'une seule fois la requête alors que SQL Server l'a réellement exécutée.
Le test pourrait donc être refait soit en trouvant un moyen de forcer MySQL à refaire la requête, soit en permettant à SQL Server de ne pas la refaire, histoire de les tester dans les mêmes conditions.
Marsh Posté le 27-07-2005 à 07:22:42
C'est tout à fait ça. Pour les conditions, à mon sens ça revient à obliger mysql à se battre avec une main attachée dans le dos mais pour désactiver son cache, c'est facile:
query_cache_size = 0
Pour ce qui est de la transaction, j'ai été lire vite fait le code du driver odbc, et c'est supporté (enfin, pas si on fait un rollback sur un ensemble de connexions mais ce n'est pas le cas ici). Pas le temps d'investiguer plus que ça.
Marsh Posté le 27-07-2005 à 08:26:12
De toute façon, en effet, le problème de la transaction se produit aussi lorsque je suis directement connecté à la base via l'outils "mysql".
J'en déduis que j'ai dû me planter quelquepart dans ma config.
PS: la raison vient peut-être du fait que lorsque j'ai tranféré les données, SQL Server a créé les tables dans MySQL avec le format MyIsam, qui est celui par défaut.
Ce n'est qu'une fois les tables remplies que j'ai changé le format. Peut-être faut-il faire une action supplémentaire.
Marsh Posté le 27-07-2005 à 09:33:00
Je l'avais fait un coup en ligne de commande, et ça n'avait rien changé.
Au fait, lorsque j'ai fais mes transactions, il m'a toujours dit "1 warning", mais sans l'afficher, je fais comment pour l'afficher, ça me donnera certainement une piste pour résoudre ce problème.
Sinon, pour en revenir au problème de cache, je suis pas tout à fait d'accord avec ta réaction DocMaboul, par contre, je tiens a éviter de faire le teste en pénalisant volontairement MySQL.
Je vais voir si je peux trouver un paramètre permettant à SQL Server de se comporter comme MySQL plutôt, et si je ne trouve pas, je vais faire un bench qui sera bien plus long, mais aussi plus représentatif d'une base de données d'un gros SI.
Sur un ERP par exemple, alors qu'un bon millier de personnes travaillent dans la même base, un grand nombre font évidement les mêmes requêtes.
Cependant, vu l'étendue fonctionnel et la complexité des traîtements effectués par un ERP, on sait aussi qu'un même utilisateur, avant de refaire une deuxième fois la même requête, va en faire pas loin d'une vingtaine différentes.
Et sur le millier d'utilisateurs, seule une vingtaine à chaque fois vont faire des traîtements similaires, le SI gérant à la fois les tarifs, les commandes, les stocks, la compta, les CRM, etc., le nombre de requêtes différentes exécutées dans un laps de temps assez court est assez phénoménal. Difficile donc de conserver en cache toutes les requêtes, d'autant plus qu'il est rare que deux personnes demandent exactement la même chose. Je pense d'ailleurs que SQL Server étant principalement prévu pour ce type de base, c'est une raison pour laquelle il réeffectue les requêtes qu'il vient de faire : en production, ça n'arrive grossomodo jamais.
Hors, c'est justement ce cas que je veux tester, car c'est en comparant MySQL sur le terrain de SQL Server et Oracle, et non l'inverse, qu'on peut, selon moi, avoir une réponse claire quant à la capacité de MySQL à rivaliser avec ces deux derniers.
Donc je pense que ce soir, je vais tenter de me faire une autre base, plus représentative d'un ERP (si vous avez des script de créations de base/données d'une base type "catalogue produit, commande, stocks, compta, etc.", je suis totalement preneur, parceque ça va me prendre des heures à monter une base comme ça, et elle risque de ne pas être significative.
Sinon, je prochain bench sera plutôt orienté vers :
-> Au moins une dizaine de requêtes différentes, éxécutées dans un ordre aléatoire une série de fois, avec des paramètres différents à chaque fois.
-> Je vais aussi essayer de voir si je peux lancer plusieurs instances du même bench en //, histoire de simuler au moins 4 ou 5 connections concurrentes. En effet, tester un SGBD en environnement mono-utilisateur, c'est pas très représentatif...
Par contre, je tiens à faire des tests avec des transactions, ça me semble très important comme point à tester (notamment la façon de gérer les transactions concurrentes sur un même ensemble de données)
Marsh Posté le 27-07-2005 à 19:22:14
Je réitère ma demande : afin de faire un bench plus représentatif de la réalité, je cherche un exemple de base de données (si possible, scripts de création plus données) relativement volumineuse, et représentant une utilisation courrante :
- Catalogue / commandes
- Gestion de stocks
- CRM
- Etc.
Le summum serait une base avec un peu de tout, histoire par exemple de faire le lien entre une demande CRM et une commande, afin de consulter les réapprovisionnements des stocks des produits en relica (chose très courrante dans les centres d'appel, et qui demande souvent des requêtes relativement complexes.)
Marsh Posté le 27-07-2005 à 19:23:13
Je pourrais tenter d'en créer une via un script qui allimente la base de façon aléatoire, mais des données cohérentes c'est quand même mieu.
Marsh Posté le 27-07-2005 à 19:38:15
Arjuna a écrit : Je pourrais tenter d'en créer une via un script qui allimente la base de façon aléatoire, mais des données cohérentes c'est quand même mieu. |
Ca risque d'être difficile : en général, les données réelles sont protégées.
Marsh Posté le 27-07-2005 à 20:26:27
C'est sûr. Mais disons par exemple qu'avec SQL Server, il y plusieurs bases de test livrées en exemple, sur lesquelles s'appuient l'aide.
Seul hic, c'est qu'elle ne sont à la fois pas assez volumineuses (une base de bouquin, et une base de gestion RH), mais surtout, après le problèmes que j'ai eu hier avec la transformation des données de SQL Server vers MySQL, je préferarais partir d'un fichier SQL, ou d'une base MySQL. Dans ce sens ça marchera peut-être mieu.
Enfin bref, je suppose que Microsoft n'est pas le seul a fournir des données de test/formation avec leurs produits...
Marsh Posté le 27-07-2005 à 20:27:25
Parceque sinon, j'ai bien accès à des bases de mes clients mais bon, s'en servir pour faire un bench, c'est mal, c'est tout protégé en effet.
Marsh Posté le 27-07-2005 à 20:46:13
Arjuna a écrit : Parceque sinon, j'ai bien accès à des bases de mes clients mais bon, s'en servir pour faire un bench, c'est mal, c'est tout protégé en effet. |
Disons que ça limite fortement la publicité de tes résultats, ou à tout le moins leur reproduction par autrui.
Tu sais, quand un de mes collègues devait faire des benchs sur des datawarehouse, il se tapait des données bidons via des scripts. T'as pas toujours un tera de données sous la main.
Ca reste malgré tout plus précis quant à la quantité de données à injecter, même si c'est moins réaliste.
Tu peux aussi plus facilement paramétrer tes tests : des champs plus ou moins longs, avec plus ou moins de variance dans la longueur des données, plus ou moins de records...
Il se peut que les perf s'inversent ou que les écarts se creusent en augmentant/diminuant un volume.
Bref, un snapshot de DB, pour "réaliste" que ce soit, c'est aussi fort limité.
Marsh Posté le 28-07-2005 à 00:45:41
Bon, j'ai pas attendu cette réponse pour commencer
Je suis en train d'allimenter ma base SQL Server avec des données bidons.
En fait, j'ai carrément décidé de réécrire un mini-erp, car ce qu'il faut bencher, ce n'est pas seulement le process de passage d'une commande, mais aussi tout ce qui est réapprovisionnement des stocks et tout ça, qui se font par batch la nuit, et par expérience, je sais qu'une nuit c'est court (la preuve, il est déjà presque 1h du matin, et j'ai toujours pas fini de débugger l'allimentation des tables...)
Marsh Posté le 28-07-2005 à 00:48:38
si tu codais pas en asp aussi, le debug irait plus vite... :-D
bon j'arrête de charier...
Marsh Posté le 28-07-2005 à 00:55:40
T'ain, quand ça veut pas, ça veut pas
Pis là j'en suis vers la fin du script évidement... quand il faut régénérer des mégas de données avant d'y arriver
Marsh Posté le 28-07-2005 à 00:56:44
C'est pas de l'ASP, c'est du VBScript
Pis c'est tout ce que j'ai sous la main
En tout cas, je ne sais pas par quoi je suis limité, parceque le script prend seulement 25% des ressources quand il tourne, du coup il pourrait aller plus vite ce con
Marsh Posté le 28-07-2005 à 00:59:05
Voilà la liste des tables en attendant :
Code :
|
Il reste la gestion des claims CRM, mais je ne sais pas si je vais les stocker. Je vais plutôt faire les traîtements "en live" (c'est à dire que c'est au moment des "batchs de nuit" que je vais décider si un client mécontent a appelé et si je dois envoyer un produit de substitution, ou le rembourser...)
Marsh Posté le 28-07-2005 à 01:10:57
VBScript ????? des gens compétents bossent avec ce truc ???
bon je vais pas troller dans chacun de mes posts mais la c'est gros ! :-D
Marsh Posté le 28-07-2005 à 01:16:22
Mon Dieu que c'est chiant... Ca a planté sur l'avant-dernière table
Marsh Posté le 28-07-2005 à 01:17:29
C'est bien plus puissant qu'il n'y paraît, et surtout, t'as besoin de rien d'autre que Notepad pour en faire. Vu que je suis sur un serveur, je vais pas m'amuser à installer Visual Studio ou autre connerie pour coder dans un autre langage...
Marsh Posté le 28-07-2005 à 01:22:31
T'ain, chuis fatigué moi... Ca fait trois fois que je corrige (mal) le même bug
Marsh Posté le 28-07-2005 à 01:57:28
tiens c'est marrant, le langage à la mode là, le php, et ben pareil : faut qu'un éditeur de texte ! :-)
sauf que là avec rien qu'un éditeur, tu as accès à une puissante phénoménale..
par exemple, je cherchais une fonction miracle, je pensais pas qu'elle était built-in, et ben si : http://fr.php.net/manual/en/functi [...] ursive.php
j'adore !
Marsh Posté le 28-07-2005 à 02:02:02
un éditeur de texte plus un interpréteur... VBS, l'interpréteur est intégré à l'OS...
sinon, franchement, quitter le VBScript au profit du PHP, non merci, je ne vois pas trop l'intérêt...
Sinon, ça m'a l'air bien parti, j'ai plus de nom de champ foireux, plus d'ID doublé, plus de FK voilée, c'est la fête !
Sauf que là j'ai pas envie d'attendre la fin du script pour attendre de voir ce que fait la dernière table... là il est parti en tout cas, y'en a pour un moment maintenant !
Marsh Posté le 28-07-2005 à 02:37:32
Arjuna a écrit : Je réitère ma demande : afin de faire un bench plus représentatif de la réalité, je cherche un exemple de base de données (si possible, scripts de création plus données) relativement volumineuse, et représentant une utilisation courrante : |
en cherchant un peu sur www.tpc.org, vous devriez trouver votre bonheur. Typiquement, en lisant bien ce doc, vous trouverez tout ce qu'il vous faut pour faire péter votre serveur: http://www.tpc.org/results/FDR/TPC [...] 64_fdr.pdf (par contre, ils utilisent du C et du bulk-copy à ce niveau (pour bourrer une archi à 5M de dollars, faut bien ça )
Marsh Posté le 28-07-2005 à 09:28:53
Oh, au fait, quand tu lanceras tes billions de requêtes depuis ton client de tests, fais gaffe à ce que celui-ci ne constitue pas un bottleneck.
C'est pas évident à mesurer et à mettre en évidence et ça fausse sauvagement tes résultats.
Marsh Posté le 28-07-2005 à 09:44:40
Ben vu que ce sera le même soft pour les deux benchs, au pire, ça permettra de mesurer aussi l'impact de la connection ODBC.
Mais sinon, je suis confiant : autant le VBS n'est pas un langage rapide, autant les requêtes seront très certainement plus lentes que le script, sans parler du fait que lent ou rapide, le VBS n'occupe jamais 100% du CPU, donc pour ce qui est de l'éxécution elle-même, elle n'impactera pas les temps de traîtement d'un SGBD à l'autre.
Marsh Posté le 28-07-2005 à 09:56:17
Je suis un jour parti de ce genre de supposition... et ça c'est avéré faux.
Ce que je peux te conseiller, c'est d'avoir plusieurs postes clients pour commencer. Tu peux te fixer p.e. 8 requêtes simultanées sur le serveur. Compare :
- 4 postes x 2 requêtes (tous ensemble bien sûr) à
- 1 poste x 8 requêtes simultanées.
Ou 2x4... Ca peut te donner une idée. Dans le cas qui me revient, le bottleneck client apparaissait àpd 5 threads seulement.
En matière de benchmarks, les bottlenecks et les améliorations ne sont pas toujours là où on le bon sens nous mène.
Marsh Posté le 28-07-2005 à 11:17:40
Je suis en train de pourrir ma machine au boulot en continuant a faire ça...
Je viens de finir le script de passage de commandes...
Ben ça ramme pas mal sur mon PC de merde
Pii@300 MHz / 128 Mo RAM / DD tout pourri / NT4
Marsh Posté le 28-07-2005 à 11:26:08
sircam a écrit : Je suis un jour parti de ce genre de supposition... et ça c'est avéré faux. |
Le seul souci, c'est pour le test que je suis en train de mettre au point, je ne peux pas faire de requêtes concurrentes, ou sinon je vais être obligé de séparer mes benchs en "lots" étallés de le temps.
En fait, le principe est le suivant :
Pour un nombre "X" de jours, "Y" clients passent des commandes.
Ensuite, je fais les traîtements de vérification des stocks, et lance des commandes fournisseurs selon les dépôts aux endroits où les commandes on été passées.
A réception des colis, j'affecte les produits en stock aux commandes relicats.
Si passé un délais, aucun colis n'est encore arrivé, je procède à un mouvement inter-dépôts, en vérifiant que le coût n'est pas trop important, et que je ne met pas en pénurie le dépôt source.
Si une commande est en relicat depuis plus de "Z" jours, alors j'ai une chance sur deux que le client logue un appel.
Je dois lui annoncer un délais d'attente, qui va impacter sa décision "oui ok j'attends encore un peu" ou "nan vous faites chier".
Dans ce cas, je cherche un produit de remplacement en stock, et sinon, je procède à au remboursement.
Enfin, je calcule les primes des commerciaux basées sur les bénéfices moyens de chaque commande.
Et pour terminer, je mets à jour la balance en banque pour chaque dépôt.
En fait, on peut dire que je reproduis le fonctionnement général d'une chaîne de franchises de magasin (où le dépôt est le magasin), qui ne disposerait pas d'un stock central.
Y'a du boulot. En tout cas, quand j'aurai terminé, je pourrai me venté d'avoir fait le premier ERP "complet" totalement en VBScript
Marsh Posté le 28-07-2005 à 11:29:22
Oui, pour en revenir aux requêtes concommitantes, le problème, c'est ma notion de temps (pour gérer les claims et les réapprovisionnement).
Ici, je gère un entier qui s'incrémente pour chaque jour.
Mais si je sérialise mes requêtes, ça ne marchera plus, et je vais me retrouver avec mon "batch de nuit" qui fait n'importe quoi.
Ou alors, il faudrait que le log la date, et que j'interprète chaque 5 minutes comme un jour, et que je schedule mon "batch de nuit" toutes les 5 minutes... Mais à ce moment, on n'aura plus de chiffres sur "le temps nécessaire", mais "le nombre de lignes mises à jour en X heures".
Marsh Posté le 28-07-2005 à 12:39:30
Bon, les jolies petites requêtes commencent
Calcul de la quantité des produits à commander par fournisseur
Code :
|
Je confirme donc, c'est bien le "batch de nuit" qui va se taper toutes les requêtes qui auront une véritable valeur pour les benchs
Marsh Posté le 28-07-2005 à 16:37:10
Finalement, pour la gestion des stocks, ça sera :
Code :
|
Heuresement que MySQL sait faire des sous-requêtes, parceque sinon c'était pas gagné
Marsh Posté le 28-07-2005 à 22:12:06
tu ne fais pas tes jointures avec les clauses JOIN, etc. ? mais avec le classique WHERE a.id = b.id
Est ce pour des raisons historiques, esthétiques, performances ?
Marsh Posté le 29-07-2005 à 00:25:57
Pour plusieurs raisons en fait
- Pratique : je hais tout bonnement les jointures avec la clause "join", j'y panne jamais rien, je trouve ça illisible
- Esthétique : En plus d'être à mon goût illisible, en cas de jointure "non évidente", le fait d'isoler ce point le plus important de la requête dans la partie la moins importante (généralement, on regarde ce qu'on sélectionne en premier, puis les filtres, pensant que les jointures sont bonnes), on risque de ne pas comprendre la requête
- Logique : le fait de faire une jointure entre deux tables, c'est selon moins simplement filtrer une table selon les lignes d'une autre, c'est donc à mes yeux un filtre comme un autre, et doit être traîté comme tel
- Historique : Même si j'ai vu en cours pendant mes études les jointures avec des "join", j'ai toujours fait (et ce, depuis l'école) avec des "="
- Compatibilité : Tous les SGBD supportent cette syntaxe depuis toujours, alors que la syntaxe SQL92, avec les "join", n'est pas toujours supporté (sur les versions pas trop vieilles d'Oracle, ça ne marchait toujours pas)
Point de vue performance, les optimiseurs de toutes les bases savent interpréter les jointures dans la clause where de la même façon que si elles étaient explicites, ainsi, il n'y a pas de différence.
Je trouve notamment la syntaxe avec "join" dangereuse lorsque le critère de jointure n'est pas un "=" mais un "!=" ou ">=" par exemple, dans ce cas, c'est vraiment plus un filtre qu'une jointure, hors ça ne saute pas du tout aux yeux.
Marsh Posté le 29-07-2005 à 00:33:36
Sinon, ça y est, le script du bench est presque terminé.
Il me reste à rajouter une fonctionnalité que j'ai complètement zappé (c'est ça de couvrir un périmètre fonctionnel trop grand d'un coup ), et débugger.
Je vais commencer par ce dernier point d'ailleurs
PS: sinon, mise à part demain où je devrais avoir un peu de temps dans la journée, je ne pourrai re-travailler dessus qu'à partir de lundi soir. Par conséquent, pensez-bien à faire remonter le topic histoire que je me motive pour terminer
Je colle ici l'intégralité de mon travail, histoire de pouvoir continuer à bosser demain.
Dans le script "bench.vbs", je vous invite à rechercher les requêtes contenant des jointures externes à la SQL Server "=*" et me proposer leur réécriture avec des jointures de type "join".
En effet, cette syntaxe n'est pas supportée par MySQL, donc ça va pas aller pour faire le bench
Il ne faut pas se contenter de faire seulement ces jointures avec cette syntaxe, mais réécrire toute la requête avec des "join". En effet, SQL Server doit utiliser deux parseurs/optimiseurs différents selon les syntaxes, et par conséquent on ne peux pas mélanger les deux types de jointures.
Marsh Posté le 29-07-2005 à 00:37:15
Script de la base de données :
Code :
|
Script d'initialisation des données de la base :
Code :
|
Script du bench :
Code :
|
Petit script SQL de contrôle/nettoyage de la base (listing de toutes les tables, et lots de reminse à 0 des données des deux scripts) :
Code :
|
Marsh Posté le 29-07-2005 à 00:46:22
J'ai fait un peu de nettoyage dans le topic, il commençait à y avoir trop de versions non à jour de bouts de code
Marsh Posté le 29-07-2005 à 01:16:00
Je ne souhaite pas troller (loin de moi cette idée), mais qu'est ce que c'est moche le VBscript!!! hallucinant.
Tu sais arjuna ya un driver sql server pour php
Marsh Posté le 27-07-2005 à 01:34:16
ATTENTION:
Je suis actuellement en train de réécrire de A à Z un nouveau bench bien plus complexe, et qui tente de répondre des critères d'utilisation plus classiques d'une base de données.
Les résultats de ce test sont donc à prendre avec parcimonie, et ne permettent très certainement pas de faire de réelles conclusions (test trop imparfait, et trop limité).
Voilà, je viens de passer ma soirée à le faire.
Je suis totalement ouvert pour apporter d'autres éléments de tests (probants si possible, pas des trucs où on sait que MySQL éclate tous les autres SGBD, car ils sont rarement représentatifs)
Voici le test :
Alors, vu qu'on n'arrive pas à se mettre d'accord sur les capacités de MySQL, j'ai décidé de faire un petit bench moi-même.
J'ai déjà une base sur SQL Server, écrite à l'origine pour faire un petit jeu en ligne.
Le projet est plus ou moins à l'abandon faute de temps, mais la base de données, en partie remplie, constitue une bonne base pour faire quelques tests de montée en charge.
Je tiens à préciser deux choses :
- La base sur SQL Server étant totalement en cours de développement, je n'ai pas eu le temps de faire le moindre tuning de performance.
- J'ai repris les mêmes index, même structure (type, etc.) pour faire mes tests.
- Je n'ai pas trouvé de drivers officiels OLEDB pour MySQL, donc tous les tests sont donc effectués avec des drivers ODBC (MySQL tout comme SQL Server)
- Versions testées :
MySQL Database 4.1.13 (version "Generally Available" sur le site http://dev.mysql.com/ au 26/07/2005)
Microsoft SQL Server 2000 - 8.00.2039 (Intel X86) May 3 2005 23:18:38 Copyright (c) 1988-2003 Microsoft Corporation Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 1)
Plateforme de test
------------------
Configuration système :
CPU : 2xPiii 933 MHz EB
MB : Asus CUV4X-DLS (Chipset Via 694XDP)
CG : ATI Radon All-In-Wonder 7200
RAM : 2 Go SD-RAM PC133
HD1 : 18.6 Go U3W IBM
HD2 : 18.6 Go U3W IBM
HD3 : 18.6 Go U3W IBM
HD4 : 18.6 Go U3W IBM
HD5 : 9.1 Go U3W Seagate
HD6 : 9.1 Go U2W Western Digital
Comme vous pouvez le constater, même s'il n'est plus de première jeunesse, il s'agit d'une configuration serveur, et non d'une machine de gamer.
La grande quantité de mémoire, l'architecture SMP et les disques interfacés en SCSI garantissent un environnement adapté pour une base de données.
Configuration logicièle :
Windows 2003 Server SP1
Aucun autre produit mise à part FireFox et le service IIS, qui n'est pas solicité durant le test (site offline)
A nouveau, la configuration est la même que celle d'un serveur dédié.
Configuration des disques :
C: (9 Go U2W NTFS) : Système (Windows + SWAP)
D: (9 Go U2W NTFS) : Données systèmes (binaires de SQL Server et MySQL)
E: (18 Go U3W NTFS) : Fichiers de données des SGBD
F: (18 Go U3W NTFS) : Fichiers du journal des transactions des SGBD
G: (18 Go U3W NTFS) : Fichiers d'index des SGBD
H: (18 Go U3W NTFS) : Fichiers de IIS (non utilisés pour le bench)
Installation
------------
N'ayant pas refait l'installation de SQL Server qui date de quelques mois, je ne vous détaille pas écran par écran la procédure.
Installez n'importe quel produit Microsoft pour avoir un apperçu, on est guidé écran par écran.
A noter que j'ai configuré SQL Server en mode sécurité élevé (droits explicites sur tous les objets, et mots de passe de plus de 50 caractères). Je ne sais pas si ça influe sur les résultats, je mentionne juste.
Réutilisation du fichier "my-huge.ini" pour le "my.cnf" avec les modifications suivantes :
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 4
(passé de 8 à 4 comme préconisé)
Ajout de la ligne :
datadir=e:/mysqldata
(séparation des données du binaire d'un point de vue physique)
Ajout de la ligne :
innodb_log_group_home_dir=f:/mysqllog
(séparation des logs du binaire et des données d'un point de vue physique)
Ajout de la ligne :
basedir=d:/mysql-4.1.13-win32
Histoire de lui dire où il est
A noter que je n'ai pas trouvé d'option permettant de séparer les index des données.
Premier lancement :
D:\mysql-4.1.13-win32\bin>mysqld-max-nt --console
InnoDB: The first specified data file .\ibdata1 did not exist:
InnoDB: a new database to be created!
050726 21:45:29 InnoDB: Setting file .\ibdata1 size to 10 MB
InnoDB: Database physically writes the file full: wait...
050726 21:45:29 InnoDB: Log file f:\mysqllog\ib_logfile0 did not exist: new to be created
InnoDB: Setting log file f:\mysqllog\ib_logfile0 size to 5 MB
InnoDB: Database physically writes the file full: wait...
050726 21:45:29 InnoDB: Log file f:\mysqllog\ib_logfile1 did not exist: new to be created
InnoDB: Setting log file f:\mysqllog\ib_logfile1 size to 5 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Doublewrite buffer not found: creating new
InnoDB: Doublewrite buffer created
InnoDB: Creating foreign key constraint system tables
InnoDB: Foreign key constraint system tables created
050726 21:45:32 InnoDB: Started; log sequence number 0 0
mysqld-max-nt: ready for connections.
Version: '4.1.13-nt-max-log' socket: '' port: 3306 Official MySQL binary
Ca semble correspondre à ce qui est dans la doc, j'en déduis que je ne me suis pas planté.
Installation en tant que service :
D:\mysql-4.1.13-win32\bin>mysqld-max-nt --install
Service successfully installed.
Premier test :
D:\mysql-4.1.13-win32\bin>net start "mysql"
Le service MySQL a démarré.
D:\mysql-4.1.13-win32\bin>mysql
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 4.1.13-nt-max-log
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql>
Alimentation de la base MySQL à partir de SQL Server.
=> "Exporter des données", choix de ma base SQL Server, choix d'un DSN vers une base vide de MySQL, sélection de toutes les tables "suivant" et zou ! Roule ma poule.
Après maintes tentatives et un destroyage total de ma base sql server, j'ai renoncé à copier les tables contenant des champs texte.
En soit ce n'est pas très grave, ce n'était que des tables de référence.
Après avoir installé un outils d'administration pour MySQL, j'ai passé les tables en InnoDB (par défaut MyIsam).
Avant le bench
--------------
Copie des index de SQL Server sur MySQL.
Une chose étonnante que j'ai pu constater avec MySQL, c'est que pour une table relativement volumineuse (10800 lignes), la création d'un index unique est... lente :
mysql> CREATE UNIQUE INDEX PK_Terrain ON Terrain (idSolarSystem, idPlanet, xTerrain, yTerrain);
Query OK, 10800 rows affected (1 min 46.47 sec)
Records: 10800 Duplicates: 0 Warnings: 0
Sous SQL Server, le même index fût créé en moins d'une dizaine de secondes.
Ceci dit, cela ne doit pas intervenir dans les résultats du bench, étant donné que la création d'un index fait partie de la maintenance, et n'impacte donc en rien la rapidité d'une application utilisant la base.
Résultat du bench
-----------------
SQL Server :
Démarrage du bench à 27/07/2005 00:50:05
Création de 10 connections
=> 0,16
Execution de 10 requêtes relativement simples sur chacune des 100 connections
=> 5,91
Execution de 10 requêtes
=> 76,55
Clôture des 100 connections
=> 0,02
Durée totale du bench : 82,63
Fin du bench à 27/07/2005 00:51:27
MySQL :
Démarrage du bench à 27/07/2005 01:00:09
Création de 10 connections
=> 0,09
Execution de 10 requêtes relativement simples sur chacune des 100 connections
=> 0,95
Execution de 10 requêtes
=> 837,8
Clôture des 100 connections
=> 0,02
Durée totale du bench : 838,86
Fin du bench à 27/07/2005 01:14:08
IMPORTANT !
Alors que la transaction a bien été prise en compte sous SQL Server, MySQL m'a laissé comme un goret les données mises à jour malgré le rollback !
Le test est donc à refaire sans transaction (pour avoir testé "en live" lors de l'écriture de la requête, SQL Server aurait dû êre près de 10 fois plus rapide !
Remarques :
Durant l'exécution du bench sous SQL Server, la mémoire occupée est resté à la valeur fixe de 681 Mo.
Durant l'exécution du bench sous SQL Server, la part de CPU occupée par le noyaux s'élevait environ à 2/3% de charge CPU.
Durant l'ecécution du bench sous SQL Server, le CPU occupé par le bench a toujours été le second, sans jamais de changement.
Durant l'exécution du bench sous MySQL, la mémoire occupée est restée longtemps à 681 Mo avant de faire un légère pointe à 687 Mo (pis c'est resté à ce niveau jusqu'à la fin.
Durant l'écécution du bench sous MySQL, la part de CPU occupée par le noyau s'élevait environ à 25%.
Durant l'exécution du bench sous MySQL, à une ou deux reprises, la charge est passée du CPU2 au CPU1 puis est revenur sur le CPU2.
Durant l'exécution des deux benchs, la charge CPU globale s'élevait exactement à 51% (1 processur alloué pour le bench, et 1 processur alloué pour le système).
Durant l'exécution des deux benchs, aucune activité disque intensive n'était à noter.
Conclusions :
MySQL est significativement plus rapide en ce qui concerne l'ouverture de connections. En effet, il est presque deux fois plus rapide.*
En ce qui concerne les select "relativement simple", MySQL affiche encore un résultat assez extraordinaire. Cela mérite d'être creusé avec des requête vraiment complexes afin de voir si le moteur de SQL Server tire vraiment profit des cas complexes ou non.
Pour ce qui est de la gestion des transactions, là, je sors un carton rouge à MySQL. Les tests sont complètement baisés à cause de ça. Les tables sont pourtant en InnoDB et j'ai bien explicité une transaction. En refaisant le test "à la main" directement dans l'analyseur de requêtes de MySQL, même constat, la transaction n'est pas effective !
Je remets ça sur mon inexpérience de MySQL (c'est la première fois qu'il reste aussi longtemps sur un de mes PC). A creuser, je suis ouvert aux suggestions afin de corriger ce problème et refaire le test dans de bonne conditions.
Par contre, là où SQL Server surpasse très largement (plus de 10 fois plus rapide, en comptant qu'il a géré la transaction !), c'est sur une requête de mise à jour relativement complexe.
J'entends déjà certains s'écrier que c'est la recopie dans "terrain2" qui bouffe tout, et non. Lorsque je la fais à la main, la recopie dans la table dire 0.27 secondes, l'indexaction dure 0.17 secondes (c'est plus rapide de faire une PK qu'un index unique, allez comprendre pourquoi), et le drop 0.03 secondes. Donc même en ajoutant le tout et en multipliant par les 10 passages dans la bougle, on ne peut sourtraire que 5 secondes à ce résultat catastrophique.
*: A noter que l'absence de transaction pourrait se traduire aussi par une absence de cette couche dans l'objet ODBC. Sans compter les bugs que j'ai eu lors de la réplication, montrant que ce drivers ne supporte pas la norme correctement. On peut en déduire qu'il est bien plus léger que celui de SQL Server qui supporte toute la norme ODBC. Je ne cherche pas une fausse excuse, mais ceci me semble être une raison possible de cet écart de performance quand à la connection.
PS: si vous voulez trôler, ouver un autre topic dans lequel je veux bien participer, mais en attendant, je préfère laisser se topic propre en préférant une discussion constructive et une amélioration du test.
Message édité par Arjuna le 29-07-2005 à 00:42:04