The Blog of a Programmer
PHP
PHP-FPM ondemand!
01 week ago
PHP 5.3.9 came out on Jan 10th and reading over the changelog I geeked out.
http://php.net/ChangeLog-5.php#5.3.9
Specifically because of this line item:
Implemented FR #52569 (Add the “ondemand” process-manager to allow zero children).
Go check out that bug and the related patch. It’s going to be amazing to see shared hosting services take advantage of PHP-FPM with the ondemand process manager option. In the past, when you started PHP w/FPM, you had two options dynamic or static, both of which created a pool of php processes at startup. Using ondemand allows for the php children processes to get started when there is a request that needs to be handled.
I just switched my server over to a custom php install using this feature, here was my memory usage before enabling it:
free -m
total used free shared buffers cached
Mem: 1358 1242 115 0 0 342
-/+ buffers/cache: 900 457
Swap: 0 0 0
Immediately after implementation this is my memory usage:
free -m
total used free shared buffers cached
Mem: 1708 518 1189 0 0 491
-/+ buffers/cache: 26 1681
Swap: 0 0 0
I should note that my memory manager increased the available memory on my machine while it was compiling PHP.
Amazing.
Memory Manager v1.1 is Coming Soon
02 months ago
First off, thanks to everyone who has been actively testing and using this application and contacting me with feature requests and questions. The latest version of the memory manager (v1.1) will be coming out soon and with it will come, what I consider to be, an essential feature. With every resize there will be a dump of all running processes sorted by memory usage.
What does that mean to you?
Chances are you’re using this memory manager to help figure out where your memory is going and keep your services up and running. Having a snapshot of your processes, taken when the script sees the need for a resize, will tell you where your memory is actually being used. Very soon you’ll be able to review your logs and click on the “process log” link. I’ll be posting an update to the news you see within the memory manager when the newest version is ready.
Thoughts on VPS Memory Management
011 months ago
Recently, 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.
A Few Notes for Building PHP 5 on DreamHost PS
5The information here is being used to overwrite the original PHP install on a DreamHost PS, mostly because I want to enable SOAP and XMLRPC.
Since the OS is currently Debian Etch I need to download, compile, and install xmlrpc-epi:
http://xmlrpc-epi.sourceforge.net/
I want to enable SOAP so I modified the configure command to use:
‘./configure’ ‘–prefix=/usr/local/php5′ ‘–datadir=/usr/local/php5/share’ ‘–localstatedir=/usr/local/php5/var’ ‘–enable-sockets’ ‘–enable-fastcgi’ ‘–enable-bcmath’ ‘–with-pear=/usr/local/php5/lib/pear’ ‘–with-mysql=/usr’ ‘–enable-calendar’ ‘–with-mhash=/usr’ ‘–with-kerberos’ ‘–enable-force-cgi-redirect’ ‘–with-config-file-path=/etc/php5/cgi’ ‘–with-imap’ ‘–with-imap-ssl’ ‘–with-gd’ ‘–with-xsl’ ‘–with-ttf=/usr’ ‘–with-freetype-dir=/usr’ ‘–enable-exif’ ‘–with-jpeg-dir=/usr’ ‘–with-png-dir=/usr’ ‘–with-zlib-dir=/usr’ ‘–with-pdo-mysql’ ‘–enable-ftp’ ‘–with-curl=/usr’ ‘–with-pspell=/usr’ ‘–enable-mbstring’ ‘–with-mcrypt’ ‘–with-mysqli’ ‘–with-openssl=/usr’ ‘–with-gettext’ ‘–enable-soap’
I also had wanted xmlrpc but ended up having so much trouble trying to get PHP to compile with it enabled that I went the route of downloading the debian etch package “php5-xmlrpc” from here:
http://packages.debian.org/etch/php5-xmlrpc
I extracted the contents using:
dpkg –extract package.deb folder/
Then pulled the xmlrpc.so file and put it into my extension dir and added the following line to the php.ini:
extension=xmlrpc.so
It should also be noted that the old configure command contained:
–enable-trans-sid
–with-xml
–with-xslt
–with-xslt-sablot=/usr
–with-dom-xslt=/usr
Which are PHP4 configure options and not needed for PHP5.
Finally, there are LOTS of dependencies that needed installation, can’t remember if these are all correct:
sudo apt-get install libcurl3-dev
sudo apt-get install libc-client-dev
sudo apt-get install libmcrypt-dev
sudo apt-get install libmhash-dev
sudo apt-get install libaspell-dev
sudo apt-get install libpspell-dev
That’s all for the time being, I’ll make a final post when I have all the details (and a working install) up and running.
It looks like it’s all up and running smoothly! There was one last catch, when running php through fastcgi you need to manually replace a file:
/dh/cgi-system/php5.cgi
With the file that was created here:
/usr/local/php5/bin/php-cgi
So a quick:
cp -a /usr/local/php5/bin/php-cgi /dh/cgi-system/php5.cgi
Did the trick.
FLV Media Player with PHP Streaming
11Modified to Work Smoothly with DreamHost
***UPDATE***
The example script has been updated due to the help from MattaProductions.com – a problem was noticed in that the swfobject.js script wasn’t being called in the example.html page!
***END UPDATE***
I’ve seen some people have trouble with the media player on DreamHost (mostly due to instructions). I’ve put together a simple, easy to install, and use flv player package. Hope you DreamHost people’s like it! I’ll be making changes to this post as I build out a nice set of instructions as to how to make it work, but for most people, this should be pretty easy.
Please note this is meant to be used on DreamHost because of the way I build the filepath to the videos. Also, you can NOT use remote video files, because the stream script will only attempt to use videos inside your filepath. Not to mention DreamHost gives a HUGE amount of space/bandwidth that can be used to play your videos from.
You can see an example of it working here. (The video is from a buddy of mine!) Then download the files!
Also if you have trouble with having your videos que up make sure you run it through the FLV MetaData Injector!
MD5 Hashing and Salt
34 years ago
I just read a great post by Marcel Oelke who runs http://md5.rednoize.com/. He’s got a great way to access his webservice and then check if a user’s password is insecure. Even if you are using MD5 before storing the password, I certianly hope people aren’t storing passwords in cleartext, it may not be secure.
I know many people don’t add some salt before storing the password and MD5.rednoize.com really is the perfect example as to why you should be salting all passwords! Even if you have a single sitewide salt - prepending it to a user’s password before creating the hash is a powerful way to prevent the use of a database like the one which runs MD5.rednoize.com matching against your database. So basically in PHP:
$salt = “ThisSuperLongStringWillProtectMyUsersAgainstInsecurePasswords”;
$userpass = $_POST['pass'];
$md5pass = md5($salt . $userpass);
When your user then attempts to login you’ll duplicate the same process. I personally would keep the $salt in a file outside the normal webroot.
Now the chances of a site having the matching hash to your users password – even if the pass is ”word” is MUCH less likely. I hope this explains what it means to salt your passwords.
You can read Marcel’s post and learn how to call his webservice here:
http://blog.fl3x.de/2005/11/10/checking-password-strength-using-md5rednoizecom-and-ajax/
Top Commenters