rhymes with milk

At this point of my PHP App Development research, I’ve made a decision to start the project using Zend Framework. During my research, I kept reading that frameworks can help your development immensely. They apparently take a lot of the repetition out of your coding, and generally make development more rapid.

So which framework to chose?

There are a lot to chose from, but the same few kept coming up in my research. Zend and CakePHP were probably the two most highly recommended. I’m no expert at the differences between the two, so I won’t even pretend to list them here. But ultimately I decided to go with Zend, mostly for the reasons listed here.

Installing Zend Framework on Linode VPS

UPDATE: After writing this, I realized that apt-get tends to get behind on updating its Zend package. As of writing this, the latest version of Zend is 1.12.0, and running apt-get installed 1.10.3. To fix the error, I removed the /usr/share/php/libzend-framework-php/Zend/ directory and updated it with the latest version of the Library. To be honest, you should probably just follow this tutorial on installing Zend instead of mine. I will leave this here for my own reference though.

I previously wrote about some of the benefits to Amazon’s AWS hosting, but while I’m still learning new technologies like Zend, I figured it would be best to start learning on my current hosting setup and avoid paying for two plans. Btw, my current plan is a Linode 512 with Ubuntu 10.04 and LAMP.

I spent the last day trying to figure out how to install Zend on Linode. Unfortunately, Zend’s official documentation isn’t great for n00bs. It ended up being really simple to install and get a Hello World created, it just took a long time to find a good tutorial. I finally just got it working, so I thought I should document those steps here:

1. Install Zend on server

This couldn’t be easier. SSH onto your server, and run the following command:

sudo apt-get install zend-framework

That downloads and installs all the necessary components of Zend. I still can’t tell if it installs just the full version of Zend Framework, or if it also installs Zend Server. I can’t even tell you the difference between those two things.

Anyway, this installs a handful of things onto your system. The most important to take note of is a library that should have been installed in the following location:

/usr/share/php/libzend-framework-php/Zend/

We’ll be needing that path here in a minute…

2. Create a project

Now we need to decide where our public website is going to reside, and install all of the necessary Zend components in that location. I happened to have a throw-away URL (we’ll call it mydomain.com) that I’m going to use for development, so I created a directory in the following location where my new website will live:

/srv/www/mydomain.com/tup/

The path is pretty arbitrary (“tup” is short for The Untitled Project), but it should at least be within a sub-directory of /srv/www/ (at least that’s where my default server root is).

So now use the cd command to get to your new directory, and then create the project inside of it:

cd /srv/www/mydomain.com/tup/
zf create project

You will be prompted for a location. Make sure to input the path to the tup directory (or wherever your site is going to be housed).

 Now if you do the command ls -la you should see that Zend added a bunch of stuff in there for you.

3. Include library path

This was the part that kept confusing me. Everywhere I looked, I was instructed to “specify the correct library path” but I had no idea what that meant. There are multiple ways of doing it: adding a new include path to your php.ini file, duplicating the whole library, or creating a symlink to it. Wtf do those mean?

Then I found an awesome YouTube video that cleared everything up. What he shows you is that the new project you just created adds an empty directory called “library”:

/srv/www/mydomain.com/tup/library/

Apparently, this new project installs the basics you’ll need to create a new site, but it doesn’t include the main Zend library files. The main installation we did in step 1 installed those core files in a common location. Remember I told you make note of the Zend library path? We’re about to use that.

First, let me explain the methods we’re NOT going to use to include those files. The php.ini method means that you’re telling php to load those files every time php is used. I have about a half-dozen other sites on my server, none of which use Zend Framework, so it would be a waste to load its libraries every time those sites use php. Then there’s the method of copying that whole Zend library directory, and pasting it into the library directory. The Zend library directory has some 3,000 files taking up nearly 30MB. Duplicating it would unnecessarily waste precious hard-disk space, so I ruled that out.

Instead I created a symlink inside of the library directory and pointed it to the Zend directory. First make sure you’ve cd’ed to library directory, then issue the link command:

cd /srv/www/mydomain.com/tup/library/
ln -s /usr/share/php/libzend-framework-php/Zend/ Zend

So now if you issue a ln -la, it should show you a symbolic link from Zend to the libzend path. We’ve just included the Zend core libraries into our website. Yay!

4. Make it live (add a vhost record)

Now we need to tell Apache to deliver our site by creating a virtual host for this site. If you go to the docs directory in your new project, there’s a README.txt file that has an example VHOST file in it. Copy this content, go to /etc/apache2/sites-available/ and create a new file called mydomain.com. In it, paste the VHOST info Zend provided for you. You might have to make small modifications, but here’s what mine ended up looking like:

    DocumentRoot "/srv/www/mydomain.com/tup/public"
    ServerName mydomain.com
    # This should be omitted in the production environment
    SetEnv APPLICATION_ENV development
     
    <Directory "/srv/www/mydomain.com/tup/public">
         Options Indexes MultiViews FollowSymLinks
         AllowOverride All
         Order allow,deny
         Allow from all
    
     

That “public” directory listed on the second line was created when you created your project, and there should be a default “welcome to zend” index.php file in it. Reload apache with the following command, then navigate to mydomain.com and you should see that index file being displayed.

/etc/init.d/apache2 reload

That’s it! At least that’s as far as I’ve gotten so far. We’ll see how it goes from here.

So as I stated in the intro to my new untitled php app project, I’ve been doing a lot of research regarding scalable hosting solutions. Rhymes With Milk is currently hosted on Linode, which I love and is perfect for this piddly little wordpress site. But even Linode’s high-end dedicated servers wouldn’t be able to handle the kind of load a large project might require.

As an example, at my job we have several dedicated servers (not at Linode, btw) that have really great performance specs. Just one of them is enough to host over 100 of our clients’ websites. So one year we helped create an iPhone app for the Tour de France. I think the way it worked was the Slipstream sag wagon was carrying an on-board GPS that would ping our server periodically to update an XML file that tracked its location throughout the race. That worked just fine, until about a million requests per minute (that’s a speculative number — I actually don’t know what the exact figures are) were coming into the server for that one file as users were trying to get updates on the location. The file itself was being requested directly by the app, so negligible processing on the server end went into fetching it. But Apache just couldn’t keep up with amount of connections coming in, so our server kept giving up. It pooped out.

This was where Amazon’s AWS really helped save us. We were able to create an Amazon S3 bucket, drop that one XML file in there, and they were able to easily handle the request load.

So what is Amazon AWS?

Well, for starters it stands for Amazon Web Services. It’s taken a lot of research to answer that simple question beyond figuring out what it stand for. Amazon throws around a lot of acronyms, and has a pretty atypical pricing plan compared to more traditional hosts. So here’s a breakdown of their two main services that I think I understand. I’m certainly no expert, I’m just a guy that’s done a lot of reading. I haven’t even set up an account and explored these services myself yet, so this is all what I’ve learned from the outside.

Amazon EC2

Let’s start with EC2 since that’s most like traditional hosting. EC2 is Amazon’s version of VPS hosting. You set up an account and select what size of a virtual server you’d like (how much RAM, bandwidth, storage, cores, etc that you need). Just like many other VPS hosts (e.g. Linode), you can totally customize your server by selecting which flavor of Linux you’d like (you can also set up Windows servers) and where you want it to be hosted (e.g. east coast, Texas, etc). Apparently when you go to select your Linux distribution, Amazon also allows you to select popular packages to start with — like whether it should have LAMP pre-installed, or a mail server included. There is also a community driven list of packages. So if somebody decided that it would be useful to have a server come pre-tuned for video delivery, or have Subversion installed, etc, they could add that package to Amazon’s list. You select one of these, and Amazon creates your VPS with the package you selected.

Now here’s where things get a little cloud-computy. I keep using words like “VPS” and “packages” whereas Amazon uses the words “instances” and “AMIs”. When you create a new VPS, you’re actually creating a new EC2 instance, and those packages are what Amazon calls AMIs (Amazon Machine Images).

You can create a new instance whenever you’d like using one of Amazon’s preconfigured AMIs, or one from the community marketplace like I mentioned above. It’s automatically assigned a new DNS entry, so you can point your domain to it and start delivering content. Similarly, you can turn off an instance whenever you want. This isn’t used much in a single-server setup (we’ll get to multi-instance cases in a minute), but theoretically it’s possible. You can take a snapshot (I think Amazon has a special word/acronym/tool for these, but I don’t know what they are) of your existing setup, back it up, and turn off your server. This does destroy all of your data, so naturally this isn’t something you’d be doing often in a production environment.

I don’t understand multi-instance situations as much, but I think the point is to spawn new instances when the server is under strain. If you know your site was just Dugg or something, you can spawn a new instance and it will share the workload with the first (I think). In a more traditional setup, you might have a server for just routing traffic, and behind it are multiple duplicate copies of the same server each responding to only a fraction of the requests. Each instance is one of those duplicate servers. There are even programs dedicated to just monitoring your server performance, and automatically spawn new instances when it notices your machine needs help (I think Amazon’s CloudWatch is one name I’ve heard before, but that’s something for another post).

These multi-instance situations make it a little more clear why Amazon charges for these services hourly, not monthly. You might need your second instance for only one hour, so you get charged for two instances for that hour.

By the way, I think there are ways you can change your instance specs on the fly instead of spawning a whole new one. Like for example, if you realize you need more RAM all the time, but not necessarily double the processing power, I think you can increase that on your base instance. I’m not confident on that point, though.

Amazon S3

So what if you have a website with a lot of static resources? Things like images, videos, anything that might take up a lot of space, or get requested a whole lot? That’s where S3 (Simple Storage Service) comes in. It’s where you can host all of those resources without putting the strain of delivery/storage of them on your EC2. Remember that XML file I talked about in the beginning? The one getting requested so often it crashed our large dedicated servers? Yeah, S3 was the solution for that. We dropped it into a bucket, and only paid a minimal fee for the number of requests it got. Storage and bandwidth are both really cheep, and you only pay for what you use. I’m about 90% sure web giants like Pinterest, Netflix, and Tumblr all use S3 to store and deliver all of their goods.

—

Alright, that was a lot of info. I’m not sure how to conclude after that. I’ve got a lot more learning to do, and I’m planning on actually setting up an AWS account soon to do that learning. I’ll let you know what I find.

Lastly, on a somewhat unrelated note, I’ve been very curious about where large-scale web apps live. Tools like WhoIsHostingThis.com and Netcraft.com have come in handy. A few interesting finds:

• MyFitnessPal: Amazon
• dailymile: Linode (though their images seem to be hosted by Amazon (media.dailymile.com, s1.dmimg.com, etc))
• Fitocracy: Amazon
• Nettuts: Linode (again, images are hosted by Amazon (cloudfront.net))
• ThemeForest: Rackspace (this is interesting, since Nettuts is a part of the same network of sites (Envato))

Please don’t look into the fact that most of those are fitness sites. They were just a few of the first large-scale non-obvious websites I could think of.

I’ve been busy lately, between getting married and spending nearly a month honeymooning in Hawaii, work, Diablo III coming out (!), and getting ready for a bike ride I’m totally not prepared for. But along with that, I’ve started working on several side projects and hopefully I’ll have enough free time to see them through.

One project I’m working on is creating a simple blank WordPress theme. But instead of being totally blank, it’ll be pre-styled with the intention of being re-styled. I’ll include all of the necessary WP-as-a-CMS functionality, and everything will be styled enough that it’s ready to go out of the box, but will also be really easy to apply custom styles to. It’s mostly something I’ll benefit from at work, since I’ll able to use it instead of the annoying and bloated TwentyEleven as a starting point for custom themes.

There’s another project I’ve been mulling over, mostly just the seed of an idea at this point. I’ve been wanting to try my hand at building a large-scale web application, and this would definitely fit the bill. I’m not sure whether it has the potential to actually see a large user base, but I’d still like to approach it with those intentions. That way I’ll learn from it, and if it does actually gain people’s attentions then it’ll be ready to handle it.

This project has forced me to start doing some research into scalable sever solutions, php frameworks, and general concepts of php application development, most of which is new to me. I feel like I need somewhere to dump my new found knowledge, and my process of discovery. This will probably be that place.

For now I’ve decided to tag these posts PHP App Development, so my progress can be followed there. Geek on!