If you’re reading this blog post, then chances are, you’ve discovered the wonderful PEAR package called System_Daemon. This well-done package offers the ability to turn any PHP script into a daemon and does a good job of making sure there aren’t memory leaks or problems along the way.

There’s a great demo of the package and an explanation of how to get it up and running on the blog of the creator, Kevin von Zonneveld.

The source code for the demo in the post seems complete enough, but it was missing one major component that seems like it would be common for users. The post unfortunately leaves out how one can set the location of the log file or the PID file for the daemon to run. This is a common necessity for many “shared system”-esque environments that exist out there or for those who just happen to be working under restricted permissions. The documentation for the class doesn’t present this information in an easy-to-find manner either.

So, I’m here to let you know that it’s easy as pie… as long as you know the name of the option you’re looking for. By default, the system seemed to want to use the following for the defaults:

/var/run/{appName}/{appName}.pid

and

/var/log/{appName}.log

There’s a couple steps that you’ll want to take so you can get a System_Daemon up and running under the proper user, using files in locations that are accessible by your user.

First, you’ll want to grab the UID and GID of the user you’d like your daemon to run as. This can be achieved by the following command:

id

Once you’ve got your UID and GID, you can get to setting the options for your System_Daemon.

<?php
// Setup
$options = array(
    'appName' => ... 
    ...
    ...
    'appRunAsGID' => your UID,
    'appRunAsUID' => your GID,
    // This sets where you want the log file to be located
    'logLocation' => '/home/uesrname/daemon.log',
    /**
       * This sets where you want the pid file to be created. 
       * Be careful, there's an undocumented restriction on 
       * the naming convention for where the pid file can be 
       * written. It must be in a directory by the same name 
       * as the pid file like the example below. I don't know 
       * why, but it will throw an error if you try to set it 
       * otherwise.
       */
    'appPidLocation' => '/home/username/daemon/daemon.pid'
);
?>

There you have it. By setting the logLocation and appPidLocation options, you can tell the daemon where you’d like the log files to write to and where the pid should be created. Then, by setting your appRunAsGID and appRunAsUID properly, you’ll be up and running scripts as daemons in no time. While the GID and UID settings may have been evident in the aforementioned demo from the author, the logLocation and appPidLocation options may not have been so clear.

If you enjoyed this post, then please consider subscribing to my feed.

Our servers are getting ready to be awaken by the masses. As such, we needed to ensure our servers would not simply fall over if we should get a sudden influx of traffic when we open our doors to everyone.

When we first released our software, we quickly found that we needed to adjust some Apache and PostgreSQL settings in addition to installing a real PG connection pooler in the form of PgBouncer from the wonderful people at Skype. This is on top of our moderately heavy memcached usage that is already working at the application level. The specifics of this phase of development and the changes made to account for our load are for the next post. You can subscribe to my feed if you’d like to know when that is published.

For now, let’s get to the benchmarks.

Due to our previous changes, things were running smoothly. The various instances of the application were running well on their hardware. However, we hadn’t opened the doors for our service yet. We knew that we would need our servers to be able to handle much more load than they were currently handling. So, we set up some nearly identical to production servers and went to town with Apache Bench.

We’re currently running the following versions of applicable software for these tests:

• Debian 4.0
• Apache/2.2.3
• memcached 1.2.8
• PostgreSQL 8.1
• PgBouncer 1.3
• PHP 5.2.0

For the test, I used ApacheBench, Version 2.0.40-dev. Data was collected by running and entering the information into OpenOffice’s Calc. The graphs were also made with this.

The versions of the two caches that were used are Squid Web Proxy Cache 2.6.STABLE5 and Alternative PHP Cache, which is to be included in PHP 6.

The tests were run on a server that sits in the same data center as the other server to minimize latency issues. Each test was performed 3 times to try to get more accurate measurements. Every test was accompanied by the proper headers to ensure mod_deflate was being used. The number of tests (specified by the -n option) was 500 for any concurrency less than 100. For any concurrency greater than 100, 1000 tests were performed. The peak load numbers were gathered from watching top during each test.

First off, let’s look at the results of a 1KB image with and without Squid Cache:

With this smaller file, the results show that Apache is clearly able to deliver roughly 700% more requests per second with Squid

We can also see how Squid allows Apache to handle even 200 concurrent threads requesting the image without breaking a sweat.

In addition, the server was relaxing, not having to create a bunch of Apache processes, when you look at the load compared to with and without Squid.

The same test was performed for an 100KB image to see if the results would be the same.

With the larger file, we can see that the differences are less apparent.

Even the load times look almost the same when you are using a 100KB image instead of a 1KB image.

However, the kicker is when you look at the load that the server is placed under. With Squid, the web server doesn’t have to work as hard since it doesn’t have to create all those Apache processes to answer for the image.

So, one can clearly see that for smaller objects and files, Squid can have a remarkable difference in what you can push out of your server. The results are much clearer when using a testing platform that allows for one to download embedded content. However, that would be suitable for a post some other time. For now, we’ll move on to the results of our other caching solution.

Seeing how Squid provided such excellent results, it was definitely time to look for a caching solution for PHP. APC was the natural choice considering it’s inclusion in the new version of PHP. After exploring it, we installed it and were astonished again by the results. Our server, which was keeling over under 10-20 requests per second was now able to deliver 50-60 requests per second, a 400% increase in performance! But don’t believe me, I’ll let the charts speak for themselves.

These test were performed on a simple Hello World PHP application:

<?php
    echo 'Hello World';
?>

Our prepend configuration means both memcached and PostgreSQL are invoked when our simple Hello World test was run. This was ideal so we had a baseline when more testing is performed on our actual application code. Here are the results of those tests:

It’s easy to see how APC allows for many more requests per second to be served.

The load times offer an even better look at how APC allows the server to remain calm even under high load. Obviously 15-20 second load times was not acceptable. However, APC allowed the load times to remain under 5 seconds even with 200 concurrent threads slamming on the server.

Again, some of the best information is seen in the peak loads. The server is, quite obviously, doing much less work thanks to APC. This is especially evident in the 100-200 concurrency levels when the server was showing loads of 10-12.

So, if you haven’t thought about installing Squid Cache or a PHP cache, like APC yet, hopefully these benchmarks will be enough to convince you of their merit. Considering the ease with which these two caches can be setup and installed, you’re doing yourself and your hardware a disservice without them.

Well, that wraps up this post. Stay tuned for my next post for hints on tuning Apache configuration settings, PostgreSQL settings, and the trials and tribulations of moving an application from a simple site to a completely automated SaaS.

If you liked this post, then please consider subscribing to my feed.

Following the success (and subsequent hate-mail/threats) of a few posts, I decided to take a break from the blogging atmosphere for a little bit.

During this time, my fiance and I have had the chance to take a trip across the country to the capital of this nation, Washington, D.C. There, I was able to speak with one of the Senators from the state I live in. It was a brief meeting but the feeling of empowerment was worth it. Although I know the words that I said had little effect, it is still nice to have that weight lifted off of your shoulders.

“Which weight is that,” you ask?

“The weight of knowing that you are aware of problems going on around you without taking the time to do something about it.”

During the past month or so we have seen attacks on our own liberties in ways never thought possible. Criminal actions are being waived aside and criminals, themselves, are allowed to roam the world without having to answer to anyone:

Telecommunications companies (such as Verizon) are growing at huge rates with acquisitions occurring every few months it seems. Will it be long before we’ll be looking at the value of the KBps instead of the cost of dollars per barrel?

The one person, who it seemed had the drive (and ability) to cause the necessary change has failed us as well. He too, has subscribed to the “Timothy Leary-esque” command that the government seems to be trying to shove down our throats:

“Tune in, turn on, and MOVE ALONG, NOTHING TO SEE HERE.”

An excellent book by Bill Emmott, former editor and chief for the Economist was recently released:

In it, the author details how America will be surpassed within the next 20-25 years as the global economic dominator. It has started to increase my desire to look beyond the walls of our country for solutions to our future and opened up my eyes to that area of the world. Is it true that this country, the United States of America, is actually slipping in the realm of global economic dominance? Though the signs have been there for a while, there was always the inkling of doubt that America could be a great country again. However, these inklings have “tuned in, turned on” and are diminishing with a steady pace.

Whether it be economics, law, or government, it seems that the world as we know it (we being Americans), is changing beneath our feet every day… faster and faster. Our country, is being driven towards some end with the citizens being drug behind it in a fashion not dissimilar from Laramie, Wyoming. Where fear, hate, and stupidity cause the damage and the only people left feeling like winners are the ones driving the truck.

Do you feel fine?