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?
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 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.
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.
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.
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.
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.
