So, you just received instructions to download and try out Zend Server. Or, you heard that Zend Server is a "PHP Application Server", but you have no idea what that means and you want to find out. What do you do?

What I have often seen is that people will download and install Zend Server, try a PHP application on it and see if it works. They see that it does work. Then they ask "ok, it works but it's not worth the price so I'll just go back to what I was using before." The problem here is that more often than not, and I'm sure it's a MUCH more often than not, "worth" is not defined.

So, today kind of got away from me and I was trying to think of what I could do to salvage this day when I came across an idea that I have had in the past. As you all probably know, Zend has salespeople. Those sales people have sales engineers who show how to use our products. However, I personally hate being on the phone for a canned presentation when all I really want to do is tinker. So, in an effort to produce something of benefit today I decided to start a series of blog posts on how to evaluate Zend Server if you are a tinkerer, like me.

In my Do You Queue article there was a comment posted about open source alternatives to Zend Server's Job Queue. Being somewhat of an open source afficionado (I can spell that thanks to my love of fine tobacco products) that is a position that I can relate to. I have heard several times "I like what Zend Server offers but I only want to use open software, or I don't think the features are worth the money." I understand why. "Open" is the new black, and has been for a while now. So let's explore these two issues. 1) Proprietary software, and 2) the price of the software.

On June 23rd Zend announced the release of Zend Server Cluster Manager. Which means what, exactly.

PHP is designed using a shared-nothing architecture. What that means is that nothing is shared. What that really means is that each individual PHP request is isolated from every other PHP request. That's great! It makes for a very stable, very easy to use architecture. But what happens when you go beyond one server?

I was sitting at my computer this morning when an email came in notifying me that there was an error indexing my Lucene content. This error was generated by the Zend Server event monitoring system. I went to the site and tried doing a search but saw that the results were coming up double.

I re-ran the indexing task and the searches started coming up the way they should. Mean time to resolution? 5 minutes. Customer impact? Zero. Why? Because I knew there was a problem before anyone coming to the site did. THAT is the benefit of Zend Server Event Monitoring.

Working with an off-the-shelf shopping cart usually requires a little bit of patience. Scaling an e-commerce site does have its share of problems. There is a LOT of interactivity that needs to be implemented. This can be things along the lines of generating targeted ads, sending email or charging a credit card.

One of the problems with doing asynchronous execution is that it can be actually quite difficult to test those asynchronous jobs. In this video I describe how to implement a testable queuing system.

With the web being what it is today there can be a lot of times when you want to aggregate data from many different sources and bring them together in a single page. I have not done much of that on my site simply because that means that I then need to learn a bunch of different API's. However, since Youtube is the #2 search engine I figured that it might not be a bad idea to aggregate some of my YouTube content on my page automatically. I don't necessarily want to do a blog post about each individual video I post, but I wanted there to be some place where I could just list them out.

Debugging is one of the things that every single PHP developer in the world needs to know how to do. Unless you are simply learning the language, learning how to debug will save you countless hours and save you loads of money in anti-anxiety medications. var_dump() or print_r() is not debugging. At least, it's not debugging in a way that is very useful, or safe.

There are two primary debuggers in the PHP world. XDebug and the Zend Debugger. I am not an expert in XDebug (though I really need to learn it better) so I will leave those discussions to someone else.

In our previous installment we looked at setting our backend up so it could automatically retrieve the bit.ly URL for a given URL and store it as part of the data for a given instance of a Content model. What we're going to do this time is take a look at the front end components.

Sometimes I find that doing things backwards can actually make things a little more clear. That way you can see the end result and then, as you work backwards, see how all the pieces work together.

Over here there is a good article on sharing page feedback on Twitter. I'll end up doing something similar but in a different manner. A little while I posted an article (Do you queue?) on how you could use the Zend Server Job Queue to run individual tasks. Well you can do the same thing here. I've made a few changes since that article, namely that Zend_Application is passed in both to execute() and to run() so I could easily retrieve application settings. Don't know why I didn't think of that earlier. Oh well.

There has been a lot of talk over the past several years about the difference between performance and scalability. Never mind that the difference between the two will probably not really affect most developers. Never mind that the "difference between performance and scalability" argument is often used when someone's code performs poorly and their best argument is "Yeah, but my code scales". Yeah, sure it does.

I deployed this blog about a week ago. Since then there has been little traffic, mostly because I have not promoted it and I have also been working on a bunch of other content and such. Since I also just needed to just get it out the door and running I have not spent a lot of time testing for performance. This blogging app is based off of Zend_Application and as such there is a bit of overhead. Since I was not expecting traffic to be that heavy I was not (and am not) overly concerned about snappy performance at this point. As long as the page loads and displays in the browser I’m fine with it.

If you are reading that title and thinking "what is that guy smoking?" then you are probably in good company. Developers often make development decisions based off of philosophy. Some developers go the route of "we will decide on the best tool (language) for this individual job" and end up having hundreds of individual tools that they need to end up supporting. Others desire to take a more puritanical approach in saying that "we will only use this one tool (language) for this individual job." The problem is that the decision is often not as cut and dry as many development philosophies allow.