Cache de page dans PHP qui gère la concurrence?

1. Sous Linux, généralement, le fichier restera "ouvert" à lire, même s'il est "supprimé" jusqu'à ce que le processus ferme le fichier. C'est quelque chose intégré au système et peut parfois causer d'énormes divergences dans des tailles d'utilisation des disques (supprimant un fichier 3G pendant qu'il est toujours "ouvert" signifierait toujours alloué sur le disque comme utilisé jusqu'à ce que le processus ferme jusqu'à la fermeture du processus) - I ' m ne sachant pas si la même chose est vraie sous Linux.
2. En supposant un système de fichiers de journaux (la plupart des systèmes de fichiers Linux et NTFS) - alors le fichier ne doit pas être vu comme "créé" tant que le processus ferme le fichier. Cela devrait apparaître comme un fichier non existant!

Assumer un système de fichiers de journaux (la plupart des systèmes de fichiers Linux et NTFS) - Ensuite, le fichier ne doit pas être considéré comme «créé» jusqu'à ce que le processus ferme le fichier. Cela devrait apparaître comme un fichier non existant!

Nope, il est visible dès sa création, vous devez le verrouiller. Renommer est atomique cependant. Donc, vous pourriez ouvrir (), écrire (), fermer (), renommer (), mais cela n'empêchera pas le même élément de cache recréé deux fois en même temps.

Un fichier mis en cache a été supprimé car il était obsolète. Une demande de ce fichier est entrée et le fichier est en cours de recréer. Une autre demande pour le fichier est disponible pendant cela.

S'il n'est pas verrouillé, un fichier demi-complet sera servi ou deux processus essaieront de régénérer le même fichier en même temps, donnant des résultats «intéressants».

Il semble que la poire :: Cache_Lite a une sorte de sécurité pour traiter des problèmes de concurrence.
Si vous regardez le manuel de constructeur cache_lite :: cache_lite , vous avez ces options:

fillocking Activer / désactiver la filocage. Peut éviter la corruption cache sous mal circonstances.

WriteControl Activer / désactiver le contrôle d'écriture. Activer le contrôle d'écriture sera légèrement lent l'écriture de cache mais pas la cache en train de lire. La commande d'écriture peut détecter certains fichiers de cache corrompus mais peut-être que ce n'est pas un contrôle parfait.

readcontrol Activer / désactiver le contrôle de lecture. Si activé, une clé de contrôle est incorporée dans Le fichier de cache et cette clé est comparé avec celui calculé après le Lecture

readcontroltype Type de contrôle de lecture (uniquement si le contrôle de lecture est activé). Doit être 'MD5' (pour un contrôle de hachage MD5 (meilleur mais le plus lent)), 'CRC32' (pour un hachage de CRC32 contrôle (légèrement moins sûr mais plus rapide)) ou 'strylen' (pour une longueur seul test (le plus rapide))

Lequel utiliser est toujours à vous et dépendra de quel type de performance vous êtes prêt à être sacrifié - et le risque d'accès à la concurrence qui existe probablement dans votre application.

Vous voudrez peut-être aussi jeter un coup d'œil à zend_cache_fronttend_output , pour mettre en cache une page, en utilisant quelque chose comme zend_cache_backend_file comme backend.

Celui-là semble supporter une sorte de sécurité aussi - le même kinf de choses que cache_lite vous a déjà donné (donc je ne copierai pas-coller une seconde fois) < / em>


En tant que SidENOTE, si votre site Web s'exécute sur un hôte partagé, je suppose qu'il n'a pas que beaucoup d'utilisateurs ? De sorte que les risques d'accès simultané ne sont probablement pas si élevés, sont-ils?

Quoi qu'il en soit, je ne rechercherais probablement pas plus loin que ce que ces cadres de remorquage proposent: il est déjà probablement plus que suffisant pour répondre à vos besoins: -)

(je n'ai jamais vu aucun mécanisme de mise en cache "plus sûr" que ce qui vous permet de faire ... et je n'ai jamais rencontré un problème de concurrence catastrophique de ce type encore ... dans 3 ans de php-développement)


Quoi qu'il en soit: amusez-vous!