Ciertamente, el bit "probado y certificado" es agradable en algunos entornos. En nuestro caso, los requisitos de auditoría son que o bien utilizamos una pila de software certificado, o vamos por nuestra cuenta, pero tenemos que mostrar que estamos haciendo actualizaciones rápidas para cada pequeño componente que se alimenta de ella. Por lo tanto, para fines de cordura, históricamente hemos ido con las ofertas estándar de las distribuciones de Linux. El problema con esto es que tienden a estar años atrás de la curva. Por ejemplo, la mayoría de las distribuciones han adoptado recientemente PHP 5.3 después de haber quedado con 5.1 (!). Eso no es aceptable cuando estás tratando de desarrollar aplicaciones modernas que usan técnicas modernas de codificación, además de que estás renunciando a una tonelada en términos de rendimiento y confiabilidad de PHP.
Habiendo dicho eso, las características son bastante agradables también. @ Keven ya mencionó la cola de trabajos. Eso es increíble para nosotros, ya que podemos descargar fácilmente todo tipo de tareas que se ejecutan de forma asíncrona y mantienen el proceso de solicitud principal en vuelo. Como ejemplo, una de nuestras aplicaciones crea tareas en nuestro rastreador de errores cada vez que ocurren ciertos tipos de eventos. Como esto se realiza mediante un servicio web, y el rastreador de errores es tremendamente lento, esto puede llevar varios segundos. Sin embargo, en lugar de hacer que los usuarios de nuestra aplicación esperen, simplemente ponemos en cola un trabajo y lo dejamos en segundo plano. Del mismo modo, nuestra clase de correo electrónico estándar utiliza la cola de trabajos en lugar de hacer que el usuario espere mientras nuestro código habla con un servidor SMTP. Y todo eso ni siquiera toca la utilidad para cosas como generar informes grandes, ejecutar comprobaciones de integridad de base de datos, reconstruir cachés, etc., etc.
El caché de página es ideal para aquellos casos en los que simplemente puede almacenar en caché toda una página y hecho con eso Usamos esto con nuestros WSDL, ya que tenemos un mejor control que los propios controles de caché de PHP. Del mismo modo, el servidor de descarga es maravilloso para almacenar en caché ciertos tipos de contenido, como imágenes. Y usamos la memoria caché de datos como un servidor de memcached local para acelerar en gran medida todo tipo de solicitudes evitando hacer una consulta a un servidor lento de base de datos sentado en otro lugar de la red lenta.
Y, por supuesto, como menciona @ André, hay algunas funciones de depuración, seguimiento e informe de eventos muy agradables.
También hay algunas características interesantes para realizar implementaciones y reversiones, que son muy importantes en las aplicaciones críticas para la empresa. Tengo la intención de probar esto algún día, pero por ahora, todavía estoy usando las herramientas que preparé antes de usar ZS.
Ahora, puede obtener la mayoría de estas características (particularmente, todos los bits de almacenamiento en caché) combinando una variedad de otras herramientas. Pero debe investigar y aprender todas esas cosas, instalarlas y trabajar juntas, y luego mantenerlas todas, incluida la realización de pruebas de integración adecuadas cuando se actualice algo. Eso es lote de trabajo y tiempo - tiempo que prefiero gastar escribiendo código.
Habiendo dicho todo eso, hay desventajas. Por un lado, las cosas a veces se sienten ... a medio cocinar y/o mal concebidas. Por ejemplo, la API de caché de datos devuelve booleano falso si intenta buscar un elemento que no existe. Y no tiene ninguna función para verificar si un artículo existe sin recuperarlo. Adivina qué significa esto: no puedes almacenar con seguridad un valor booleano porque no puedes recuperarlo de manera segura. Incluye una capa de compatibilidad de APC pobremente documentada, pero tratar de usar la función de existencia de APC produce un error de función no definida.
Como otro ejemplo, podemos utilizar Macs para nuestras estaciones de desarrollo, pero debido a la preocupación en gran medida equivocada sobre la compatibilidad con el hardware antiguo, que tiende a ser ejecutado por todos los desarrolladores profesionales por ahí que abandonan miles de software de servidor PHP, Zend ha elegido para enviar la versión para Mac (que es sólo para el desarrollo) como de 32 bits solamente . Así que estamos obligados a desarrollar una aplicación en 32 bits que se ejecuta en cualquier otro lugar en 64 bits. Esto hizo que un buen número de errores y no pasaron las pruebas automatizadas en nuestra aplicación, que en lugar mata a uno de los propósitos principales de ZS, que es una pila de software idénticos a través de entornos de desarrollo, prueba, puesta en escena, control de calidad y producción. Traté de convencerlos de cambiar esto, pero rápidamente comenzaron a ignorarme.
Otro grande es que la cola de trabajos sólo puede procesar los trabajos a través de peticiones HTTP. La API está configurada para permitir otros métodos (como la llamada de línea de comando mucho más sensible), pero HTTP es todo lo que funciona. Esto lo obliga a vincular las conexiones del servidor web con tareas que, por diseño, tienden a ser de larga ejecución y, por lo tanto, deben eliminarse del contexto web. Y te obliga a saltar por los aro para evitar que el mundo pueda desencadenar tus trabajos visitando una URL en un navegador. Es solo una decisión estúpida.
Otros ejemplos son el mal manejo de eventos personalizados enviados mediante API a Zend Monitor, el envoltorio php-cli para el binario PHP que se rompe en la Mac cuando se desencadena por shebang line, la completa (absoluta) falta de salud y rendimiento informar en las herramientas de caché (aunque dijeron que esto está cambiando en ZS 6), y la documentación embarazosamente incompleta. Podría continuar ....
Ahora, esas desventajas, y el tiempo perdido y los recursos que vienen para el viaje, obviamente no han superado los beneficios para nosotros, sino por la cantidad de dinero que estamos gastando , Definitivamente espero más.