Avez-vous déjà testé la mémoire que prenait PHP avec vos script ?

[Sephi-Chan]

- ton système de cache, utilise t il la RAM ou utilise t il un système de fichier?

Par défaut, c'est le filesystem qui est utilisé, mais on peut facilement passer à memcached (il suffit de l'installer et de spécifier les coordonnées du serveur).

- ton exemple de HTML mis en cache fais 7Ko donc si tu as 1000 joueurs qui ont affichés cette page dans un laps de temps assez court cela te fais 7Mo de cache, a moins que le cache ne soit compressé...cela risque d'etre enorme les données mise en cache non?

Ben… 7Mo, ce n'est pas énorme sur un disque de 250Go. Mieux vaut utiliser un peu plus l'espace disque et soulager fortement le processeur (qui n'a plus besoin de toujours boucler pour construire le HTML) et la base de données (qui n'est plus du tout interrogée dans 99% des affichages). En plus, ici, j'ai formatté un peu le HTML stocké (grâce à XML Tidy) pour qu'on voit mieux ce qu'il contient, il est en fait minifié.

Et puis, n'oublie pas que le premier fragment que j'ai copié est commun à tout le monde, il n'y a donc qu'un seul fichier (pesant 4.9Ko) constant.
Ensuite, il y a un fichier pour chaque joueur, contenant le HTML qui représente les bâtiments possédés, sa taille varie selon le nombre de bâtiment (entre 1 et 37). Ici il pèse 1.9Ko pour 13 bâtiments.

-quand est ce que le cache est detruit? à la fin de la session (beaucoup de joueur ne se deconnecte pas)? apres un certain delais?

La destruction du cache peut-être faîte manuellement (comme dans le cas que je te présente), semi-automatiquement (dans des Sweepers, qui se déclenchent quand on crée, modifie ou supprime certains objets), ou suivant un timer (ce comportement est réservé à Memcached), comme ceci :

<% cache "key-for-cache", :expires_in => 10.minutes do %>

  <%# ... %>

<% end %>

Bien sûr, je peux mettre ce que je veux, des secondes aux années.


Sephi-Chan

[Cartman34]

34.579.640 (~33mo) pour Staart.fr en fin de page.
Ceci est justifié par toute la configuration mise en tableau et le tableau de langue, etc...

Ce que je ne comprends pas c'est que ce chiffre ne cesse d'augmenter à chaque nouvelle exécution !

EDIT: En fait, cela semble être causé par le faire que je doit garder en session les playlists déjà lancées afin de permettre à l'utilisateur d'ouvrir plusieurs page en même temps.
mais en théorie, c'est quelque Ko et là c'est plutot 2Mo à chaque fois...
Je vais chercher une solution à ce problème.

[php_addict]

Ce que je ne comprends pas c'est que ce chiffre ne cesse d'augmenter à chaque nouvelle exécution !

es tu en POO ? j'y connais pas grand chose en POO mais il me semble que tu dois construire et detruire tes class, non? a moins que cela se fasse automatiquement, j'en sais rien...c'est peut etre cela qui te bouffe de la RAM...j'ai peur de te dire une ânerie car je suis pas fortiche en POO...

2Mo a chaque fois c'est beaucoup quand meme...

[Cartman34]

Non, tout est détruit à chaque fois, c'est l'avantage et l'inconvénient de PHP.
Mais j'ai expliqué la raison en EDIT dans mon précédent post...

[php_addict]

tu as testé avec xdebug?

[Cartman34]

Non, mais je le ferais.

[srm]

Même si ton code est intéressant Sephi, je ne le recommanderais pas.
Coder proprement, efficacement dès le début oui.
Mais commencer à mettre plein du cache partout (générateur de bien plus de bug, car tu ajoutes de la complexité) alors que ça n'est pas forcément utile non. Avoir un code souple et élégant qui sera extensible et le permettra si le besoin s'en fait ressentir oui.

[Sephi-Chan]

Même si ton code est intéressant Sephi, je ne le recommanderais pas.
Coder proprement, efficacement dès le début oui.
Mais commencer à mettre plein du cache partout (générateur de bien plus de bug, car tu ajoutes de la complexité) alors que ça n'est pas forcément utile non. Avoir un code souple et élégant qui sera extensible et le permettra si le besoin s'en fait ressentir oui.

Qu'est-ce que tu recommandes ? Le retrait pur et simple des deux blocs de cache ?

Je suis assez surpris par ta remarque car je pense sincèrement qu'on ne peut pas faire plus simple dans la mise en place d'un cache (dans le cas contraire, je veux voir un exemple ^^). D'autant que la syntaxe des blocks de Ruby rend ça encore plus évident.

Peux-tu préciser la complexité que ça ajoute ? Car à mon sens c'est trivial dans le concept comme dans l'application : les clés utilisés pour les caches sont basiques et ne dépendent que d'un paramètre au maximum (aucun dans le cas de la carte globale). On ordonne l'expiration des caches ensuite (d'ailleurs, ça aurait dû se faire grâce aux Sweepers de Rails, mais j'ai rencontré un bug avec la bêta de Rails 3, je garde cette partie au chaud en attendant le fix).

Quels bugs potentiels imagines-tu ?

Enfin voilà, si tu pouvais détailler/préciser tes inquiétudes quant à la limpidité du code, je t'en serais reconnaissant (pour éventuellement modifier le pas à pas, si c'est justifié).


Sephi-Chan

[srm]

Car ça peut toujours partir en vrille, plus tu ajoutes de complexité, ici de cache, un moment tu vas oublier un cas ou faire correctement expirer le cache, ou alors un cas ou le cache va être mal utilisé et donc inutile.

Et ça sans compter les problèmes indépendant de ton code qui peuvent survenir, par exemple pour ton cas, tu fais un système de cache clean, qui marche du tonnerre. Pouf tu as 100000 utilisateurs un jour et tu te rends compte que ton application est devenue super lente parce que tu as 100000 petits fichiers dans un répertoire ce qui ne facilite pas le système de cache à chercher les fichiers qui l'intéresse alors qu'avec un système de sous-dossier pour partitionner les fichiers il n'y aurait pas le problème.

Ca n'est qu'un exemple, il peut y en avoir des tonnes et pas que pour le cache, pour tout et n'importe quoi.

[Sephi-Chan]

Car ça peut toujours partir en vrille, plus tu ajoutes de complexité, ici de cache, un moment tu vas oublier un cas ou faire correctement expirer le cache, ou alors un cas ou le cache va être mal utilisé et donc inutile.

Et ça sans compter les problèmes indépendant de ton code qui peuvent survenir, par exemple pour ton cas, tu fais un système de cache clean, qui marche du tonnerre. Pouf tu as 100000 utilisateurs un jour et tu te rends compte que ton application est devenue super lente parce que tu as 100000 petits fichiers dans un répertoire ce qui ne facilite pas le système de cache à chercher les fichiers qui l'intéresse alors qu'avec un système de sous-dossier pour partitionner les fichiers il n'y aurait pas le problème.

Ca n'est qu'un exemple, il peut y en avoir des tonnes et pas que pour le cache, pour tout et n'importe quoi.

Ça fait partie du cycle de vie de l'application : il faut être cohérent selon les besoins qu'on a.

Tu parles de mise à l'échelle de l'application. Si j'attends les 100 000 utilisateurs, j'aurais de toute manière besoin d'un cache : donc je m'exposerais aux problèmes que tu cites. La différence, c'est que si j'attends ce moment, je devrais mettre en place le cache dans un environnement probablement plus complexe : au pied du mur, j'oublierai probablement des cas d'utilisation.
En m'y prenant plus tôt, je vois le système se complexifier et je peux ajuster ma politique d'expiration des caches au gré de l'évolution de l'application.
Tu n'es pas d'accord ? (Si non, pourquoi ?)

Ensuite, tu parles des limites du système de fichiers : c'est vrai, c'est un risque. Un risque qui a une contremesure toute trouvée : le passage à Memcached, qui est éprouvé face à ce genre de situations (d'ailleurs, le problème des accès disques ne se pose pas avec celui-ci). Ce changement de moteur de cache est trivial dans Rails.


Sephi-Chan