Appel répétée à une mini page : optimisation

Version imprimable

09/08/2010, 23h13
ithurts

Appel répétée à une mini page : optimisation

Bonjour,

Je suis amené à créer une page php de quelques lignes qui sera appelé en moyenne 1 à 2 fois par seconde en période de pointe.

Le script doit simplement entrer des paramètres passé par $_GET (une dizaine) dans une table mysql sans en vérifier le contenu.
Tous les traitements (DELETE des raté/doublons etc .. se feront post rush, la nuit)

Assez effrayé à l'idée de faire un script de 10 lignes sensé supporté plus de 200 visites minutes en période de pointe j'essaie de faire au mieux pour l'optimiser.
Du coup j'ai tout plein de question !

Dans un tel cas de figure, est ce que

- PDO ou mysqli est mieux adapté que les fonctions mysql de base ?
- Une connexion mysql persistante à un intérêt ? http://php.net/manual/en/function.mysql-pconnect.php
- J'ai lu que le moteur Innodb était plus rapide pour des INSERT IGNORE que myiasim vu qu'il lock la ligne et pas la table , était ce mon imagination ou est ce vrai ?
- Faut il que je change de table quand celle ci atteint une certaine taille ?
Est ce que la taille d'une table influe sur un INSERT IGNORE ?

Mysql est il vraiment adapté ? Je n'ai jamais utilisé que lui, est ce que DB2-express-C , postgreSQL ou carrément un nosql serait plus adapté à mon besoin ?

Voilà toutes ces questions pour à peine 5 lignes de codes o// !

Merci d'avance pour tous vos conseils !
09/08/2010, 23h27
comode

Citation:

Envoyé par ithurts

- PDO ou mysqli est mieux adapté que les fonctions mysql de base ?

Ne pas confondre PDO avec un SGBDR ! PDO est juste une class permettant d'attaquer différent SGBD. Pour PDO, je pense que c'est bien plus lourd que les fonctions natives MySQL. Il serait néanmoins très intéressant dans le cadre d'une seule page effectuant un grand nombre d'appel à la même requete.

Citation:

- Une connexion mysql persistante à un intérêt ? http://php.net/manual/en/function.mysql-pconnect.php

Surtout pas ! la connexion persistante est valable juste pour une session... Si t'as 200 utilisateurs qui attaquent ta page, t'auras 200 connexions ouvertes en simultanées, ce qui est tout sauf une optimisation... Ca serait en revanche très intéressant avec un script en tache de fond commun à tous les utilisateurs (que tu pourrais attaquer - par exemple - avec un pipe ou un socket).

Citation:

- J'ai lu que le moteur Innodb était plus rapide pour des INSERT IGNORE que myiasim vu qu'il lock la ligne et pas la table , était ce mon imagination ou est ce vrai ?

Je crois que oui, mais que les tables sont beaucoup plus lourdes

Citation:

- Faut il que je change de table quand celle ci atteint une certaine taille ?
Est ce que la taille d'une table influe sur un INSERT IGNORE ?

non si elle est bien indexée

Citation:

Mysql est il vraiment adapté ? Je n'ai jamais utilisé que lui, est ce que DB2-express-C , postgreSQL ou carrément un nosql serait plus adapté à mon besoin ?

N'en déplaise à certains, je pense que oui. Je ne dit pas qu'il est mieux qu'un postgres, ni qu'il est aussi complet qu'un oracle, mais c'est selon moi un excellent SGBD à qui 200 requêtes / secondes (si elles sont bien conçues), ne devrait pas faire peur.

PS : Après tes rush, n'hésite pas à faire un petit "optimise" de ta table pour tout bien ré-indexer.
10/08/2010, 00h27
ithurts

Bonsoir et merci infiniment pour vos réponses !

Citation:

Surtout pas ! la connexion persistante est valable juste pour une session... Si t'as 200 utilisateurs qui attaquent ta page, t'auras 200 connexions ouvertes en simultanées, ce qui est tout sauf une optimisation... Ca serait en revanche très intéressant avec un script en tache de fond commun à tous les utilisateurs (que tu pourrais attaquer - par exemple - avec un pipe ou un socket).

Je suis super intéressé par cette méthode !
Par contre petit problème : toutes mes recherches google avec "mysql daemon pipe socket connect" ne mènent qu'a des postes relatant des problèmes .. :x
Serait il possible d'avoir le nom de cette technique ou un lmgtfy à ce sujet ?
Merci d'avance !

Citation:

N'en déplaise à certains, je pense que oui. Je ne dit pas qu'il est mieux qu'un postgres, ni qu'il est aussi complet qu'un oracle, mais c'est selon moi un excellent SGBD à qui 200 requêtes / secondes (si elles sont bien conçues), ne devrait pas faire peur.

J'envisageais aussi sérieusement de passer sous postgresql, merci de confirmer ce choix ;D
Du coup je vais utiliser pdo histoire d'abstraire le sgbd utilisé !

Cdt
10/08/2010, 01h45
comode

Méfiance quand même avec la PDO, y'a des méthodes qui fonctionnent avec certains SGBD et pas d'autre (genre LastInsertID()), mais je ne saurais pas dire quoi et avec qui.

Citation:

merci de confirmer ce choix ;D

Ca fait trop longtemps que j'ai pas utilisé postgres pour savoir s'il est vraiment mieux au vu des dernières versions de mysql. Je pense qu'un post dans le topic adapté serait plus judicieux avant de faire ce choix.

Citation:

Je suis super intéressé par cette méthode !

Le problème, c'est qu'elle n'est pas si simple... En effet, même s'il est prévu que ça change dans les version à venir, PHP n'est pas encore adapté à la création de daemons (je crois que PHP gère désormais un garbage collector, mais il faut un temps max d'exécution des scripts illimités, puis c'est pas vraiment fait pour). En d'autre terme, il est préférable de créer ce daemon avec un autre langage, genre PERL.

Une fois que t'as un petit soft en PERL qui écoute un port sur 127.0.0.1 et qui maintient une connexion ouverte, coté php, c'est ultra simple... un connect, un write et un close.

Par contre, pour rédiger le soft en PERL, ça fait trop longtemps que j'en ai pas fait pour pouvoir t'aider.

D'autre part, j'insiste bien sur le fait que c'est une optimisation pour les accès BDD, notamment en terme de connexions ouvertes simultanément. Je ne sais pas quel pourra être le gain global (qui devrait cependant être légèrement meilleur puisque je crois bien que PHP ouvre de toute façon une connexion via socket au serveur SQL local à chaque appel de mysql_connect).
10/08/2010, 10h55
ithurts

Bonjour !

Merci pour ces éclaircissements !

En fait je pensais le faire en C++ avec un fork off&die, je n'ai jamais fait de perl.
Mais dans tous les cas j'ai du mal à conceptualiser la chose.

Donc on a d'un côté un script web
De l'autre côté un démon connecté à un SGBDR

Est ce que le démon doit :
- Offrir un socket tunnelisé vers un autre socket de connexion d'SGBD
- Écouter,Recevoir les informations, et effectuer lui même les requêtes.

Mais tout ça a déjà été pensé non ?
Est ce que ça vaut vraiment le coup de réinventer la roue, je dois pas être le premier confronté à un tel problème et j'ai beau chercher, impossible de trouver quoi que ce soit qui ressemble de près ou de loin à ca !
Ça m'inquiète un peu :D
(et ça me fait penser à : http://www.developpez.net/forums/d96...ayez-utilisee/ )

Cdt
10/08/2010, 13h53
comode

Oh oui, ça a du déjà être fait. Après, est-ce que quelqu'un l'a publié sur le net, je ne sais pas.

Sinon, le C++ est une bonne option, surtout pour ce qui est de la rapidité. Je recommande l'utilisation des socket, car je ne sais pas comment gérer les pipes depuis php, et tu n'auras pas de mal à trouver des codes tout fait, genre un petit serveur de chat en socket où tu auras juste à remplacer la fonction de brodcast par un appel SQL. Pas besoin d'un FORK non plus, utilise plutôt un select() qui te permet de gérer plusieurs connexions de façon propre et sans processus fils (j'avais fait un truc du style y'a quelques années, mais je ne retrouve pas mon source).

Citation:

- Offrir un socket tunnelisé vers un autre socket de connexion d'SGBD
- Écouter,Recevoir les informations, et effectuer lui même les requêtes.

Bha comme tu l'aurais fatit en PHP avec une connexion permanente... Tu ouvres ta connexion persistante au lancement, et quand des données arrivent sur un socket, tu exécutes une requête SQL avec.

Après, peut être ne faut-il pas te focaliser sur la méthode que je propose. Moi, j'ai suggéré ça, mais sur un serveur dédié où tu peux configurer le max de connexions simultanées au SGBD en illimité, peut être que PHP suffit.
10/08/2010, 19h04
ithurts

En fait toute cette histoire du démon ..
Ça s'appelle le "connection pooling" (p...n de nom barbare trouvé sur une dixième page de recherche google ><)

Plus d'info ici :
http://brunovernay.wordpress.com/200...owing-problem/
Et mon choix va probablement s'orienter sur
http://sqlrelay.sourceforge.net/
Et ailleurs !
Du coup j'ai pas à réinventer la roue ! :D
Par contre, ça reste hallucinant de voir à quel point ce système est méconnue

Enfin voilà merci infiniment comode j'aurais jamais trouvé ça sans toi , même si il me reste plein de question je vais mettre ce post en résolu !

Cdt
10/08/2010, 20h23
comode

Je ne le connaissait pas non plus :p Enfin au moins, on sait maintenant que le principe est viable et qu'il constitue bien une optimisation non négligeable.
10/08/2010, 20h35
nosferapti

une autre possibilité serait d'utiliser la plus simple base de données qu'il existe : un fichier texte
ensuite, quand la période de pointe est passé, un autre système lit les fichiers et les insère dans la base de données MySQL
10/08/2010, 22h46
ithurts

Bonsoir,
En effet j'avais envisagé cette solution.
J'avais même commencé à reprendre qq sources d'assembleur.

Mais je suis plutôt effrayé à l'idée de gérer des centaines d'accès simultanés à un seul et même fichier, ainsi que toutes les problématiques de file d'attente lié aux flock.

De plus Je n'ai plus le chiffre en tête mais je dois pouvoir au mois gérer 100 appels simultanés à ce script : Apache2 doit générer une erreur 500 avant que le script dépasse la seconde d'exécution.

...
Par contre si vous avez quelques liens de projets (non sgbd) utilisant cette méthode déjà codé et éprouvé sur le même sujet que le mien, je tourne direct ma veste !

Cdt.
10/08/2010, 22h59
nosferapti

Citation:

Envoyé par ithurts

Mais je suis plutôt effrayé à l'idée de gérer des centaines d'accès simultanés à un seul et même fichier, ainsi que toutes les problématiques de file d'attente lié aux flock.

je pensais plutôt à un fichier par appel et ensuite tu as juste besoin de parcourir le répertoire et de lire les fichiers les uns après les autres

Citation:

Envoyé par ithurts

Sachant que ça passe par apache avant et que ce sagouin crée limite un processus par appel : "ça va tout péter !"

regarde cet autre serveur : http://www.lighttpd.net/
et associé à ça, c'est vrai qu'un programme C compilé sera plus rapide que du PHP qui est interprété

Citation:

Envoyé par ithurts

De plus Je n'ai plus le chiffre en tête mais je dois pouvoir au mois gérer 100 appels simultanés à ce script : Apache2 doit générer une erreur 500 avant que le script dépasse la seconde d'exécution.

tu dois générer une erreur 500 à quel moment ?
10/08/2010, 23h30
ithurts

Bonsoir,

En effet hyper astucieux 1 fichier par appel !

Sinon pour l'erreur : apache(ou lighthttpd) génère bien une erreur 500 à l'utilisateur en cas de timeout (et donc de surcharge) si mes souvenirs sont exact non ?
J'ai pour consigne de faire quelque chose qui cède après apache :x, ou carrément le serveur ...

Sinon, je dois avouer que je suis complètement séduit par cette idée, avec un démon qui mange à son rythme les fichiers petits à petits pour les insérer dans un SGBD.
Et un script qui se contente simplement de créer un fichier avec un nom unique et les données BRUT à insérer.
Je vois ce qui peut être bloquant là dedans ...

Un grand merci !