Discussion :

[Seb33300]

A prioris ça n'a pas été posté

Plutot que de faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
$req = mysql_query("SELECT COUNT(*) as nb FROM `table` WHERE `id`=".$id);
$rslt = mysql_fetch_array($req);
 
if($rslt['nb'] > 0){
     mysql_query("UPDATE `table` SET `time`=".time()." WHERE `id`=".$id);
}else{
     mysql_query("INSERT INTO `table` (`id`, `time`) VALUES ('$id', '".time()."')");
}

Faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mysql_query("INSERT INTO `table` (`id`, `time`) VALUES ('$id', '".time()."') ON DUPLICATE KEY UPDATE `time`='".time()."');

Bien sur cela implique d'avoir mis le champ `id` en clé primaire

[Yogui]

Pour info, MySQL propose la clause REPLACE INTO, dont la syntaxe est identique à l'INSERT INTO

[Seb33300]

Manuel Mysql

REPLACE works exactly like INSERT, except that if an old row in the table has the same value as a new row for a PRIMARY KEY or a UNIQUE index, the old row is deleted before the new row is inserted. See Section 13.2.4, “INSERT Syntax”.

Donc dans les tables InnoDB avec suppression en cascade on se retrouve à supprimer tous les contenus des autres table du meme ID.
Alors que le ON DUPLICATE KEY fait un UPDATE

[genova]

Le ON DUPLICATE KEY marche à partir de quelle version de MySQL ? Marche postGreSQL et SQLite ?

[FFF]

c'est effectivement un plus mais ca peut avoir des inconvenients, si tu as droit a 20 connections simultanées et que tu fais du pconnect, tu seras limité a 20 users sur ton site alors que sans le pconnect, tu pourras en avoir plus car ils interrogeront pas tous la base en meme temps

je ne suis pas d'accord avec toi :

Premièrement, lors de la connexion, la fonction essaie de trouver une connexion permanente déjà ouverte sur cet hôte, avec le même nom d'utilisateur et de mot de passe. Si une telle connexion est trouvée, son identifiant est retourné, sans ouvrir de nouvelle connexion.

Le seul inconvénient est au niveau de la sécurité du serveur mysql... mais y a moyen je pense de sécurisr cette connexion (filtre IP des requètes...).

[siddh]

je me suis mal exprimé.

Notez que les connexions persistantes ont quelques inconvénients si vous hébergez une base de données, dont le nombre maximal de connexion risque d'être atteint par les connexions persistantes. Si votre base de données accepte jusqu'à 16 connexions simultanées et que, 17 processus essaient de se connecter, le dernier restera sur la touche. S'il y a des erreurs dans les scripts qui ne permettent pas de fermer la connexion (par exemple, une boucle infinie), votre serveur sera rapidement engorgé. Vérifiez la documentation de votre base de données pour savoir comment elle traite les connexions inactives ou abandonnées.

[FFF]

Oui en fait j'ai pas lu toute la doc, tu as raison effectivement pour les connexions simultanées siddh.
Mais tu peux inclure dans le code une petite pause (qq milisecondes) au script, le temps que les autres libère la connexion, comme cela les autres requètes ne perdent pas en vitesse d'exécution et sont mêmes incitées à terminer rapidement leur process.
Pour avoir 20 connexions ou requètes simultannées sur un serveur web sur un site comme dvez.com je dirais (à vu de nez) qu'il faut peut -être une centaine d'utilisateurs (suivant la taille et le nombre des requètes) qui consultent le site, donc c'est pas si contraignant que cela (probabilités de clics simultanés).

En fait ce qu'ils disent de retenir de cette fonction sur la doc :

Résumons-nous : les connexions persistantes ont été définies pour avoir les mêmes fonctionnalités que les connexions non persistantes. Les deux types de connexions sont parfaitement interchangeables, et n'affecteront pas le comportement de votre script : uniquement son efficacité.

[siddh]

oui, c'est un plus mais faut juste faire gaffe.
Si tu as un dédié, tu fais ce que tu veux.
Dans le cadre d'un hébergement mutualisé, ca peut peut etre coincer.

Personnellement je n'utilise pas pconnect car je me suis fais une classe d'abstraction (que je vais modifier pour utiliser PDO) qui est un singleton donc je me fais ma persistance tout seul.

[FFF]

ça a l'air intéressant, tu peux expliciter ta démarche (PDO?) en quelques mots ?!

[siddh]

Pdo est une couche d'abstraction pour php 5:
http://fr3.php.net/pdo

[FFF]

Autre astuce :

resource mysql_unbuffered_query ( string query [, resource link_identifier] )


mysql_unbuffered_query() envoie la requête SQL query au serveur MySQL identifié par link_identifier, sans préparer les résultats pour la lecture, comme le fait mysql_query(). D'une part, cela réduit considérablement la consommation de mémoire par MySQL, lorsque les requêtes génèrent des résultats de grande taille. D'autre part, vous pourrez utiliser les résultats dès que la première ligne aura été lue : pas besoin d'attendre que la requête ait complètement été exécutée. Lorsque vous utilisez de multiples connexions à MySQL, vous devez spécifier le paramètre optionnel link_identifier.

[FFF]

Pdo est une couche d'abstraction pour php 5:
http://fr3.php.net/pdo

je ne vois pas le rapport avec les connexions persistantes...

[siddh]

ben tu met ca dans un objet dont tu te fais un singleton

[FFF]

ok je viens de lire une page intéressante :
http://qwix.media-box.net/index.php/...ingletonEnPhp5

je pense que c'est le principe de ce que tu disais plus haut.

Mais du coup, connaissant la programmation OO en java mais peu celle de php, je me pose la question de la durée de vie d'un objet en php ?!
Ce que j'ai en tête pour l'instant, c'est que pour tout code php, la durée de vie des toutes les instances (variables, objets...) est égale à celle de l'exécution du script php, est ce bien cela ?
Si c'est le cas, alors je vais me répéter en disant qu'il n'y a pas d'équivalents entre mysql_pconnect() et la connexion mysql via les objets PDO !
Si je me trompe alors explique moi car là je vois pas comment un objet php peut persister... (c'est d'ailleurs ce qui me fait douter de l'efficacité de la POO en php) sauf en utilisant les sessions (of course !) mais bon si faut d'abord mettre ça pour avoir ça...

Sinon le coup des singletons est astucieux !

[siddh]

oui tu met tes objets en session

[FFF]

DSL je suis pas convaincu par PDO (j'aime pas les sessions c'est un peu lourd pour peu de choses bien que très pratique j'avoue), je préfère mysql_pconnect()

Merci pour tes explications en tout cas !

[FFF]

pour expliciter ce que je viens de dire précedemment.

Dans ce cas là les sessions demandent trop de ressources au système (à confirmer).En tout cas je préfère les réserver uniquement pour avoir un identifiant de connexion sur le site. Ensuite rien n'empêche de faire un équivalent "programmation orientée" objet en utilisant les bases de données comme moyen d'accès aux membres des objets (qui seraient enfait des tables...) et de remplacer les méthodes par des fonctions classiques.

[FFF]

une autre astuce de performances pour exécuter un script php distant :
privilégiez la fonction fsockopen() ou stream_socket_client() vous perdez du temps en programmation, mais gagnez sur le temps d'exécution de votre script, voir le post suivant :

http://www.developpez.net/forums/showthread.php?t=73445

[Kioob]

Tu t'avances beaucoup je trouve...

Pour les connexions persistantes, c'est quasiment inutilisable en mutualisé. Et sur un dédié, il faut configurer MySQL pour accepter un grand nombre de connexion simultanées... ce qui veut dire beaucoup moins de mémoire disponible pour chacune de ces connexions, ce qui implique généralement pas mal d'accès disques supplémentaires... bref, dans ces conditions, ça empire largement les choses.

Donc comme spécifié dans la doc, ça peut être très interessant, mais seulement dans certains contextes assez particuliers.


Coté connexion persistante en session, à ma connaissance PHP coupera la connexion à la fin du script de toutes façons... donc lors de la ré-instanciation il faut se reconnecter... au final, je ne vois pas le gain.



Pour mysql_query_unbuffered, oui, effectivement. Mais ce n'est pas adapté à toutes les utilisations : il est par exemple impossible de faire des appels imbriqués avec cette fonction.

Pour ce qui est de ton ouverture par socket, il serait bien plus malin de faire une requete HEAD si tu ne souhaites pas récupèrer le contenu...

[FFF]

Tu t'avances beaucoup je trouve...

Oui mais c'est fondé !!

Pour les connexions persistantes, c'est quasiment inutilisable en mutualisé. Et sur un dédié, il faut configurer MySQL pour accepter un grand nombre de connexion simultanées... ce qui veut dire beaucoup moins de mémoire disponible pour chacune de ces connexions, ce qui implique généralement pas mal d'accès disques supplémentaires... bref, dans ces conditions, ça empire largement les choses.

Donc comme spécifié dans la doc, ça peut être très interessant, mais seulement dans certains contextes assez particuliers.


Coté connexion persistante en session, à ma connaissance PHP coupera la connexion à la fin du script de toutes façons... donc lors de la ré-instanciation il faut se reconnecter... au final, je ne vois pas le gain.

Relis bien la doc s'il te plaît !

Pour ce qui est de ton ouverture par socket, il serait bien plus malin de faire une requete HEAD si tu ne souhaites pas récupèrer le contenu...

J'ai fais les tests, il n'y a aucun apport significatif avec le HEAD. De toutes façons mon script ne récupérant pas la réponse que je fasse GET ou HEAD c'est pareil apparament le serveur web ne fait aucune priorité sur les différentes requètes. Dire que cela aurait été bien plus malin de faire un HEAD, je trouve que tu es un peu dur avec moi !
Mon pb n'était pas sur la requète HTTP, mais sur la façon d'exécuter un script distant !