Oui en effet, question nombre d'objets il y a une limite. FastFrench a publié des tests là-dessus dans la guilde NWN-FF, que j'ai refait.
On peut sans problème monter à 10000 variables chaînes locales en restant plus rapide qu'avec MySql, au delà ça pose problème.

Après examen, 1500 chaînes locales de 250 caractères ca fait moins d'1Mo pour la consommation du module en mémoire.
Ceci je doute qu'on ait 1500 objets chaînes à manipuler d'un coup.

A titre d'illustration de ce que je dis : il est difficile de manipuler des inventaires (coffre par exemple) de plus de 300 items : on tombe radicalement, peut importe le script (script unique s'entend) sur des messages d'erreurs qui disent que l'on a dépassé le nombre d'instructions maxima permis.

Le système a ses limites mais ça laisse le temps de voir venir (pour expliquer MySql aux co-MD) avant de passer à une solution plus "professionnelle".

------------------------------------------------------------------------------------------
Le double tranchant : faut relativiser

Le risque de panne serveur existe, certes... mais dans le cas du BBS il est très limité.
Coté fichier dbf, fpt, cdx on ne perd que le(s) dernier(s) enregistrements non écrits.
A la vitesse ou postent les utilisateurs ... 15 secondes c'est court.
J'ai testé une coupure brutale du module, la base reste en bon état, seul le dernier enregistrement est géné.
Faudrait voir avec l'option de suppression(effacement des messages) comment c'est géré.
De part sa structure, le BBS est robuste, il y a certes plusieurs chaînes à enregistrer mais le fondamental lors d'une mise à jour des messages est un compteur entier (int) celui là qui sera écrit très rapidement.

A la limite pour sécuriser la base BBS, il suffit de le repasser en instruction directe SetCampaignInt, l'impact performance est minime ... mais enfin je trouve ça parano en connaissance de cause de la longue période de test (1 mois) pour éprouver la robustesse du cache avec des usages bien plus rudes et délicat vis à vis des joueurs (coffres persistants)
Ceci dit également j'ai un module qui à tourné en début aout environ 200 heures sans panne...

D'autres part tout système de données s'envisage avec un aspect sauvegarde en cas de soucis : un sauvegarde par jour en zip par exemple, un bon petit schedule windows ou cron linux. Même si le module est up ca ne gêne pas.

Donc aussi curieux que ça puisse paraître le cache est une solution médiane, inutile pour le module solo, pas assez extensible pour beaucoup d'utilisateurs en ligne si on l'utilise pour toutes les fonctions de persistence : je ne sais pas ou est la limite mais je dirais que si c'est pour le BBS en l'état, sans autre type de données à gérer : pas de surprise à avoir même avec 25 joueurs en permanence et 10-30 messages par jour, gardés sur un mois.
Après, et bien, je pense que l'interface elle-même montrerait des limites : faire 30 clics pour aller au fin fond du dernier message (300 avant par exemple), ce serait décourageant.
MDs : ménage à faire.

A tester et à mettre à l'épreuve donc.

PS1 : Ne vous méprenez pas : je suis partisan des systèmes avec une vraie database, cette solution est pour permettre à ceux qui ont quelques soucis de performance avec la database nwn de patienter le temps de faire une transition raisonnée vers MySql.
PS2 : à quand un tutorial sur la mise en place d'easy-php par exemple et le paramétrage de MySQL pour raccordement à un module avec NWN-FF ou APS-NWX2. Ni Papillon, ni FastFrench ne le font.
PS3 : les performances n'ont absolument pas à rougir devant MySQL, c'est meilleur dans les faibles activités.
PS4 : si suite de discussion là-dessus il faudrait diviser le sujet.

Voilà, sujet divisé
_________________
» Le Tref & l'Aucube : Histoire, misanthropie & zoologie léonine
» 1626, le Gant & l'Epée : intrigues & duels sous le règne de Louis XIII

Si ce n'est qu'un risque de perte d'un seul enregistrement en cas de plantage, jolie boulot... comme je l'ai dit dans l'autre post, je n'ai fait que parcourir ton code.
Cependant, un détail dans tes explications ajoutent une robustesse au BBS.

Citation :Et oui comme ton système ce base en priorité sur le cache, la base BBS restera intacte même lors d'un plantage provoqué par un évènement indépendant du BBS lors d'un postage de message. Alors que malgré la robustesse du BBS, il est arrivée que sa base soit corrompu après plantage.

Pour le nombre de variables sur objet, j'avait oublié leur nombre... si c'est bien 10000, ton système de cache ce trouvera en rapport de force face à mysql, c'est certain.

Pour l'interface du BBS, les 30clics sur suivant sont loin d'être atteint. Car il est prévu de base à n'enregistrer que 100messages par rubrique. Au dela, les plus vieux message seront écrasé par les nouveaux. Pour schématisé la chose, un jolie cercle gradué de 1 à 100. Une fois passé le cap du 100 + 1 message, le message signé 1 sera écrasé. Pour les effacements, le BBS n'utilise pas de DeleteCampaign... Il prend la signature du message et décale tous les autres messages de signature supérieur de -1. Pourquoi cela, c'est simple un DeleteCampaign n'efface pas réellement la donnée, il ce contente de dire dans la BD qu'elle est détruite.
Autre chose le BBS, utilise le même principe que ton cache, MODE FIFO.

Dès que j'aurais fini quelques travaux divers pour Pandorn, je me pencherais sérieusement sur ton système de cache.
_________________
Module en développement : Pandorn Nouvel Age
Système de Pandorn diffusé : Cliquez-ici

j'avais fait un test très court (formalisé) il est ici
Bench
C'était sur une version un peu moins aboutie du cache la semaine d'avant
Les boucles de test sont là, c'était lié à un OnClose de coffre. Le mysql provient bêtement d'une installation d'easy-php 1.7
Scripts de test