Discussion :

[genova]

Bonjour, pour une application open source que je developpe j'utilise un système de cache, en stoquant des tableaux PHP.

Il y a deux façons de les stoquer, soit à l'aide d'un var_export() dans un fichier .php, soit en les serializant dans une table cache avec une ligne par fichier.

Après une série de benchmark je me suis rendu compte que le cache FTP était 2 fois plus lent que le cache Base de donnée, chaque include() coute environ 0.02 secondes alors qu'une requète prend 0.0004 seconde.
La question que je me pose c'est quel système utilisé ? Y a t'il des avantages à utiliser le FTP avec include() plutot que la base de donnée ? Sachant que l'application que je developpe est destinée à être redistribuée, y a t'il vraiment un avantage a utiliser le FTP (est il utile d'économiser le plus possible les requètes sur la base de donnée ?)

Merci d'avance pour votre éclairage

[loufoque]

Y a t'il des avantages à utiliser le FTP avec include()

Il n'y en a aucun.
Par contre, utiliser le système de fichiers, c'est déjà beaucoup plus intéressant.

C'est fou comme les gens peuvent utiliser le terme FTP pour tout et n'importe quoi.
FTP c'est un protocole de transferts de fichiers... C'est généralement avec ce protocole qu'on transfère les fichiers sur le serveur HTTP.
Mais bien entendu, ensuite, une fois que les fichiers sont sur le serveur, on ne repasse pas par FTP pour accéder aux autres fichiers du serveur.

[genova]

Oui en fait c'est ce que je voulais dire désolé ^^
Donc il est plus avantageux d'utiliser les fichiers via include() plutot que le cache dans la base de donnée ? Est ce que le nombre de requètes a long terme a vraiment un impact négatif ?

(au fait pour les chiffres je retire ce que j'ai dit, je faisais mes tests sur un serveur windows assez lent ce qui fait que les accès fichiers étaient lents, j'ai retester sous linux et c'est bien plus rapide).

[Kioob]

+1 loufoque

Mon opinion sur le sujet :

- via base de données : à moins qu'il s'agisse d'une base fichier très rapide, sans phase de connexion, comme sqlite par exemple, ça n'a pas grand intérêt à mon sens. En effet rien que l'étape de connexion à la base de données est très couteuse, donc les gains risquent de prendre une claque.

- via fichiers .php + include : là le résultat va dépendre fortement de l'utilisation d'un cache d'opcode ou non (eAccelerator, Zend Optimizer, etc). Si tu n'utilises pas de cache d'opcode, ton script de cache devra être "compilé" à chaque inclusion... une catastrophe en termes de temps CPU . Et si tu utilises justement un cache d'opcode, selon la quantité de données de cache tu risques vite de saturrer la mémoire allouée au système en question, et au final pénaliser tous les scripts hebergés.

- via fichier raw (bruts) : une très bonne solution à mon avis... à condition que le système de fichier soit local. En effet chez certains hebergeurs le système de fichier est déporté sur un "filer" via NFS ; et dans ce cas les écritures seront surement assez lentes, et tu risques de rencontrer des problèmes de synchronisations entre les différents nodes du "cluster".

- via mémoire : d'un point de vue performance, c'est certainement la solution la plus rapide. De nombreuses API existent, eAccelerator en propose justement une, qui a l'avantage de pouvoir compresser les données en mémoire ce qui permet d'avoir un équilibre entre "consommation mémoire" et "gain de performance". Il gère également de lui même les verrous, donc son utilisation est très simple.
Toutefois il est possible de le faire soit même via les fonctions SHM et sémaphores de PHP. Coté clustering, les solutions "mémoire déportée" du style memcached peuvent également être utilisées.



Sur mon site j'ai tendance à mixer plusieurs méthodes : les données necessaires très fréquement sont en mémoire, celles qui sont "régulières" sont en fichier, et les "répétitives mais pas tellement fréquentes" sont dans des champs en supplémentaires des tables existantes des bases de données.


......

j'espère t'avoir éclairé un peu sur le sujet... sans être trop sorti du sujet (c'est un sujet qui me tient à coeur )



PS : dark j'ai moi même développé plusieurs systèmes de cache... j'avais d'ailleurs rendu publique une partie des sources, je t'en fais volontiers cadeau si tu veux t'en inspirer ou modifier ou utiliser ou même jetter

[genova]

Je suis effectivement intéressé par tes sources pour voir un peu le fonctionement de tout ça, n'hesites pas a me donenr le lien par MP ou sur le topic ^^

Merci pour les explications