Discussion :

[elcoyotos]

Bonjour,

Je suis en train de développer un chat en php/ajax.

J'actualise le contenant des messages via une requête ajax qui lance un select dans ma base de données. La fréquence d'actualisation est toutes les 1 seconde.

Sachant que je suis en mutualisé chez OVH : Une requête toute les secondes, n'est ce pas trop pour le serveur ?

Si oui, comment faire autrement ?

Merci d'avance de vos réponses

PS : Pour les devs -> Il n'y a pas PHP8 dans les préfixes

[darkstar123456]

Bonjour,

C'est difficile de répondre à ce genre de question
Il faudrait connaître la charge qu'utilise l'exécution du script et la multiplier par le nombre de personnes potentielles

Un serveur peut facilement gérer plusieurs centaines de requêtes PAR SECONDE, donc tant qu'il n'y a que quelques utilisateurs, ça ne sera pas forcément un problème mais ça peut très très vite le devenir
Surtout sur des serveurs mutualisés qui sont généralement moins puissants que des serveurs dédiés

Quoi qu'il en soit, je vous conseillerais plutôt d'aller voir du côté de NodeJS (cependant pas possible sur un serveur mutualisé à ma connaissance) grâce à Express et socket.io dont c'est le "travail"
D'ailleurs le Getting Started de Socket.io est justement un live chat (c'est sûrement pcq c'est ce que veulent le plus les gens ^^) : https://socket.io/get-started/chat

En plus, ils permettent de créer des choses beaucoup plus complexes comme le fait de regrouper des personnes (salons ou direct message)
Ce serveur fonctionne sur le principe d'une boucle infinie et donc on est dans du VRAI live (pas toutes les secondes)

[elcoyotos]

Bonjour,

Merci pour ta réponse qui m'éclaire tout de même. Pour la charge qu'utilise l'exécution du script, je ne sais pas comment calculer cela (est ce possible sur un mutualisé ?)
Quant au le nombre de personnes potentielles, il est bas. Moins d'une dizaine...

Pour nodejs, ce n'est effectivement pas proposé sur un mutualisé. Je vais quand même regardé Getting Started de Socket.io par curiosité....

[darkstar123456]

Bonjour,

Je t'avoue que les calculs de charge ce n'est pas ma spécialité et encore moins sur un serveur mutualisé où on a pas vraiment accès à ces données malheureusement.

Je pense que de toute façon, si tu consommes trop, t'auras un avertissement d'OVH

Personnellement, avant de passer sur du Socket.io, je faisais le même système que toi mais par contre, j'augmentais tout simplement le timeout (temps entre les requêtes)

Il me semble que j'avais 15 secondes et que ça passait smooth pour plus de 100 personnes.
Surtout que si t'es pas en direct/live, que tu aies 1s de délai ou 15s, ça ne se voit pas forcément trop
Je te conseille de toute façon de mettre cette valeur dans une variable afin de pouvoir jouer avec.
Tu pourrais même envisager de compter le nombre de personnes connectées et d'augmenter/diminuer le timeout en fonction (si ça devenait nécessaire)

Il est évident par contre qu'il faut éviter de charger trop de trucs inutiles. Par exemple, si tu comptes charger tout ton site web pour juste extraire la valeur qui se trouve dans un input, ça n'aurait pas de sens ^^

[elcoyotos]

Bonjour,

Effectivement, si je consomme trop, j'aurai un avertissement d'OVH
C'est ce que j'ai fait (augmenter le timeout)

Tu pourrais même envisager de compter le nombre de personnes connectées et d'augmenter/diminuer le timeout en fonction (si ça devenait nécessaire)]

C'est une excellente idée !

Merci d'avoir pris du temps pour me répondre...

[grunk]

Globalement , faire un chat en polling c'est une mauvaise idée , car comme tu as pu t'en rendre compte c'est problématique d'un point de vue performance.

La bonne solution est bien évidemment de faire du push avec des websocket par exemple.

Dans le cas ou ce n'est pas une options , il faut à minima faire du polling intelligent :

Avoir un l'intervalle de requêtage faible au début (par ex 1x/s) , puis si pas de nouveau message depuis un certains temps augmenter exponentiellement (jusqu à une certaine limite) afin de soulager le serveur quand il ne se passe rien. Dès qu'un changement apparait on repart sur un polling rapide.
Adapter l'intervalle en fonction du nombre de client est également une bonne idée.

[elcoyotos]

Bonjour,

Merci pour vos conseils que je vais suivre...

[elcoyotos]

Avoir un l'intervalle de requêtage faible au début (par ex 1x/s) , puis si pas de nouveau message depuis un certains temps augmenter exponentiellement (jusqu à une certaine limite) afin de soulager le serveur quand il ne se passe rien. Dès qu'un changement apparait on repart sur un polling rapide.
Adapter l'intervalle en fonction du nombre de client est également une bonne idée.

@grunk Du coup, j'en suis là :
Comment régler l'intervalle de requête en fonction du nombre de messages/utilisateur sans interroger la base de données toutes les x secondes ?
Car sinon, ça ne sert à rien pour soulager le serveur des x requête toutes les x secondes pour afficher les données, de l'interroger toutes les x secondes pour savoir s'il y a de nouvelles données...
J'avoue que je ne comprends pas comment faire
Aurais-tu une piste à me suggérer.

[Pytet]

Bonjour,

Tu pourrais aussi faire du long polling, c-a-d laisser la requête en attente et y répondre uniquement lorsqu'un nouveau message arrive.
Mais comme précisé par grunk, faire du push avec les websockets, les server-sent events ou le protocole Mercure seraient de meilleures solutions.

Sur la chaine youtube de l'AFUP, tu peux trouver la présentation "Propulser du temps réel avec PHP en 2020 !" qui donne plus de détails sur ces différentes solutions :

[elcoyotos]

Merci Pytet pour ta réponse.

Comme précisé dans les précédents messages, je suis en mutualisé. Donc, d'après ce que j'ai compris, le longpooling et nodejs, il faut oublié...
Je vais regarder du côte des websockets, de server-sent events ou du protocole Mercure...

[grunk]

Comment régler l'intervalle de requête en fonction du nombre de messages/utilisateur sans interroger la base de données toutes les x secondes ?

Je ferais ca coté client.
Par exemple :
- Tu commences avec un polling à 1s
- Pas de message reçus après Xs tu passe à 5s
Et ainsi de suite jusqu'à un intervalle que tu juge acceptable pour la réactivité de ton appli et la santé de ton serveur.

[elcoyotos]

@grunk : Je comprend comment faire et je te remercie de ta reponse.
Ce que je ne comprend pas c'est que pour

Pas de message reçus après Xs tu passe à 5s

Il faut bien que j'interroge le serveur ?
Donc, il faut encore un timeout supplémentaire ?
Dans ce cas, au lieu de diminuer les requetes, j'en ajoute ???
C'est cela que je ne comprens pas...
Peux tu me montrer un exemple de code ?

[grunk]

Il faut bien que j'interroge le serveur ?

Oui , et ca tu le fais déjà.

Donc, il faut encore un timeout supplémentaire ?

Non

Exemple :

00.00 pull - message
00.01 pull
00.02 pull
00.03 pull
00.04 pull
00.05 pull - Pas de message depuis 5 secondes , augmentation du timeout
00.10 pull
00.15 pull - message , réduction du timeout
00.16 pull
etc ...

[elcoyotos]

Bon sang mais c'est bien sur !
Merci grunk pour ton exemple limpide

[elcoyotos]

C'est encore moi avec mon timeout
Cette fois, je bloque sur comment transmettre mon timeout.

Je m'explique : J'ai 2 pages.

1. La page qui affiche le chat dans laquelle il y a le javascript avec le timeout. Mettons, la page index.php
2. La page qui est actualisé par le timeout et qui envoie les données à la page index. Mettons ajax_chat.php

Comment actualiser le timeout dans la page index.php ?

[grunk]

Tu es plus sur une problématique javascript que PHP maintenant , mais suffit faire un clearTimeout() quand il doit changer et de le recreer avec la nouvelle valeur

[elcoyotos]

Oui effectivement, maintenant je suis sur le javascript. Merci grunk pour la piste. Je vais regarder ce que je peux faire avec clearTimeout()