I just had an epiphany. I’ve talked about pre-caching content before and the benefits thereof before. But this is the first time I realized not only that there are benefits, but that doing it is BETTER than caching inline. Let me sum up… no, there is to much. Let me explain.
Typically caching is done like this (stolen from the ZF caching docs):
Tapping millions of non-PHP PHP developers. (A managerâ€™s short guide for migrating from Java to PHP)
I was getting ready to post the Powerpoint presentations from my last two user group meetings when I fat-fingered my “My Documents” folder and accidentally opened up a Word doc that had an old article that I had written for a Zend newsletter a while ago. So for this case of serendipity I decided that I would repost this article, which I had written long before I had a blog. The basic premise is that once you get past a few minor differences, an organization can move from Java development to PHP development in a very short amount of time, saving time, money and headaches.
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.