Bonsoir à tous ,

Voilà , j'ai pour projet de développer une méssagerie "instantané" ( enfin presque ), uniquement en php/ajax ...

Un petit projet comme ça pour m'amuser et essayer de découvrir de nouveaux moteurs de stockage mysql ..

Sachant que les données ne seront pas gardés sur le serveur qui hébergera cette messagerie , j'ai l'intention de les rendres volatiles en utilisant le moteur memory (Heap).

Il y aura forcement de nombreuses petites connexions , pour savoir par exemple si un nouveau message vient d'arriver , ou si un nouvel utilisateur à rejoint le salon ...

C'est pourquoi je pense utiliserHeap qui a l'avantage d'être tres rapide et au vue du nombre de requêtes par utilisateur en une minute , celà ne peut être que bénéfique ... non ?

Qu'en pensez vous ?
Conseillez vous une autre façon de faire ? .. autre moteur ? ...
c'est une bonne idée ... à tester ?

Il faut que tu sois conscient que cela stocke la base dans ta RAM et donc qu'il faut un serveur suffisamment fourni à ce niveau. As-tu déjà évalué la taille de la base en fonction du nombre d'utilisateurs ?

Oui , j'en ai bien conscience ,
mais les données seront peut nombreuse , étant donne que le but , n'est pas de stocker , j'ai prévu , des scripts de nettoyage , qui vide au fur et à mesure ce qu'il faut pour ne pas laisser grossir la base en ram ..

( Enfin , pour le moment c'est sur le papier )

Ensuite , pour le nombre d'utilisateur , il sera normalement , fort limité ... car pour le moment ,c'est un projet de test , donc , une utilisation trés ponctuelle , avec au max 20 utilisateurs ...

Apres , je ne sais pas .. au vue du nombre de requêtes forcement plus important qu'une application standard , le fait d'utiliser ce genre de moteur n'est - il pas mieux , qu'un moteur Inodb par exemple , qui va engendrer plus d'acces aux disques dure ?

Là j'avoue que c'est totalement expérimentale j'aime bien les défis ...

Tu peux bencher…
Après évidemment que le but d'une telle extension c'est la performance. Cela va de soi que stocker des infos en RAM est infiniment plus rapide que de les mettre sur un disque dur… Mais attention à ne pas dépasser la taille de la RAM sinon tu risques de monopoliser la place d'autres applications plus critiques. Surtout que les copies RAM-Disque Disque-RAM lors de fautes de pages risquent d'être violentes.
Bref, quand je te dis de faire attention c'est sérieux. Car autant tu peux avoir de très grosses performances en stockant en RAM, autant si le système arrive à un moment à être obligé de swapper, les performances risquent d'être tout simplement désastreuses pour tout le système…

Humm tu as entièrement raison ...

Je n'ai pas envi que mon systéme se mette à swaper comme un fou ..
Il faut limiter les tailles des tables , et de ce fait , le nombre de connecté ...

Pour se faire , je pense mettre en place des "gardes fou" qui limiterons de nombreuses choses , comme , le nombre de messages à la minute , la taille de ces messages , le nombre de connecté simultané ... et en dernier recourt , bloquer la taille de la base ...

Ce qui limite les risques ...

De toute manière , les messages postés , ne seront stockés théoriquement ( encore une fois , ce n'est que sur le papier ) que quelque minutes .. car une fois affiché , il n'a plus lieu d'être dans la base ..

Mais il est vrai , que c'est un point critique à surveiller de trés prés , pour lequel il faut s'appliquer pendant le dev ..

Je comprends pas l'intérêt de la DB dans le cas d'une messagerie instantanée..

Je vois deux aspects:
- loguer ce qui se dit (pourquoi pas, mais simplement dans un fichier texte alors)
- transmettre le message le plus rapidement possible à son destinataire.

Bon. Dans le cas d'une messagerie "instantanée", tu peux soit faire du long polling (ce qui revient à du push, l'idéal pour une messagerie instantanée) ou du pull (aller voir de temps en temps si quelque chose de nouveau est arrivé).

La vitesse jouant une grande importance, et l'utilisation de la DB étant quand même assez lourde, pourquoi ne pas passer par quelque chose comme APC, pour stocker des objets en mémoire vive le temps que le destinataire vienne les chercher ?

Oui c'est vrai , je n'avais pas pensé à APC ...

Sinon , etant donné , qu'il peut y avoir plusieurs utilisateurs , qui dialoguent entre eux , il faut que chaque utilisateur ai le temps de récupérer tous les messages avant qu'il ne soient supprimés ...

Donc un simple Push/PoP en memoire n'est pas viable .. enfin , je pense non ?

Ah, ben comme tu es en ajax, tu fais en sorte que le poste client envoie bien une message de confirmation à chaque réception de message avant que le texte soit supprimé du côté client.

En gros, il s'agirait de travailler avec une fille d'attente, mais pas trop grande sinon on perd le suivi.

Ouaip , je pense utiliser finalement le cache APC , avec une liste qui contient des messages qui sont au plus , âgés de par exemple 3 minutes ... le tout vérifier via un "daemon" qui supprime les messages dont le timestamp est >= timestamp actuel + 3 minutes.

ainsi la file ne sera pas bien grosse ...
Et encore , 3 minutes , je peux réduire je pense ..

Pour la récupération des messages , je pense aussi utiliser le timestamp ...

Le client connecte récupère tous les messages dont le timestamp > au timestamp du dernier message récupéré par l'utilisateur .

Et cette vérification , faite toutes les 15 secondes par exemple ...

En gros, il s'agirait de travailler avec une fille d'attente, mais pas trop grande sinon on perd le suivi.

Une fille d'attente, c'est une dame avec laquelle tu prends du bon temps en attendant la femme de ta vie?

... Ripat voit tout ..

En gros, il s'agirait de travailler avec une fille d'attente, mais pas trop grande sinon on perd le suivi.

Une fille d'attente, c'est une dame avec laquelle tu prends du bon temps en attendant la femme de ta vie?

je m'essaie à la vulgarisation. Faudrait juste trouver de meilleurs exemples..