Simple Setup of PEAR on a DreamHost Account
0While DH installs a basic set of PEAR modules it’s a common situation need others, when that situation comes up you’ll often be referred to the PEAR article on the DH wiki. I’ve taken the instructions found there and created a shell script you can download and execute, it’ll do the following:
- Creates a .pearrc file in your home directory.
- Sets the download_dir, cache_dir, and temp_dir to folders within your /home/user/pear directory
- Sets the PHP_PEAR_PHP_BIN variables by adding “export PHP_PEAR_PHP_BIN=/usr/local/php5/bin/php” to your .bash_profile
- Modifies your PATH variable by adding “export PATH=/home/user/pear:/usr/local/php5/bin:$PATH” to your .bash_profile. This change also sets the PHP5 binary as the default for your shell.
Next time you call pear you’ll be using your custom settings and when you attempt to install any modules it will be done within your home directory. Now in order to use these PEAR modules in your application you will need to add the following to your app:
$pear_user_config = '/home/user/.pearrc';
set_include_path('.' . PATH_SEPERATOR . '/home/user/pear/php' . PATH_SEPERATOR . get_include_path());
Make sure to update “user” in the path to the actual user you are using and you’ll be set.
Download and Execute the Script
Just execute the following in a shell session:
wget http://files.gimmesoda.com/dreamhost/install_pear.sh; chmod 0744 install_pear.sh; ./install_pear.sh;
You can download and review the shell script from here, just open it up in a text editor of your choice.
Thoughts on VPS Memory Management
0Recently, I have been spending a significant amount of time working on an application which manages the amount of memory assigned to a DreamHost Web VPS. During the time I’ve spent developing this several choices had to be made in what the real goal of the application had to be. When it comes to memory management on a server there are really two goals which don’t always play well together.
Goal One: Save Money
Many people seem to have a belief that just because the site/s are on a VPS, even with memory set as low as possible (300MB of RAM assigned to a machine in the case of a DreamHost VPS), they will have perfect or near perfect uptime. Sadly, this is not the case and often times this misunderstanding/confusion can lead to serious downtime and frustration. Ideally, for people who are trying to have the lowest amount of memory usage possible, a memory management application would realize that there is a need for more memory, calculate an estimated amount of memory needed to handle the increased usage, resize the VPS as closely as possible to that need, then downsize as soon as the memory is no longer needed.
There is one major issue with this scenario:
Creating estimates regarding the amount of memory needed in an environment where usage is constantly changing, is a massive challenge. To be more specific; since the ability to resize a VPS tends to take some time (anywhere from 1-5 minutes), it is possible for memory requirements to have increased during the time that the need was detected and the memory estimate was created. This could create a resize on a VPS with too little memory, causing problems for the website/s on the VPS, as the machine is given too little memory to handle the increased need.
Goal Two: Keep Services Running
If you are on a VPS, chances are you’ve outgrown shared hosting or are looking for more stability and control over the environment your applications run on. If you’ve got a decent understanding of servers, applications, and websites, you may also understand that you need to have enough memory to run all the processes and handle the requests to your sites. Often times simply setting your service to the lowest amount of memory possible is going to be asking for failed script executions and the dreaded 500 error being displayed on your site.
So with this understanding, some people go to the extreme and max out their VPS resources. At DreamHost that means $200 a month for services (4GB worth of RAM) which may not be fully utilized (and most likely are not). So the question here becomes how to balance cost and the need for memory, in order to keep services running without paying the maximum amount at all times.
A Hybrid Memory Manager Focused on Uptime
With these two potential goals in mind, I had decided to mainly focus my attentions on goal two. While I do understand the need to keep price as low as possible, it is my personal belief, gleaned from experience, that a downed website is more damaging to the bottom line than a slightly larger payment for hosting services. So with this in mind, the memory manager was created to focus on uptime, while still saving time and money for those who manually resize throughout the day, and potentially over-allocate memory for their site/s.
All this being said, I am quite excited to be releasing this software soon. The status of this release is currently closed beta. However, if you are interested in testing this on your DreamHost VPS, please contact me. I am looking to increase the pool of Beta testers before the official release.
Code Fix for Missing PATH_INFO
0Many applications seem to be using the $_SERVER['PATH_INFO'] and related variables in their router section of code to figure out what information or page is being requested without having to write rewrite_rules for each possible request. It’s smart really! What about the web hosts that aren’t setting this information due to whatever reason?
While there are ways to getting this fixed on the server side, where I do agree it should be fixed, an application should be able to handle running in as many possible environments as possible. With that in mind I’ve found a way to ‘fake’ the information in PATH_INFO when it isn’t being set through the use of the argv array.
$path = (substr($_SERVER[argv][0], 0, 1) == "/") ? $_SERVER['argv'][0] : false;
This has been useful in my current patch for Concrete5 and should be useful for any app that depends on PATH_INFO.
Enjoy.
Pretty URL’s with Concrete5 on DreamHost
6Update:
For those who are curious this patch was submitted to the developers and the still open bug report and fix can be found here:
http://www.concrete5.org/developers/bugs/5-4-1-1/pretty-urland039s-with-fastcgi-and-404and039s/
I’ll be getting this to the developers soon but for anyone using Concrete5 on DreamHost and having trouble with enabling pretty url’s apply the following patch and make sure you check the .htaccess – it should have a ? before the /$1
The patch also includes an update to the controller which tells you what to put in your .htaccess.
http://files.gimmesoda.com/dreamhost/software_patches/concrete5/request_patch/dh_request.patch
Which means you can do the following from the directory that holds the concrete5 files:
wget http://files.gimmesoda.com/dreamhost/software_patches/concrete5/request_patch/dh_request.patch;
patch -p0 < dh_request.patch;
Enjoy!
$12.99 SSL Certs at GoDaddy!
0Updated Pricing for GoDaddy SSL Certificates
Forget about the $14.99 price of the GoDaddy SSL certificate (I’ve removed that link). Go pick up a cheap SSL certificate, no clue how long this sale will last!
Save 50% Now on Go Daddy SSL Certificates! Only $12.99!
Also if you’re interested in hosting with them check out their specials here:
—————————-
This is something I rarely do, I’m now promoting a rather amazing deal from GoDaddy! They’ve currently got a great deal for SSL certificates. I haven’t seen them cheaper then this in a LONG time. So take advantage of it while you can. Who knows when they’ll stop accepting it.
$14.99 SSL Sale!
There is one thing I do use GoDaddy for, rather consistently in fact, that is their SSL Certificates. GoDaddy SSL certs are the cheapest in town AND recently they’ve had an amazing promotion running. SSL Certificates for only 14.99! Purchase a few of those while the promotion is going on, save the credits for when you’ll need them, it really does add up.
FLV Streaming Through Nginx Using JW FLV Player
0I’m quite happy to report that the Nginx flv streaming module is part of the default Nginx setup on a DreamHost VPS. I finally took some time (much less then I thought it would be) to modify one of my old pseudo-streaming php scripts with a drop in replacement (3 lines of code) that basically just handles a redirect and uses the flv streaming module instead. You can grab a copy over here:
http://files.gimmesoda.com/dreamhost/nginx/nginx_stream.php
I use this particular script in conjunction with the rather popular JW Player:
http://www.longtailvideo.com/players/jw-flv-player/
However, at this point it looks like the newest versions of their player no longer recommends the use of streaming through a script and provides this functionality directly. This script is more for people like myself who don’t feel like upgrading to their branded versions of the player. The plugin functionality sure does tempt me but at a price of $89 for a video player to be used on a single site, I think I’ll stick to my current version, at least for now.
Brief and Expected Downtime
0Gimmesoda.com may be down for a brief period of time today – I’m transferring the domain registration to a new registrar and though I expect things to go smoothly I figured I’m put up fair warning.
-JJ
GimmeSoda.com Server Move: XCache, W3-Total-Cache and Nginx = Awesome
2I’ve moved this site (gimmesoda.com) over to a test server (Private Server) I’ve got running on DreamHost. This server is running Nginx instead of Apache, both machines (the PS it was running on before, and the PS it is now running on) are set to 2GB of memory and the software setup of WordPress is exactly the same.
Why:
Apache can be a memory hog.
As more and more traffic comes into a website the Apache process continues to spawn memory hogging worker processes and during my basic testing I saw over 90 apache worker processes spawned at one time. Each of those processes were taking about 23MB worth of memory when spawned (23 x 90 = 2070MB) which maxed out the $100/month PS machine and returned several hundred errors at 100 concurrent connections.
Nginx handles concurrency much better and requires far less memory.
When the site was moved over to Nginx I ran the same test (1000 requests with 100 concurrency) and memory usage was under 800MB, it also returned 0 errors compared to the 664 from the use of Apache. Also, you should take note of the speed between the two in the results below, Nginx returned all requests in under 1s.
WordPress Cache Settings:
I’ve switched off the use of WP-SuperCache, which uses disk based caching and provides no further options such as opcode caching (APC/XCache/eAccelerator) which W3-Total-Cache does provide! Not only does it provide a static page cache as well as opcode options but it incorporates minify options, database, and object caching among other features.
All cache options have been set to XCache rather then disk, after all reading from memory is faster then reading from disk.
The Setup:
- WordPress v3.0.1
- Theme
- I am using the Mystique theme, which thankfully does NOT use the timthumb.php script (I am NOT a fan of it).
- Plugins
- Akismet
- All in One SEO Pack
- Categories to Tags Converter Importer
- Clean-Contact
- Dragon Design Sitemap Generator
- DreamHost WordPress Backup
- FeedBurner FeedSmith
- Google XML Sitemaps
- Paypal Donate Plugin for WordPress Widget Support
- Permalinks Moved Permanently
- Piwiks Analytics
- Twitter for WordPress
- W3-Total-Cache
- WordPress.com Stats
- WordPress Importer
- WP-FLV
- WP-PayPalDonate
- Theme
AB (ApacheBench) Results:
| Apache Results | Nginx Results |
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.gimmesoda.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
Server Software: Apache
Server Hostname: www.gimmesoda.com
Server Port: 80
Document Path: /
Document Length: 30876 bytes
Concurrency Level: 100
Time taken for tests: 6.912 seconds
Complete requests: 1000
Failed requests: 664
(Connect: 0, Receive: 0, Length: 664, Exceptions: 0)
Write errors: 0
Non-2xx responses: 664
Total transferred: 10878952 bytes
HTML transferred: 10588808 bytes
Requests per second: 144.67 [#/sec] (mean)
Time per request: 691.234 [ms] (mean)
Time per request: 6.912 [ms] (mean, across all concurrent requests)
Transfer rate: 1536.96 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 15 164.4 7 3013
Processing: 24 511 782.2 190 4087
Waiting: 17 503 778.0 188 4074
Total: 46 526 792.6 196 4091
Percentage of the requests served within a certain time (ms)
50% 196
66% 266
75% 499
80% 744
90% 2018
95% 2703
98% 2983
99% 3060
100% 4091 (longest request)
|
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.gimmesoda.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests
Server Software: nginx/0.7.65
Server Hostname: www.gimmesoda.com
Server Port: 80
Document Path: /
Document Length: 30874 bytes
Concurrency Level: 100
Time taken for tests: 3.158373 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 31348328 bytes
HTML transferred: 30961170 bytes
Requests per second: 316.62 [#/sec] (mean)
Time per request: 315.837 [ms] (mean)
Time per request: 3.158 [ms] (mean, across all concurrent requests)
Transfer rate: 9692.65 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 22 11.8 20 63
Processing: 36 184 108.6 144 874
Waiting: 8 34 24.6 26 279
Total: 37 206 111.5 166 913
Percentage of the requests served within a certain time (ms)
50% 166
66% 209
75% 251
80% 273
90% 347
95% 405
98% 569
99% 641
100% 913 (longest request)
|
More Information
Nginx: A web server written to address the C10K problem. http://wiki.nginx.org/Main
XCache: A fast opcode cacher, it’s a PHP extension. http://xcache.lighttpd.net/
W3-Total-Cache: A brilliant (and free) wordpress caching plugin that goes the extra mile. http://wordpress.org/extend/plugins/w3-total-cache/

Top Commenters