Zend 服务器体验
有一天，我正在研究 Zend Server，我想知道为什么要使用它？好吧，他们说这一切都经过测试、关键任务和企业准备就绪等。但对我来说，这只是营销部门在说。
有没有人使用该产品，如果是的话，您可以分享您的使用经验，也许您还可以详细说明为什么您为您的应用程序选择该产品的原因。
您是否发现使用 Zend 服务器有任何真正的好处？
The other day I was looking into Zend Server and I was wondering why I would use this? OK, they say it's all tested and mission critical and Enterprise ready etc. But to me that's just the marketing department talking.
Is anyone out there using this product and if so can you share your experiences with it and maybe you could also elaborate on the reason on why you choose this product for your application(s).
Did you find any real benefits to using Zend server?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我一直在使用 Zend Platform（我知道您在询问 Zend Server，我正在了解）并且非常热衷于使用 Zend Server 获得的错误报告工具。
每当发生错误或抛出异常时，Zend Server 都会存储尽可能多的相关信息（例如正在使用哪些请求参数、错误发生的位置、时间、错误消息、堆栈跟踪等）。
还向您报告脚本执行缓慢。
我真的更喜欢收到此类错误消息，而不是客户说：“该网站无法正常工作。请修复它”。
当将 Zend Server 与 Zend Studio 结合使用时，Zend Debugger 已经预装（但您也可以自己安装），这非常巧妙。
它还带有一个 php-java-bridge（你的 java 类可以在 PHP 中使用），但我不需要这个。
如果您的 Web 应用程序中已经有基于 php 的错误报告解决方案，或者对此没有任何用处，也没有 Java 桥接器，那么我想说，如果您使用 Zend Server 而不是您自己的服务器，那么它并没有真正的区别。 apache安装（只要你知道如何正确配置）。
至少这是我的意见/经验。
我一直在使用免费的 Zend Platform 开发人员版。如果我必须为 Zend 平台/服务器付费，我想我不会使用它。但这确实取决于项目。
I have been using Zend Platform(I know you were asking about Zend Server, I'm getting there) and have been very keen on the error reporting tool which you also get with Zend Server.
Whenever an error occurs or an exception is thrown Zend Server stores as much information about it as it can(like for instance what request parameters were being used, where the error occured, time, error message, stack trace, etc.).
Also slow script execution is being reported to you.
I really prefer getting those kind of error messages over customers saying something like: "The site is not working. Please fix it".
When using Zend Server in conjunction with Zend Studio it's pretty neat that Zend Debugger comes already preinstalled(but you could have installed it yourself as well).
Also it comes with a php-java-bridge(your java classes can be used in PHP) but I didn't need this.
If you're having a php-based error reporting solution in your web application already or have no use for this nor for the java bridge I'd say that it doesn't really make a difference if you are using Zend Server over your own apache installation(as long as you know how to configure it right).
At least that's my opinion/experience.
I've been using the Developer Edition of Zend Platform which is free. If I had to pay for Zend Platform/Server I don't think I would be using it. But that really depends on the project.
Zend Server 不仅仅是拥有经过测试和支持的堆栈。 Andre 谈到了 Zend Server 的一项功能，即监控。监控会监视您的 PHP 脚本执行是否满足特定条件，如果超过特定阈值，则会记录该请求的上下文，以便您稍后检查。当我在现场与遇到应用程序问题的客户合作时，我做的第一件事就是安装 Zend Server 并打开监控。几分钟之内，我通常至少对他们的问题有一个很好的理论。
在 Zend Server 5 中，随着代码跟踪功能的引入，这一点得到了提高，该功能对请求过程中进行的几乎每个单独的函数/方法调用进行运行时检测。它有点像在运行时完成的调试和分析的组合。在许多情况下，可以在生产环境中诊断问题，而无需实际复制问题。
您还可以使用其他一些功能。作业队列对我来说是一个很大的队列，我使用得非常广泛。我在 你排队吗？ Zend Server 作业队列简介
还有两种不同的缓存功能，PHP-Java 桥（Andre 也提到过）和 Optimizer+（这是可用的最快的操作码加速器之一）。
Zend Server is about a lot more than having a tested and supported stack. Andre touched on one of the features in Zend Server, that being monitoring. Monitoring watches your PHP script execution for certain conditions and if a certain threshold is passed, the context of that request will be recorded for you to examine at a later point in time. When I work onsite with customers who are having application problems the first thing I do is install Zend Server and turn monitoring on. Within a few minutes I usually have at least a pretty good theory as to what their problem is.
In Zend Server 5 that was taken to a much higher with the introduction of the Code Tracing feature which does runtime instrumentation of almost every individual function/method call made over the course of a request. It is kind of like a combination of debugging and profiling which is done during runtime. In many cases it is possible to diagnose a problem in a production environment without actually replicating the problem.
There are several other features that you can use as well. The Job Queue is a big one for me which I use pretty extensively. I have an example of how to use it at Do you queue? Introduction to the Zend Server Job Queue
There are also two different caching features, the PHP-Java bridge (which Andre had also alluded to) and Optimizer+ which is one of the fastest opcode accelerators available.
当然，“经过测试、认证”在某些环境中是很好的。在我们的例子中，审计要求是我们要么使用经过认证的软件堆栈，要么我们自己进行，但必须表明我们正在对其中的每个小组件进行快速更新。因此，出于理智的目的，我们历来都使用 Linux 发行版的标准产品。问题在于它们往往落后于曲线多年。例如，大多数发行版在坚持使用 5.1（！）之后最近才采用 PHP 5.3。当您尝试开发使用现代编码技术的现代应用程序时，这是不可接受的，而且您还放弃了大量 PHP 性能和可靠性。
话虽如此，这些功能也相当不错。 @Keven 已经提到了作业队列。这对我们来说太棒了，因为我们可以非常轻松地卸载异步运行的各种任务并保持主请求进程正常运行。例如，每当发生某些类型的事件时，我们的一个应用程序就会在错误跟踪器中创建任务。由于这是由 Web 服务完成的，并且错误跟踪器非常慢，因此这可能需要几秒钟的时间。然而，我们只是将作业排队并让它在后台运行，而不是让应用程序的用户等待。同样，我们的标准电子邮件类使用作业队列，而不是让用户在我们的代码与 SMTP 服务器对话时等待。所有这些甚至都没有触及诸如生成大型报告、运行数据库完整性检查、重建缓存等之类的有用性。
页面缓存非常适合您可以简单地缓存整个页面并使用它来完成的情况。我们将其与 WSDL 一起使用，因为我们比 PHP 自己的缓存控件具有更好的控制能力。同样，下载服务器非常适合缓存某些类型的内容，例如图像。我们像本地 memcached 服务器一样使用数据缓存，通过避免对位于慢速网络上其他位置的慢速数据库服务器进行查询来大大加快各种请求的速度。
当然，正如 @André 提到的，其中有一些非常好的调试、跟踪和事件报告功能。
还有一些用于执行部署和回滚的好功能，这对于业务关键型应用程序非常重要。我打算有一天尝试这些，但目前，我仍在使用在使用 ZS 之前整理的工具。
现在，您可以通过拼凑各种其他工具来获得大部分功能（特别是所有缓存位）。但是，您必须研究和学习所有这些东西，将它们全部安装并一起工作，然后维护它们，包括在更新某些内容时进行适当的集成测试。这是大量的工作和时间——我个人宁愿把这些时间花在编写代码上。
话虽如此，但也有缺点。其一，有时感觉事情……不成熟和/或考虑不周。例如，如果您尝试获取不存在的项目，数据缓存 API 将返回 boolean false。而且，它没有在不获取的情况下检查项目是否存在的功能。猜猜这意味着什么：您无法安全地存储布尔值，因为您无法安全地检索它。它包括一个记录不足的 APC 兼容层，但尝试使用 APC 中的存在函数会产生未定义函数错误。
另一个例子，我们使用 Mac 作为我们的开发站，但出于对与古老硬件的兼容性的极大误导性担忧，这些硬件往往由那些在 PHP 服务器软件上投入数千美元的专业开发人员运行，Zend 选择发布Mac 版本（仅用于开发）为 32 位仅。因此，我们被迫开发一个 32 位应用程序，该应用程序可以在其他任何地方以 64 位运行。这在我们的应用程序中导致了相当多的错误和失败的自动化测试，这反而扼杀了 ZS 的核心目的之一，即跨开发、测试、登台、QA 和生产环境的相同软件堆栈。我试图说服他们改变这一点，但他们很快就开始无视我。
另一个大问题是作业队列只能通过 HTTP 请求处理作业。 API 设置为允许其他方法（例如更明智的命令行调用），但 HTTP 是唯一有效的。这迫使您将 Web 服务器连接与任务联系起来，这些任务在设计上往往需要长时间运行，因此应该脱离 Web 上下文。而且，它迫使您克服重重困难，阻止外界通过访问浏览器中的 URL 来触发您的工作。这只是一个愚蠢的决定。
其他示例包括对通过 API 发送到 Zend Monitor 的自定义事件处理不当、PHP 二进制文件的 php-cli 包装器在被 shebang 行触发时在 Mac 上中断、缓存中完全（完全）缺乏运行状况和性能报告工具（尽管他们说这在 ZS 6 中发生了变化），以及令人尴尬的不完整文档。我可以继续......
现在，这些缺点，以及随之而来的浪费时间和资源，显然没有超过对我们来说的好处，但对于我们花费的金钱来说，我绝对期望更多的。
Certainly, the 'tested, certified' bit is nice in some environments. In our case, auditing requirements are that we either use a certified software stack, or we go on our own but have to show that we're doing quick updates to every little component that feeds into it. So, for sanity purposes, we've historically gone with the standard offerings of the Linux distributions. The problem with this is that they tend to be years behind the curve. For example, most distributions have only recently adopted PHP 5.3 after having stuck with 5.1 (!). That's just not acceptable when you're trying to develop modern applications that use modern coding techniques, plus you're giving up a ton in terms of PHP performance and reliability.
Having said that, the features are quite nice, too. @Keven already mentioned the job queue. That's awesome for us, in that we can very easily offload all sorts of tasks that run asynchronously and keep the main request process flying. As an example, one of our applications creates tasks in our bug tracker whenever certain types of events happen. As this is done by web service, and the bug tracker is horrendously slow, this can take several seconds. Rather than making the users of our application wait, however, we just queue up a job and let it run in the background. Likewise, our standard e-mail class uses the job queue rather than making the user wait while our code talks to an SMTP server. And all that's not even touching the usefulness for things like generating large reports, running database integrity checks, rebuilding caches, etc., etc.
The page cache is great for those cases where you can simply cache a whole page and be done with it. We use this with our WSDLs, since we have better control than PHP's own caching controls. Likewise, the download server is wonderful for caching certain types of content, like images. And we use the data cache like a local memcached server to greatly speed up all sorts of requests by avoiding doing a query to a slow database server sitting somewhere else on the slow network.
And of course, as @André mentions, there are some very nice debugging, tracing, and event reporting features in there.
There are also some nice features for doing deployments and rollbacks, which are very important with business-critical applications. I intend to try these out someday, but for now, I'm still using the tools I put together prior to use ZS.
Now, you can get most of these features (particularly, all the caching bits) by cobbling together a variety of other tools. But, you then have to research and learn all those things, get them all installed and working together, and then maintain them all, including doing proper integration testing when something is updated. That's a lot of work and time -- time I'd personally rather spend writing code.
Having said all that, there are downsides. For one, things sometimes feel... half-baked and/or ill-conceived. For example, the data cache API returns boolean false if you try to fetch an item that doesn't exists. And, it has no function for checking if an item exists without also fetching. Guess what this means: you can't safely store a boolean value because you can't safely retrieve it. It includes a poorly documented APC compatibility layer, but trying to use the existence function from APC produces an undefined-function error.
As another example, we use Macs for our development stations, but out of a greatly misguided concern over compatibility with the ancient hardware that tends to be run by all those professional developers out there who drop thousands on PHP server software, Zend has chosen to ship the Mac version (which is for development only) as 32-bit only. So we're forced to develop an application in 32-bit that runs everywhere else in 64-bit. This caused quite a few bugs and failed automated tests in our application, which rather kills one of the core purposes of ZS, which is an identical software stack across development, test, staging, QA, and production environments. I tried to talk them into changing this, but they quickly started ignoring me.
Another big one is that the job queue can only process jobs through HTTP requests. The API is set up to allow other methods (like the much more sensible command line call), but HTTP is all that works. This forces you to tie up web server connections with tasks that, by design, tend to be long-running and thus should be taken out of web context. And, it forces you to jump through hoops to keep the world from being able to trigger your jobs by visiting a URL in a browser. It's just a stupid decision.
Other examples are the poor handling of custom events sent via API to Zend Monitor, the php-cli wrapper for the PHP binary that breaks on the Mac when triggered by shebang line, the complete (utter) lack of health and performance reporting in the cache tools (though they said this is changing in ZS 6), and the embarrassingly incomplete documentation. I could go on....
Now, those downsides, and the wasted time and resources that come along for the ride, obviously haven't outweighed the benefits for us, but for the amount of money we're spending, I definitely expect more.
代码跟踪是 Zend Sever 提供的最好工具
根本原因分析是开发人员的时间消耗
当您知道问题的原因时，解决问题就很容易了。然而，在测试期间找到问题的根本原因通常具有挑战性，并且在应用程序在生产中运行时更是极其困难。尝试在开发实验室中重现完全相同的环境、应用程序状态和负载既耗时又容易出错，而且它会让开发人员偏离最重要的任务——编写代码。 Zend Server 5 通过代码跟踪功能将根本原因分析提升到一个全新的水平。
适用于 PHP 应用程序的飞行记录器
什么是代码追踪？
想想黑匣子飞行记录器。当飞机出现问题时，您可能不想“重现”该问题。这就是飞行记录器捕获飞行分析师可能需要的完整数据的原因，以便了解问题发生的原因。
Zend Server Code Tracing 就像 PHP 的飞行记录器。
Zend Server 无需花费时间尝试设置环境并重现导致失败的所有步骤，而是在生产或测试实验室中实时捕获应用程序的完整执行情况，以便您可以快速找到根本原因。
Zend 服务器代码跟踪缩短了根本原因分析时间
当检测到问题时，Zend Server 代码跟踪会自动激活，或者由用户手动激活，例如在优化项目期间。
Zend Server 代码跟踪记录的数据包括：
Zend Server Web 控制台中显示的跟踪使您能够查看（就像 DVD 一样）应用程序的执行历史记录并跟踪跟踪单个有问题的请求的脚步，以快速查明根本原因。
Code Tracing is the best tool provided by Zend Sever
Root Cause Analysis is a Time-Sink for Developers
Fixing a problem is easy when you know what causes it. However, finding the root cause of problems is often challenging during testing, and incredibly difficult when the application is running in production. Trying to reproduce the exact same environment, application state and load in the development lab is both time-consuming and error-prone, and it takes developers away from their most important task – writing code. Zend Server 5 takes root cause analysis to a whole new level by featuring code tracing.
A Flight Recorder for Your PHP Application
What is code tracing?
Think of a black box flight recorder. When something goes wrong with an airplane, you would probably not want to “reproduce” the problem. This is why the flight recorder captures the full data that flight analysts may need in order to understand why the problem occurred.
Zend Server Code Tracing is like a flight recorder for PHP.
Rather than spending time on trying to set up the environment and reproducing all the steps that led up to the failure, Zend Server captures the full execution of your application in real-time – in production or in the test lab – so you can quickly find root cause.
Zend Server Code Tracing Cuts Root Cause Analysis Time
Zend Server code tracing is activated automatically, when a problem is detected, or manually by the user, e.g. during an optimization project.
Data recorded by Zend Server code tracing includes:
The trace displayed in the Zend Server web console enables you to view - much like a DVD – the execution history of your application and follow the footsteps of a single problematic request to quickly pinpoint root cause.
我开发的 PHP 应用程序在大型 IBM 服务器（IBMi 系列）上运行，使用的旧软件已经使用 COBOL 运行了 20、30 年。因此，基本上，Zend Server 是据我所知唯一可以在 IBMi 上运行或至少与它一样强大的 PHP 平台。这些系统对于任务至关重要。基本上大多数保险公司、银行、股票、甚至学区都在这些类型的系统上运行。由于您可以运行 Zend Server 之类的东西，因此您可以做一些事情，例如构建 REST API，以现代方式公开这些古老的系统并允许面向服务的架构。这就是我一直致力于开发的事件驱动系统，该系统利用 PHP CLI 和 Zend 作业队列将数据推送给第三方。在这种情况下，我们将数据从我们端同步到供应商端。
IBMi 上的 Zend Server 设置了一个用于静态资源（CSS、图像等）的 nginx 前端，并使用 FastCGI 进程来处理动态 PHP，因此它是一个非常强大的设置。它无疑为旧系统的现代化打开了大门。
I work on PHP applications that run on large IBM servers (IBMi Series) with old software that's been running for like 20, 30 years using COBOL. So basically Zend Server is the only PHP platform that I know of that works on IBMi or at least as robust as it is. Those systems are mission-critical. Basically most insurance companies, banks, stocks, even school districts run on these types of systems. Since you can run something like Zend Server you could do stuff like build a REST API that exposes those ancient systems in a modern way and allows for Service Oriented Architecture. That's what I've been working on and as well as an Event Driven System that utilizes the PHP CLI and Zend Job Queue that pushes data to third parties. In this case we sync data from our end to the vendor's end.
Zend Server on IBMi is set up with a nginx front-end for static resources (CSS,images, etc.) and uses FastCGI processes for dynamic PHP so it's a pretty powerful setup. It definitely opens up old systems for modernization.
我发现使用 Zend Server 来减轻对我所有服务器上的 PHP 软件版本及其所有各种扩展的管理是其最大的优势。
此外，能够通过用户输入和环境变量找到问题根源直至特定的 PHP 函数，这比浏览 PHP 错误日志更有帮助，尤其是在高流量服务器上。
如果有一个开源替代品，我很想知道！我对 Zend 停止提供免费版本不太高兴。
I find that using Zend Server to mitigate management of software versions of PHP and all of its various extensions across all of my servers to be its greatest advantage.
Also, being able to spot the source of a problem down to the specific PHP function with user input and environment variables is much more helpful than trolling through PHP error logs especially on a high traffic server.
If there is an open source alternative to that, I would love to know about it! I'm not too happy that Zend discontinued the free version.