|
Performance de sgbd
pour le web
20/08/2000 |
Objectif: On cherche
à évaluer, à comparer des languages de scripts sur des SGBD relationnels.
A. IntroductionA.1. ContexteB. Outils de comparaisons
A.2. ConventionB.1. ConfigurationC. Résultats
B.2. Lancement du binaireC.1. Avant-propos des résultats
C.2. A propos de la cpu.
C.3. Archives des résultats de WebStone
C.4. Graphiques
|
A. Introduction |
On présente 4 familles de stress comparatifs : psp/oracle, php/oracle et php/mysql dans l'objectif de les séparer avec un critère de performances. A la première lecture des résultats on peux dire que le couple le plus efficace est php/oracle ensuite php/mysql et enfin psp/oracle. Mais il faut relativiser celui-ci, afin de retirer toutes conclusion trop attives. En effet toutes les machines stressées étaient en exploitation relative. Par exploitation relative on veut signifier que celle-ci recevaient une charge moyenne (entre 5 et 15%) pendant nos stress.
|
A.1.Contexte/Topologie |
Hard : La topologie 3 serveurs sur des OS differents et sur des machines différentes avec des cartes à 10 interconnecté par des switchs Cablotrons.
Soft : Les sgbd testés sont ORACLE 7.3.3,8.1.5,8.1.6 et MYSQL 3.22. Les languages php (hypertext pre-processor) et psp (pl/sql server page).Les plateformes sont Solaris 2.5, 2.6 et Linux Suze 6.4.
Data : Les data sur webserver sont délocalisés par dblink sur triton, ie les data sont sur triton, les psp et php sont basées sur webserver et ceux-ci accèdent au data par dblink. La raison de cette configuration de data délocalisées. On souhaite séparer le serveur de data du serveur d'interrogation pour des raisons essentiellements de sécurités et de stabilités préventives : par exemple webdb ou apache/php plante, le sgbd n'est pas touché.
Objectif : On présente 3 familles de stress comparatifs : psp/oracle, php/oracle et php/mysql dans les séparer avec un critère de performance. En toute objectivité on peux dire que le couple le plus efficace est php/oracle ensuite php/mysql et enfin psp/oracle.
Fig. 1 (20k)
|
A.2 Convention |
Il y aura 4 grandes comparaisons. Psp sur oracle sur webserver vers triton par dblink , php sur oracle sur webserver vers triton par dblink et php sur linux4 vers triton et php sur linux4 vers mysql sur linux4, noté respectivement PSP_ORA_WEBSERVER, PHP_ORA_WEBSERVER, PHP_ORA_LINUX4 et PHP_MYSQL_LINUX4, comme sur la figure 1.
| B. Outils de comparaisons |
Celui utilisé par le support d'audit et de consulting d'Oracle France ie webstone (disponible en source ou pré-compilé) Voir http://www.mindcraft.com/webstone. Nous avons utilisé WebStone 2.5, sur le serveur webserver (solaris2.6)
|
B.1 Configuration |
Le paramétrage de l'outils se réalise par deux fichiers (filelist et testbed) dans le ./conf
filelist
où on
specifie les url à charger aleatoirement sur lesquels on place un poids (le
dernier entier), representant l'importance d'une url par rapport àune autre.
On livre un morceau de notre fichier:
| # Run
15 les psp sur webserver avec
webdb #http://webserver:8888/seprotest/p_nomenclature?v_codent=S0P063330057 1 #http://webserver:8888/seprotest/p_nomenclature?v_codent=S6P063330007 1 #http://webserver:8888/seprotest/p_nomenclature?v_codent=S3P063330020 1 #http://webserver:8888/seprotest/p_nomenclature?v_codent=AM0000854101 1 #run 16 php/mysql sur linux4 http://linux2/scripts/requetes/req_fich.php?reqid=10001 1 http://linux2/scripts/requetes/req_fich.php?reqid=10002 1 http://linux2/scripts/requetes/req_fich.php?reqid=10003 1 http://linux2/scripts/requetes/req_fich.php?reqid=10004 1 |
testbed
ensuite il y a le fichier de conf
proprement dit, voici les lignes les plus importantes :
|
### BENCHMARK
PARAMETERS -- EDIT THESE AS REQUIRED ITERATIONS="1"
### SERVER
PARAMETERS -- EDIT AS REQUIRED # This is the host
name or IP number of the web server that we will be # Port 80 is the
default web server port. If your web server is running |
|
B.2. Lancement du binaire |
Le binaire de webstone lance un autre binaire (webclient) installé dans tmp; pour notre install nous étions user oracle81. Le proprietaire de celui-ci (webdb) etait different du proprietaire de webstone (oracle81). Pour lancer webstone il a fallu se loger en webdb...
Enfin même si webstone archive toutes test de stress, nous placons le résultat manuellement dans un fichier au nom pertinent dans /tmp; exemple :
/export/home/oracle/stress/WebStone2.5/webstone | tee /tmp/report15
| C. Résultats |
Premièrement nous avons bien conscience de la difficulté de présenter des chiffres objectifs et rigoureux basés sur des tests pertinents et bien fondés. Sur la base de la figure 1 on peut rappeller deux choses:
1. Le test entre pspora_webserver et phpora_webserver est central de notre point de vue. Central dans le sens où il permet de faire la comparaison objective et rigoureuse entre les psp (propriétaire oracle) et les php (libre). La charge des machines conscernés (switch, dns, triton, webserver) n'était pas négligeable au moment de faire les tests (ie pas de charges), de sorte que seule la tendance doit rester à l'esprit.
2. On présentre autour du test central (pspora_webserver et phpora_webserver) deux autres tests satellites pour éclairer les perspectives de php et mysql. Ces deux autres tests dans les mêmes conditions de charges des machines conscernées ( (switch, dns, triton, linux4) chiffrent les performances phpora_linux4 et phpmysql_linux4.
On fixe des rappels techniques:
1. Configuration:
Webserver: Sun ultra 10 450MHtz 256 ram (solaris 2.6) oracle816+webdb et apache1.3.12/php40pl2 sans Zend)
Linux4 : suze 6.4 (bi-pro 450 avec 256 ram) oracle816 (php40pl2 zend0.99, apache1.3.12)
Triton : Sun e250 (bi-pro 450 avec 256 ram) solaris2.51 oracle7332. Remarques importantes avant de lancer les stress:
2.1. Vérifier que les requêtes contiennent des litérraux, de maniere a n'etre compiler qu'une seul fois sur oracle, ie afin de maximiser la reutilisation.
2.2. IL faut placer des connections persistante, sinon, le serveur sgbd aura la cpu a 100%. Dans le cas de connection persistante (en oci : OCIPLogon au lieu de OCILogon et en ora pas de persistance) on soulage considérablement le serveur de data : de 100% on passe à 10, 20%. En conclusion il faut imperativement les api de oracle 8 pour compiler php sinon les performance seront quasi lineaire avec le nb de connection concourrante). On rappelle les deux configue possible et les implication :
2.2.1. php/apache et sgbd sur 2 machines differentes. Dans ce cas un client net8 est necessaire.
2.2.2. php/apache et sgbd sur meme machine. Implique un oracle 8 (voir note conseil oracle...)
2.2.3 Pour attaquer un oracle 7 avec un client 8 par les OCI, il faut placer le proprietaire des process fils d'apache (par default nobody) dans le groupe oracle.Note : Le Conseil support oracle préconise de ne pas placer un client 8 sur un oracle 7 ....
|
C.2. A propos de la charge CPU |
Pour le server de data (triton), le taux de charges de la cpu est identique par psp et php. Identique, dans le sens où on ne constate pas dans un cas comme dans l'autre une différence significative. En revanche dans tous les cas la cpu augmente sur les serveurs conscernés avec le nombre de clients et ceux de manière preque linéaire. Une dernière note : les data sur webserver sont délocalisés par dblink sur triton, ie les data sont sur triton, les psp et php basé sur webserver accède au data par dblink.
psp_ora_webserver : webserver cpu à 100% (pour 10 et 50 clients) et triton de 10 et 60% suivant le nombre de clients (entre 10 et 50).
php_ora_webserver : idem
php_ora_linux4 : linux4 cpu à maximum 30, 50% de 10 à 50 clients et triton de 10 à 60% suivant le nombre de clients (entre 10 et 50).
php_mysql_linux4 : linux4 cpu à 100% pour 50 clients.
Archives résultats de WebStone 2.5 pour des clients (de 10 à 50) concurrents :
|
C.3. Graphiques |
Fig. 2
Fig. 3
Fig. 4