Stefan Koopmanschap has taken his own look at the latest offering from Zend - the Zend Server.

Zend released a new web application server product earlier this week called Zend Server. Curious as I am, I'm going to have a quick look into it here. I decided to start fresh so I launched my Parallels and installed a fresh Debian VM to check Zend Server out on. After running through the Debian installation I was ready to start the work.

He mentions a few of the "goods" - like the Debian package that's already built (just an apt-get call away), the nice interface and some of the bads - the "not quite enterprise" feel of the dashboard (looks a lot like Zend Platform) and a few smaller setup issues that could be easily fixed in future releases.

His overall impression is a bit indifferent, though he notes that

This is just a beta though, so things may change in the future. We'll see. [...] It's good to see something new coming from Zend, but I think they could've done better.

In a recent post to his blog Patrick Allaert takes a look at benchmarking what Zend Platform has to offer against its open source brothers, Xdebug and APC.

The benchmark has been realized on an Intel Core2 Duo CPU T7500 @ 2.20GHz with 2Gb of RAM running Gentoo with a 2.6.25-r7 linux kernel. ab, the Apache Benchmark tool, has been used for the benchmark with 3000 requests and three concurrency modes: -c1, -c5 and -c50 which represents respectively 1, 5 and 50 simultaneous users. The application tested is eZ Publish 4.0.1 with default configuration using the "plain_site" example.

He tested with a number of different PHP installations including a base install of PHP 5.2.6, one including APC, another with APC+Xdebug and others with the Zend Platform. The resulting stats are included as well as a graph showing their relationships to each other. The installs using the bytecode caching came out on top (obviously) with the APC installations being much faster than the accelerated Zend Platform.

The Zend Developer Zone as posted a new screencast from Zend about the event debugging functionality offered with their Zend Platform product.

Zend Platform is a powerful tool both in development and in production. [...] One of the cool features of it is the Event Debugger. Here's a short screencast that demonstrates how it works and how it integrates with Zend Studio for Eclipse.

The screencast is only about three and a half minutes long, but they cram a lot of screenshots and output results into that time. Cal Evans himself does the narration.

This recent post on the PHP::Impact blog spotlights a useful little tool for those developers needing to span the gap between PHP and Java in their applications - the PHP/Java Bridge.

The PHP/Java bridge allows you to quickly access Java classes from within your PHP classes without having to know Java and vice versa. Because of this two-way flexibility, you can access hundreds of pre-built Java classes from PHP, and hundreds of pre-built PHP classes from Java opening up your applications to greater flexibility and enhanced functionality.

The post includes an introduction to the bridge's functionality - its functions/methods, how to make a new instance of it, catching exceptions and the type conversion it automatically does (like lang.java.String directly to the PHP String type).

They also mention the Zend Platform bridge functionality for a more commercial solution.

On the Zend Developer Zone today, there's a new article by Dotan Perry and Shie Erlich talking about what kind of scalability and responsiveness that the Zend Platform's Job Queue functionality has to offer.

The Zend Platform Job Queue is used to make applications more responsive by allowing tasks to be performed on other machines (e.g.: dedicated machine), and scheduling tasks to a future time (usually to low-traffic hours). [...] Job Queue offers both a web-based management UI, and a programmer-oriented rich API, which allows embedding sophisticated logic into applications. This article will demonstrate basic usage of Job Queue, through an imaginary company wesellalot.com.

They start by presenting a scenario where a simple cluster of machines behind a load balancer all work with the same database. Because of some of the tasks they want to perform, things could get overloaded very easily under a high load. Enter the Job Queue and their four step process to integrate it into this setup:

• Step 1: Off Load to a Dedicated Server
• Step 2: Scheduling to low-traffic hours
• Step 3: Breaking down tasks using dependencies
• Step 4: A recurring cleanup job

They also include an explanation as to why this method is preferable over just using croned scripts for the same purpose.

On the Zend Developer Zone today, there's a new article by Dotan Perry and Shie Erlich talking about what kind of scalability and responsiveness that the Zend Platform's Job Queue functionality has to offer.

The Zend Platform Job Queue is used to make applications more responsive by allowing tasks to be performed on other machines (e.g.: dedicated machine), and scheduling tasks to a future time (usually to low-traffic hours). [...] Job Queue offers both a web-based management UI, and a programmer-oriented rich API, which allows embedding sophisticated logic into applications. This article will demonstrate basic usage of Job Queue, through an imaginary company wesellalot.com.

They start by presenting a scenario where a simple cluster of machines behind a load balancer all work with the same database. Because of some of the tasks they want to perform, things could get overloaded very easily under a high load. Enter the Job Queue and their four step process to integrate it into this setup:

• Step 1: Off Load to a Dedicated Server
• Step 2: Scheduling to low-traffic hours
• Step 3: Breaking down tasks using dependencies
• Step 4: A recurring cleanup job

They also include an explanation as to why this method is preferable over just using croned scripts for the same purpose.

If you've read this post and gotten a little lost as to the struggle he (Tony Bibbs) faced to lead up to, you might want to check out the previous post outlining all of the things he came across when making the move from Zend Studio version 5.1 up to version 5.5.

So what have I concluded out of all of this? As clearly as I can state it here is the big problem. With Zend Studio 5.1 you could install Studio Server with no additional fee outside of the Zend Studio license. This allows you to debug via your local Apache instance running PHP. To get the same feature set out of Zend Studio 5.5 you would have to buy Zend Platform separate.

My hunch is the folks at Zend expect developers to debug on their local desktops with only the internal debugger which *can* produce different behavior than that under your web server environment. It's not good if your debugger can exhibit different behavior than your web server. I should also note that remote debugging with Zend Studio 5.1 while serviceable was not the most stable. It would occasionally kill Apache, possibly require me to restart Zend Studio or rare cases even force me to reboot.

He also lists out some of the other issues he's noticed in making the change (six of them).

If you've read this post and gotten a little lost as to the struggle he (Tony Bibbs) faced to lead up to, you might want to check out the previous post outlining all of the things he came across when making the move from Zend Studio version 5.1 up to version 5.5.

So what have I concluded out of all of this? As clearly as I can state it here is the big problem. With Zend Studio 5.1 you could install Studio Server with no additional fee outside of the Zend Studio license. This allows you to debug via your local Apache instance running PHP. To get the same feature set out of Zend Studio 5.5 you would have to buy Zend Platform separate.

My hunch is the folks at Zend expect developers to debug on their local desktops with only the internal debugger which *can* produce different behavior than that under your web server environment. It's not good if your debugger can exhibit different behavior than your web server. I should also note that remote debugging with Zend Studio 5.1 while serviceable was not the most stable. It would occasionally kill Apache, possibly require me to restart Zend Studio or rare cases even force me to reboot.

He also lists out some of the other issues he's noticed in making the change (six of them).

Today, Tony Bibbs provides something that "Zend might not want you to know" about using their debugger in your application - that it enables an option silently, without asking the user at all.

A co-worker here was going through similar problems with Zend Studio 5.5. He'd even gotten so frustrated he tried installing phpEclipse and in doing that installed Zend's debugger. Little did he know that by doing that he had enabled remote debugging support in Zend Studio 5.5 without the need for Zend Platform and we can still happily use APC.

Now the million dollar question is why doesn't Zend document or promote this fact? Sure, they want you to install and test drive their "PHP Application Server" but if you don't desire all of that why force it down our throat?

He points out a PDF that only barely mentions that this could happen but couldn't find much else. If you don't want this to happen to you, he provided a different method to enable the debugging easily through a few php.ini settings.

Today, Tony Bibbs provides something that "Zend might not want you to know" about using their debugger in your application - that it enables an option silently, without asking the user at all.

A co-worker here was going through similar problems with Zend Studio 5.5. He'd even gotten so frustrated he tried installing phpEclipse and in doing that installed Zend's debugger. Little did he know that by doing that he had enabled remote debugging support in Zend Studio 5.5 without the need for Zend Platform and we can still happily use APC.

Now the million dollar question is why doesn't Zend document or promote this fact? Sure, they want you to install and test drive their "PHP Application Server" but if you don't desire all of that why force it down our throat?

He points out a PDF that only barely mentions that this could happen but couldn't find much else. If you don't want this to happen to you, he provided a different method to enable the debugging easily through a few php.ini settings.