opcache gui
Public release 3.5.5
Une interface propre et réactive pour les informations Zend OPcache, affichant les statistiques, les paramètres et les fichiers mis en cache, et fournissant une mise à jour en temps réel des informations.
Cette interface utilise ReactJS et Axios et est destinée aux navigateurs modernes et nécessite un minimum de PHP 7.1.
MIT : http://acollington.mit-license.org/
Si vous êtes en mesure et souhaitez sponsoriser ce travail d'une manière ou d'une autre, ce serait super génial. Vous pouvez le faire via la page de parrainage de GitHub.
Alternativement, si vous souhaitez simplement me remercier sur X (alias Twitter) pour me dire que vous l'utilisez, ce serait génial aussi ! (Quelqu’un d’autre manque-t-il de cartes postales ?)
Il existe deux manières de commencer à utiliser cette interface graphique :
Le moyen le plus simple de commencer à utiliser opcache-gui est de cloner ce dépôt, ou simplement de copier/coller/télécharger le fichier index.php dans un emplacement que votre serveur Web peut charger. Pointez ensuite votre navigateur vers cet emplacement, par exemple https://www.example.com/opcache/index.php .
Vous pouvez inclure les fichiers avec Composer en exécutant la commande composer require amnuts/opcache-gui .
Une fois dans votre répertoire vendor , vous pouvez utiliser l'interface de nombreuses manières. Par exemple, si vous utilisez un framework tel que Symfony ou Laravel, vous pouvez charger opcache-gui dans un Controller . Vos exigences en matière de configuration dans le cadre de votre choix varieront, il n'est donc pas vraiment possible de détailler comment procéder dans ce fichier Lisez-moi... mais j'ai confiance en votre capacité à le comprendre !
L'espace de noms utilisé pour la classe est AmnutsOpcache , donc une fois la dépendance dans votre autoload.php vous pouvez utiliser la classe AmnutsOpcacheService . Par exemple, vous pourriez faire quelque chose comme :
<?php
use Amnuts Opcache Service ;
// assuming location of: /var/www/html/opcache.php
require_once __DIR__ . ' /../vendor/autoload.php ' ;
// specify any options you want different from the defaults, if any
$ options = [ /* ... */ ];
// setup the class and pass in your options, if you have any
$ opcache = ( new Service ( $ options ))-> handle ();Ensuite, vous pouvez créer la vue de votre choix pour afficher les détails du cache opcache. Bien qu'il existe une interface assez soignée basée sur React disponible pour vous dans ce référentiel.
Vous pouvez également inclure directement vendor/amnuts/opcache-gui/index.php et cela vous donnera le même résultat que de simplement copier/coller le index.php quelque part.
<?php
// assuming location of: /var/www/html/opcache.php
require_once __DIR__ . ' /../vendor/amnuts/opcache-gui/index.php ' ; Vous pouvez même simplement créer un lien symbolique vers le index.php qui se trouve dans le répertoire vendor :
ln -s /var/www/vendor/amnuts/opcache-gui/index.php /var/www/html/opcache.phpFondamentalement, il existe de nombreuses façons de rendre l'interface opérationnelle : choisissez celle qui correspond à vos besoins.
La configuration par défaut de l'interface ressemble à ceci :
$ options = [
' allow_filelist ' => true , // show/hide the files tab
' allow_invalidate ' => true , // give a link to invalidate files
' allow_reset ' => true , // give option to reset the whole cache
' allow_realtime ' => true , // give option to enable/disable real-time updates
' refresh_time ' => 5 , // how often the data will refresh, in seconds
' size_precision ' => 2 , // Digits after decimal point
' size_space ' => false , // have '1MB' or '1 MB' when showing sizes
' charts ' => true , // show gauge chart or just big numbers
' debounce_rate ' => 250 , // milliseconds after key press to send keyup event when filtering
' per_page ' => 200 , // How many results per page to show in the file list, false for no pagination
' cookie_name ' => ' opcachegui ' , // name of cookie
' cookie_ttl ' => 365 , // days to store cookie
' datetime_format ' => ' D, d M Y H:i:s O ' , // Show datetime in this format
' highlight ' => [
' memory ' => true , // show the memory chart/big number
' hits ' => true , // show the hit rate chart/big number
' keys ' => true , // show the keys used chart/big number
' jit ' => true // show the jit buffer chart/big number
],
// json structure of all text strings used, or null for default
' language_pack ' => null
]; Si vous souhaitez modifier l'une des valeurs par défaut, vous pouvez transmettre uniquement celles que vous souhaitez modifier si vous souhaitez conserver le reste tel quel. Modifiez simplement le tableau en haut du script index.php (ou transmettez le tableau différemment à la classe Service ).
Par exemple, ce qui suit modifierait uniquement les allow_reset refresh_time mais conserverait tout le reste par défaut :
$ opcache = ( new Service ([
' refresh_time ' => 2 ,
' allow_reset ' => false
]))-> handle ();Ou cet exemple pour donner aux onglets un côté un peu plus « pirate » :
$ opcache = ( new Service ([
' language_pack ' => <<<EOJSON
{
"Overview": "Crows nest",
"Cached": "Thar Booty",
"Ignored": "The Black Spot",
"Preloaded": "Ready an' waitin', Cap'n",
"Reset cache": "Be gone, yer scurvy dogs!",
"Enable real-time update": "Keep a weathered eye",
"Disable real-time update": "Avert yer eyes, sea dog!"
}
EOJSON
]))-> handle ();L’aperçu vous montrera toutes les informations de base. De là, vous pourrez voir sur quel hôte et quelle plate-forme vous utilisez, quelle version d'OPcache vous utilisez, quand sa dernière réinitialisation, les fonctions et directives disponibles (avec des liens vers le manuel php.net), et toutes les statistiques associées à l'OPcache (nombre de hits, mémoire utilisée, mémoire libre et gaspillée, et plus encore).
Tous les fichiers actuellement dans le cache sont répertoriés ici avec leurs statistiques associées.
Vous pouvez filtrer les résultats pour vous aider à trouver les scripts particuliers que vous recherchez et modifier la façon dont les fichiers mis en cache sont triés. À partir de là, vous pouvez invalider le cache pour des fichiers individuels ou invalider le cache pour tous les fichiers correspondant à votre recherche.
Si vous ne souhaitez pas du tout afficher la liste des fichiers, vous pouvez utiliser l'option de configuration allow_filelist ; le définir sur false supprimera complètement la liste des fichiers.
Si vous souhaitez ajuster la longueur de la pagination, vous pouvez le faire avec l'option de configuration per_page .
Si vous avez configuré une liste de fichiers que vous ne souhaitez pas mettre en cache en fournissant une valeur opcache.blacklist_filename , alors la liste des fichiers sera répertoriée dans cet onglet.
Si vous n'avez pas fourni cette option de configuration dans le fichier php.ini alors cet onglet ne sera pas affiché. Si vous définissez l'option de configuration allow_filelist sur false , cet onglet ne sera pas affiché quel que soit votre paramètre ini.
PHP 7.4 a introduit la possibilité de précharger un ensemble de fichiers au démarrage du serveur via le paramètre opcache.preload dans votre fichier php.ini . Si vous l'avez configuré, la liste des fichiers spécifiquement préchargés sera répertoriée dans cet onglet.
Comme pour le fichier ignoré, si vous n'avez pas fourni le paramètre ini ou si l'option de configuration allow_filelist est false , alors cet onglet ne sera pas affiché.
Vous pouvez réinitialiser l'intégralité du cache et forcer l'invalidation de fichiers individuels ou de groupes de fichiers afin qu'ils soient à nouveau mis en cache.
La réinitialisation peut être désactivée à l'aide des options de configuration allow_reset et allow_invalidate .
L'interface peut interroger de temps en temps pour avoir un nouveau regard sur l'opcache. Vous pouvez modifier la fréquence à laquelle cela se produit avec l'option de refresh_time , qui est en secondes.
Lorsque les mises à jour en temps réel sont actives, l'interface mettra automatiquement à jour toutes les valeurs selon les besoins.
De plus, si vous choisissez d'invalider des fichiers ou de réinitialiser le cache, cela se fera sans recharger la page, de sorte que le terme de recherche que vous avez saisi ou la page vers laquelle vous avez navigué ne seront pas réinitialisés. Si la mise à jour en temps réel n'est pas activée, la page se rechargera en cas d'utilisation d'invalidation.
L'interface a été conçue autour du principe d'avoir un seul fichier dont tout le monde a besoin pour être opérationnel. Pour cela, il existe un fichier modèle, des fichiers de langue, jsx et css, qui sont tous utilisés pour créer l'interface et rassemblés dans le processus de construction.
Ce processus de construction vous permettra de modifier le langage utilisé, la manière dont les bibliothèques javascript tierces requises sont incluses, l'apparence, ou même les composants de base, si vous le souhaitez.
Pour exécuter le processus de construction, exécutez la commande php ./build/build.php à partir de la racine du dépôt (vous aurez besoin nodejs et npm déjà installés). Une fois exécuté, vous devriez voir le résultat quelque chose comme :
Installing node modules
Building js and css
Creating single build file
Using remote js links from 'cloudflare'
Done!
Le script de build n'aura besoin d'installer les node_modules qu'une seule fois, donc lors des builds suivants, cela devrait être un peu plus rapide !
Le processus de construction créera un fichier CSS compilé dans build/interface.css et le javascript de l'interface sera dans build/interface.js . Vous pouvez probablement utiliser ces deux éléments dans vos propres frameworks et systèmes de modèles, si vous le souhaitez.
Le CSS de l'interface se trouve dans le fichier build/_frontend/interface.scss . Apportez-y des modifications si vous souhaitez modifier les couleurs ou la mise en forme.
Si vous apportez des modifications au fichier scss, vous devrez exécuter le script de construction afin de voir les modifications.
Si vous souhaitez modifier l'interface elle-même, mettez à jour le fichier build/_frontend/interface.jsx - il s'agit essentiellement d'un ensemble de composants ReactJS. C'est ici que vous pouvez modifier la disposition des widgets, le fonctionnement de la liste des fichiers, la pagination, etc.
Exécutez à nouveau le script de construction si vous apportez des modifications ici.
Le modèle PHP wrapper utilisé dans le processus de construction, et qui sert à transmettre divers bits de données au côté ReactJS, se trouve dans build/template.phps . Si vous souhaitez mettre à jour la version de ReactJS utilisée ou la façon dont le wrapper HTML est structuré (par exemple, vouloir transmettre des éléments supplémentaires au côté ReactJS), alors ce serait le fichier que vous voudriez mettre à jour.
L'interface nécessite quelques fichiers js tiers pour fonctionner correctement. Vous avez la possibilité de changer l'endroit où ils sont récupérés (entre CloudFare, JSDelivr et Unpkg), ou vous pouvez avoir js js complètement local et en ligne (par exemple, vous avez des politiques CSP en place et les URL distantes sont pas sur liste blanche).
Afin de modifier l'emplacement des ressources tierces, utilisez l'option -r ou --remote-js suivie de cloudflare , jsdelivr ou unpkg . Par exemple, si vous souhaitez utiliser jsdelivr , vous exécuterez la commande build comme ceci : php ./build/build.php -r jsdelivr . La valeur par défaut est cloudflare .
Si vous souhaitez avoir le js en ligne, vous pouvez utiliser l'indicateur -j ou --local-js lors de la construction, comme php ./build/build.php -j . Cela récupérera les fichiers de script distants et intégrera le js dans le fichier index.php principal. Si vous souhaitez le reconstruire avec des fichiers distants, exécutez à nouveau la commande sans l'indicateur. La récupération des fichiers prendra en compte votre option -r si vous la fournissez.
Il y a un vieux dicton qui dit : « Si vous connaissez plus d’une langue, vous êtes multilingue, sinon vous êtes britannique ». Non seulement c'est une condamnation accablante de la mentalité britannique à l'égard des autres langues, mais cela explique également pourquoi l'interface utilisateur n'a été jusqu'à présent qu'en anglais - parce que je suis, malgré tous mes péchés, britannique.
Cependant, il est désormais possible de construire l'interface avec un langage différent. Actuellement, grâce aux contributeurs, le français et l'espagnol sont également pris en charge. Si quelqu'un d'autre souhaite contribuer à des packs de langues supplémentaires, veuillez soumettre un PR !
Si le module linguistique se trouve dans le répertoire build/_languages/ , vous pouvez l'utiliser avec l'indicateur -l ou --lang . Par exemple, s'il existe un pack de langue fr.json , vous pouvez utiliser php ./build/build.php -l fr afin de construire avec ce langage.
Quelques scripts de compositeur ont été ajoutés pour aider à la construction. Il s'agit de composer build , composer build-french et composer build-spanish .
Si vous souhaitez créer un fichier de langue, build/_languages/example.json contient tout ce dont vous avez besoin. Il s'agit d'une structure json simple dont la clé est la version anglaise qui correspond à ce qui se trouve dans l'interface utilisateur, et la valeur correspond à ce en quoi vous la convertissez - ce qui dans le fichier d'exemple est simplement vide. Si une valeur est vide ou si l'index n'existe pas pour une traduction, alors elle utilisera simplement la version anglaise. Cela vous donne la possibilité de remplacer tout ou partie des chaînes d’interface comme bon vous semble.
Pour commencer avec une nouvelle langue, copiez le example.json dans la langue de votre choix qui n'existe pas déjà - par exemple, pt-br.json ou pirate.json . Remplissez ensuite les traductions dans les valeurs. Une fois cela fait, reconstruisez avec php ./build/build.php -l pt-br ou php ./build/build.php -l pirate .
Version 3.5.5
Ajout de traductions espagnoles grâce à @cvc90 (PR#110)
Version 3.5.4
Meilleure gestion de l'activation ou de la désactivation de JIT. Montre désormais également pourquoi il peut être désactivé même si le paramètre est activé. L'interface désactive également correctement les statistiques de graphique et de mémoire pour JIT si elles sont désactivées pour une raison quelconque.
Version 3.5.3
Correction de certaines incohérences avec les liens dans la documentation opcache sur php.net.
Version 3.5.2
Suppression de certains avertissements pour PHP 8.2 en supprimant les instructions namespace et use dans le fichier index.php fourni.
Version 3.5.1
Il ne s'agit que de la version 3.5.0 mais avec des balises de version corrigées pour rendre Packagist heureux et corriger mon erreur.
Version 3.5.0
Cette version modifie la façon dont le processus de construction inclut le javascript.
-j / --local-js intègre désormais le javascript dans le fichier index.php plutôt que de les avoir dans des fichiers séparés-r / --remote-js a été ajoutée pour vous permettre de décider d'où vous obtenez les fichiers tiers (soit lorsqu'ils sont récupérés localement, soit lorsqu'ils sont ajoutés en tant que liens de script distants), avec cloudflare , jsdelivr ou unpkg étant disponible choix Version 3.4.0
Cette version ajoute un peu plus d'informations sur les fichiers dans le cache et permet un peu plus de configuration via le script de configuration et de construction.
datetime_format pour un formatage flexible des valeurs de date/heuremodified du fichier mis en cache à la sortie (lorsque le fichier a été ajouté ou mis à jour)index.php avec les fichiers js locaux plutôt qu'avec les URL distantes Version 3.3.1
Juste quelques petites modifications :
Version 3.3.0
Informations JIT principalement ajoutées pour PHP 8 :
falseSi vous souhaitez activer JIT, vous devez saisir une valeur pour le paramètre ini opcache.jit_buffer_size, sinon il est désactivé par défaut.
Si vous n'utilisez pas PHP 8, l'interface compensera et n'affichera pas les informations JIT supplémentaires.
Version 3.2.1
Version de maintenance mineure pour :
Version 3.2.0
Mise à jour de ReactJS vers les versions minifiées les plus récentes et utilisées et légère amélioration de l'option de tri lorsqu'aucune pagination n'est présente.
Version 3.1.0
Ajout de la possibilité de trier la liste des fichiers mis en cache de différentes manières.
Version 3.0.1
Une mise à jour mineure qui utilisera http ou https pour obtenir les bibliothèques javascript, selon ce que vous utilisez.
Version 3.0.0
Bien que l’interface soit pratiquement la même, elle a été complètement réécrite sous le capot ! Certains des changements les plus notables sont :
Version 2.5.4
Placement raffiné de l'espace de noms CSS initial pour fonctionner correctement dans le plugin Moodle et éventuellement d'autres systèmes. J'ai également modifié certains CSS.
Version 2.5.3
Les noms de classes CSS ont été ajoutés et les règles de style mises à jour pour les utiliser.
Version 2.5.2
Correctif pour les valeurs optimisation_level publié dans la v2.5.1.
Version 2.5.1
Quelques corrections de bugs et amélioration des détails du niveau d'optimisation.
Version 2.5.0
Ajout d'un nouveau graphique de surbrillance pour afficher le pourcentage de clés mises en cache avec des options pour activer/désactiver les graphiques de surbrillance individuels.
Version 2.4.1
Principalement des corrections de bugs
memory_consumption et max_file_size s'affichent désormais sous forme de tailles lisibles par l'homme.file_cache_only est actif Version 2.4.0
Ajoute un magasin de cookies pour l'état en temps réel permettant d'activer le temps réel au chargement. Le nom du cookie et la longueur TTL peuvent être ajustés dans la configuration
Version 2.3.0
Ajoute des informations sur les chaînes internes et la compatibilité PHP 5.4
Version 2.2.2
Apporte des optimisations pour la liste des fichiers lors du filtrage
Version 2.2.1
Les jauges sont-elles désormais mises à jour avec l'impulsion en temps réel et quelques problèmes d'arrondi ont-ils été résolus ?
Version 2.2.0
Offre la possibilité d'activer/désactiver la liste de fichiers (la valeur par défaut est activée)
Version 2.1.0
Fournit désormais un moyen beaucoup plus simple de configurer certaines options, qu'il s'agisse de l'heure d'interrogation, de la possibilité de réinitialiser le cache, des mises à jour en temps réel, etc. Il vous permet également d'afficher les grandes valeurs (utilisation de la mémoire et taux de réussite) sous forme de jauge. des graphiques au lieu de grands nombres.
Version 2.0.0
L'introduction de React.js offre la possibilité de mettre à jour de manière transparente davantage d'informations en temps réel (enfin, toutes les cinq secondes par défaut) - les fichiers ainsi que la vue d'ensemble sont désormais actualisés. Il y a un look mis à jour, supprimant les dégradés et optant pour une sensation plus plate. Et le code en général a fait l’objet d’une refonte.
Les versions de l'interface graphique sont disponibles à l'adresse :
https://github.com/amnuts/opcache-gui/releases/
Un certain nombre de personnes se demandent si opcache-gui fonctionne sur leur instance de PHP-FPM, car les fichiers affichés ne semblent pas être tout ce qui est mis en cache, et c'est différent de ce qu'Apache pourrait afficher.
Essentiellement, c'est un comportement attendu. Et grâce à un excellent commentaire du contributeur Michalng, cette explication devrait couvrir la différence :
L'interface ne peut afficher que ce qu'elle sait sur l'utilisation OPcache de sa propre instance OPcache. Par conséquent, lorsqu'elle est accessible via Apache avec mod_php, elle ne peut voir que l'utilisation OPcache de cette instance OPcache du serveur Web Apache. Lorsqu'on y accède avec CGI classique, il ne peut se voir mis en cache qu'au fur et à mesure qu'une nouvelle instance PHP et OPcache est créée, auquel cas OPcache lui-même n'a souvent aucun sens.
Pour pouvoir surveiller et gérer l'OPcache pour toutes les applications Web, toutes doivent utiliser la même instance FastCGI, c'est-à-dire PHP-FPM.
Dans le cas d'Apache, il faut alors souvent le configurer activement pour ne pas utiliser son mod_php interne mais envoyer les requêtes du gestionnaire PHP au serveur PHP-FPM partagé via mod_proxy_fcgi, ce qui nécessite également l'utilisation de l'événement MPM. De nos jours, cette configuration est généralement considérée comme la configuration préférée, en particulier pour les sites Web à fort trafic. En effet, chaque requête entrante avec MPM prefork + mod_php crée son propre processus enfant prenant du temps et de la mémoire supplémentaires, tandis qu'avec l'événement MPM et le serveur PHP-FPM dédié, un thread de gestionnaire (généralement) déjà en attente est utilisé sur Apache et du côté PHP, ne consommant presque pas de mémoire supplémentaire ni de temps pour la génération du processus.
Le script nécessite PHP 7.1 ou supérieur. Je ne suis pas tenté de rétrograder le code pour le rendre compatible avec la version 7.0, et j'espère que la plupart des gens l'auront déjà mis à niveau. Mais j'apprécie vraiment que parfois les gens n'aient tout simplement pas la possibilité de changer la version de PHP qu'ils utilisent parce que cela échappe à leur contrôle. Donc, si vous faites partie des malchanceux, vous pouvez apporter les modifications suivantes à index.php (ou Service.php et exécuter le script de construction). Pour les lignes :
public function getOption(?string $name = null)
public function getData(?string $section = null, ?string $property = null)
public function resetCache(?string $file = null): bool
Il s'agira simplement de supprimer le ? de chacun des paramètres.
