Certes, l'aspect "testé, certifié" est appréciable dans certains environnements. Dans notre cas, les exigences en matière d'audit sont les suivantes : soit nous utilisons une pile logicielle certifiée, soit nous nous débrouillons seuls, mais nous devons montrer que nous effectuons des mises à jour rapides de chaque petit composant qui l'alimente. Donc, pour des raisons de bon sens, nous avons toujours utilisé les offres standard des distributions Linux. Le problème est qu'elles ont tendance à avoir des années de retard. Par exemple, la plupart des distributions n'ont adopté que récemment PHP 5.3 après être restées sur la version 5.1 ( !). C'est tout simplement inacceptable lorsque vous essayez de développer des applications modernes qui utilisent des techniques de codage modernes, et vous perdez beaucoup en termes de performances et de fiabilité de PHP.
Cela dit, les fonctionnalités sont également très intéressantes. @Keven a déjà mentionné la file d'attente des travaux. C'est génial pour nous, dans la mesure où nous pouvons très facilement décharger toutes sortes de tâches qui s'exécutent de manière asynchrone et garder le processus de requête principal en marche. Par exemple, l'une de nos applications crée des tâches dans notre système de suivi des bogues lorsque certains types d'événements se produisent. Comme cela se fait par service web, et que le bug tracker est horriblement lent, cela peut prendre plusieurs secondes. Cependant, plutôt que de faire attendre les utilisateurs de notre application, nous mettons simplement en file d'attente une tâche et la laissons s'exécuter en arrière-plan. De même, notre classe de messagerie standard utilise la file d'attente des tâches plutôt que de faire attendre l'utilisateur pendant que notre code communique avec un serveur SMTP. Et tout cela sans même parler de l'utilité pour des choses comme la génération de rapports volumineux, l'exécution de contrôles d'intégrité de bases de données, la reconstruction de caches, etc. etc.
Le cache de page est idéal pour les cas où vous pouvez simplement mettre en cache une page entière et en finir avec elle. Nous l'utilisons avec nos WSDL, car nous avons un meilleur contrôle que les contrôles de cache de PHP. De même, le serveur de téléchargement est merveilleux pour mettre en cache certains types de contenu, comme les images. Et nous utilisons le cache de données comme un serveur memcached local pour accélérer considérablement toutes sortes de requêtes en évitant d'interroger un serveur de base de données lent situé ailleurs sur un réseau lent.
Et bien sûr, comme le mentionne @André, il existe de très belles fonctionnalités de débogage, de traçage et de rapport d'événements.
Il existe également des fonctionnalités intéressantes pour les déploiements et les retours en arrière, qui sont très importants pour les applications critiques. J'ai l'intention de les essayer un jour, mais pour l'instant, j'utilise toujours les outils que j'ai mis en place avant d'utiliser ZS.
Aujourd'hui, vous pouvez obtenir la plupart de ces fonctionnalités (en particulier, tous les éléments de mise en cache) en bricolant une variété d'autres outils. Mais vous devez ensuite rechercher et apprendre toutes ces choses, les installer et les faire fonctionner ensemble, puis en assurer la maintenance, notamment en effectuant des tests d'intégration appropriés lors des mises à jour. C'est une lot de travail et de temps -- temps que je préférerais personnellement passer à écrire du code.
Cela dit, il y a des inconvénients. Tout d'abord, les choses semblent parfois... mal conçues et/ou peu élaborées. Par exemple, l'API du cache de données renvoie le booléen false si vous essayez de récupérer un élément qui n'existe pas. Et elle ne dispose d'aucune fonction permettant de vérifier si un élément existe sans qu'il soit nécessaire de le récupérer. Devinez ce que cela signifie : vous ne pouvez pas stocker en toute sécurité une valeur booléenne car vous ne pouvez pas la récupérer en toute sécurité. Il inclut une couche de compatibilité APC mal documentée, mais essayer d'utiliser la fonction d'existence d'APC produit une erreur de fonction non définie.
Comme autre exemple, nous utilisons des Macs pour nos stations de développement, mais par souci de compatibilité avec le matériel ancien qui tend à être utilisé par tous ces développeurs professionnels qui dépensent des milliers de dollars pour un logiciel de serveur PHP, Zend a choisi de livrer la version Mac (qui n'est destinée qu'au développement) en 32-bit. sólo . Nous sommes donc obligés de développer une application en 32 bits qui fonctionne partout ailleurs en 64 bits. Cela a provoqué un certain nombre de bogues et d'échecs de tests automatisés dans notre application, ce qui va à l'encontre de l'un des principaux objectifs de ZS, à savoir une pile logicielle identique dans les environnements de développement, de test, de stockage, d'assurance qualité et de production. J'ai essayé de les convaincre de changer cela, mais ils ont rapidement commencé à m'ignorer.
Un autre point important est que la file d'attente des travaux ne peut traiter les travaux que par le biais de requêtes HTTP. L'API est configurée pour permettre d'autres méthodes (comme l'appel en ligne de commande, beaucoup plus raisonnable), mais HTTP est la seule méthode qui fonctionne. Cela vous oblige à bloquer les connexions au serveur web avec des tâches qui, par conception, ont tendance à être longues et doivent donc être effectuées hors du contexte web. Et cela vous oblige à faire des pieds et des mains pour empêcher le monde entier de déclencher vos tâches en visitant une URL dans un navigateur. C'est tout simplement une décision stupide.
D'autres exemples sont la mauvaise gestion des événements personnalisés envoyés via l'API à Zend Monitor, le wrapper php-cli pour le binaire PHP qui se casse sur le Mac lorsqu'il est déclenché par la ligne shebang, l'absence totale de rapports sur la santé et les performances dans les outils de cache (bien qu'ils aient dit que cela allait changer dans ZS 6), et la documentation embarrassante et incomplète. Je pourrais continuer ainsi....
Ces inconvénients, ainsi que les pertes de temps et de ressources qu'ils entraînent, ne l'emportent évidemment pas sur les avantages pour nous, mais pour la somme d'argent que nous dépensons, je m'attends vraiment à plus.
