Конечно, «проверенный, сертифицированный» бит хорош в некоторых средах. В нашем случае требования аудита состоят в том, что мы либо используем сертифицированный программный стек, либо действуем самостоятельно, но должны показать, что делаем быстрые обновления для каждого небольшого компонента, который в него входит. Итак, для здравомыслия мы исторически придерживались стандартных предложений дистрибутивов Linux. Проблема в том, что они, как правило, отстают на несколько лет. Например, большинство дистрибутивов только недавно приняли PHP 5.3 после того, как застряли с 5.1 (!). Это просто неприемлемо, когда вы пытаетесь разработать современные приложения, использующие современные методы кодирования, плюс вы теряете кучу средств с точки зрения производительности и надежности PHP.
Сказав это, функции тоже довольно хороши. @Keven уже упомянул очередь работы. Это замечательно для нас, поскольку мы можем очень легко разгрузить все виды задач, которые выполняются асинхронно и поддерживают выполнение основного запроса. Например, одно из наших приложений создает задачи в нашем трекере ошибок, когда происходят определенные типы событий. Поскольку это выполняется веб-службой, а система отслеживания ошибок работает ужасно медленно, это может занять несколько секунд. Однако вместо того, чтобы заставлять пользователей нашего приложения ждать, мы просто ставим в очередь задание и запускаем его в фоновом режиме. Аналогично, наш стандартный класс электронной почты использует очередь заданий, а не заставляет пользователя ждать, пока наш код общается с SMTP-сервером. И все это даже не касается полезности таких вещей, как создание больших отчетов, проверка целостности базы данных, восстановление кешей и т. Д. И т. Д.
Кеш страниц отлично подходит для тех случаев, когда вы можете просто кешировать целую страницу и покончить с ней. Мы используем это с нашими WSDL, так как у нас больше контроля, чем у собственных элементов управления кэшированием в PHP. Кроме того, сервер загрузки отлично подходит для кэширования определенных типов контента, таких как изображения. И мы используем кеш данных, как локальный сервер memcached, чтобы значительно ускорить все виды запросов, избегая выполнения запросов к медленному серверу базы данных, который находится где-то еще в медленной сети.
И, конечно, как упоминает @ Андре, в нем есть несколько замечательных функций отладки, трассировки и отчетов о событиях.
Есть также несколько приятных функций для развертывания и отката, которые очень важны для критически важных бизнес-приложений. Я собираюсь попробовать их когда-нибудь, но сейчас я все еще использую инструменты, которые я собрал до использования ZS.
Теперь вы можете получить большинство из этих функций (в частности, все биты кэширования), объединяя различные другие инструменты. Но затем вы должны исследовать и изучить все эти вещи, установить их все и работать вместе, а затем поддерживать их все, включая проведение надлежащего интеграционного тестирования, когда что-то обновляется. Это много работы и времени - время, которое я лично предпочел бы потратить на написание кода.
Сказав все это, есть недостатки. С одной стороны, вещи иногда кажутся ... недоделанными и / или непродуманными. Например, API кэша данных возвращает логическое значение false, если вы пытаетесь получить элемент, который не существует. И, у него нет функции для проверки, существует ли элемент без извлечения. Угадайте, что это значит: вы не можете безопасно хранить логическое значение, потому что вы не можете безопасно получить его. Он включает плохо документированный уровень совместимости APC, но попытка использовать функцию существования из APC приводит к ошибке неопределенной функции.
В качестве другого примера, мы используем Маки для наших станций разработки, но из-за крайне ошибочной озабоченности по поводу совместимости с древним оборудованием, которое, как правило, используют все те профессиональные разработчики, которые сбрасывают тысячи на серверное программное обеспечение PHP, выбрал Zend поставлять версию Mac (предназначенную только для разработки) как 32-битную только . Таким образом, мы вынуждены разрабатывать приложения в 32-разрядной версии, которые работают везде в 64-разрядной версии. Это вызвало немало ошибок и неудачных автоматических тестов в нашем приложении, что, скорее, убивает одну из основных целей ZS - идентичный программный стек в средах разработки, тестирования, тестирования, тестирования и производства. Я пытался уговорить их изменить это, но они быстро начали игнорировать меня.
Еще один важный момент: очередь заданий может обрабатывать задания только через HTTP-запросы. API настроен для разрешения других методов (например, гораздо более разумного вызова командной строки), но HTTP - это все, что работает. Это заставляет вас связывать подключения к веб-серверу с задачами, которые по своей природе, как правило, имеют длительный характер и поэтому должны быть исключены из веб-контекста. И это заставляет вас прыгать через обручи, чтобы не дать миру возможность запускать ваши задания, посещая URL-адрес в браузере. Это просто глупое решение.
Другими примерами являются плохая обработка пользовательских событий, отправляемых через API в Zend Monitor, обертку php-cli для двоичного файла PHP, которая ломается на Mac при запуске по строке shebang, полное (полное) отсутствие отчетов о работоспособности и производительности в инструментах кэширования (хотя они сказали, что это меняется в ZS 6) и смущающе неполной документации. Я мог бы продолжить ....
Теперь те недостатки, а также потраченное впустую время и ресурсы, которые приходят вместе для поездки, очевидно, не перевесили преимущества для нас, но из-за количества денег, которые мы тратим, я определенно ожидаю большего.