utiliser son fameux 'scanmus' pour agresser les sites marchands
français à la conférence PHP Paris 2005 : c'est totalement
effrayant... A ce moment là, les performances deviennent le cadet des
soucis.
Non la performance passe après la sécurité car personne ne ferait des
courses sur un site marchand qui met 15 secondes a afficher chaque
page, quand bien même se serait ultra-sécurisé. De plus si ses sites
marchands avaient développer leur propre code, le scanmus se serait
cassé les dents.
Pour parler des performances justement : j'imagine que tes
applications sont au minimum sécurisées, donc tu as produit ce fameux
code (échappements de caractères, traitement d'erreur, etc.). Les
couches d'abstraction comme PEAR::DB ne font finalement que ce genre
de traitements supplémentaires, et souvent de façon très optimisée.
Non les couches d'absraction ne font pas QUE ce genre de traitement
complémentaire, il gère à CHAQUE requette le choix de la base de
donnée. ils doivent, j'imagine, implémenter EN PROPRE certains
fonctionnalités qui ne sont pas commune aux base de données.
Par ailleurs, je ne fais du traitement d'erreur que lorsque cette
erreur à une incidence durable et importante, soit très rarement (sur
viva par exemple très très peu d'écriture).
Si cétait juste une couche de sécurisation, il suffirait de lancer un
sed -e 's\mysql\pgsql\g' sur la totalité de l'arborescence.
cas incomparablement mieux que si on espère réinventer la roue. Le
cas de PDO est encore plus flagrant, car ce code est exécuté dans une
extension compilée avec une performance inégalable en code PHP,
fut-il en byte-code optimisé.
oui mais PDO est php5 only.
Pour ce qui est des comparaisons de performance entre les différentes
bases de données : si une application met 5-9 secondes pour réagir
sur une altération standard, i.e. qui arrive souvent, cela vient plus
souvent d'une erreur de conception que d'une lenteur du moteur de
SGBD. PostGre est effectivement moins rapide que MySQL, mais on reste
dans le même ordre de grandeur : on ne passe pas du quasi-instantané,
quelques dizaines de millisecondes, à presque une dizaine de
secondes, c'est-à-dire 100 fois plus.
c'est pas beaux de taper sur dany : c'est son code qui met ce temps. ;-)
je ne sais pas de quoi cela provient, mais les .jsp, .cfm sont
TOUJOURS plus lent que les .php sur le net. Oracle a besoin d'une
architecture matérielle plus étoffée que mysql. Maintenant je n'ai pas
travaillé avec pgsql, mais il est EVIDENT que plus on analyse une
requete pour faire des vérifications d'intégrité, plus la requette est
lente. [ne serait-ce que pour faire cette vérification].
Laquelle erreur de conception serait probablement gommée par
l'utilisation de la fameuse intersection de fonctionnalité. Du reste je
oui la BDD du pauvre, comme le compte bancaire universel ou la carte
plastique de retrait mono guichet qui ne peut pas servir à payer
(sécurité optimale).
L'intersection de fonctionnalité ne sert qu'a ceux qui essaient de
'ratisser le plus large possible' au détriment des performances. une
application pro n'est ni un cours de développement pour débutant (cad
facile à lire et comprendre avec des commentaires de code
pantagruelique, ni une proof of concept de l'universalité
d'environnement.
te rejoins totalement sur l'intégrité référentielle, même si
j'aimerais avoir un filet supplémentaire grâce aux foreign keys.
ces vérifications externes, j'ai connus avec access, non merci.
Pour info, et sans vouloir faire de surenchère, notre application
(système d'information hospitalier) effectue sans problème de
performance (réponse quasi-instantannée) 3 millions de requêtes pour
50 mille pages servies par jour. Avec un processeur dont les pics de
charge dépasse rarement 20% sur un lissage de 5 minutes.
il est seul sur son serveur ou est hébergé chez un dédié virtuel (et
donc partagé avec d'autres dédié virtuel) ?
Une requette n'est pas forcement identique à l'autre, la partie
"lourde" de viva c'est le géoclassement : chaque adresse est triée par
rapport à la commune du visiteur, on doit calculer les distances pour
chaque enregistrement et pour chaque requette, et il est impossible de
mettre des résultats en cache car chaque visiteur vient d'une ville
différente.
Si j'ai cité ce cas, ce n'est pas pour en avoir une plus grosse, c'est
parce que c'est un cas très particulier. Ce n'est pas trouver la liste
des produits qui appartiennent à la catégorie 1 ou de sortir le
dossier d'un patient avec toutes ses visites passées (par exemple)
Mot de la fin concernant le facteur exogène, ces couches
d'abstraction des surtout des standard de facto, qui font que
n'importe qui entrant dans de code s'y retrouvera d'autant plus vite,
sans avoir à effectuer sa propre rétro-ingénierie.
oui, on en revient , je sais suis un peu tétu, à pourquoi pas une
surcouche sur le langage, cela permettrait aussi a celui qui ne
connait pas php de s'y retrouver plus vite... nan je rigole.
Si une personne veut coder comme il faut avec ces méta-couches
d'abstraction, il doit d'abord faire de la rétro-ingénierie sur le
code de ces couches, sinon, je ne donne pas chère du code fini. les
codes php de 50 lignes qui refont ce qu'une ou deux fonction font
déja, je l'ai vu
un nombre incroyable de fois.
Je peux comprendre qu'une entreprise commerciale développe en
abstraction, ce qui lui permet de 'proposer' ses produits quelque soit
l'environnement de travail de ses prospects/clients, mais certains
prefèrent coder nativement (sacrifiant la portabilité il est vrai)
pour bénéficier des fonctionnalités et des performances de celle
qu'elle a choisie.
hervé
_______________________________________________
Dolibarr-user mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/dolibarr-user