imperialWicket

Increase PHP memory_limit on GoDaddy shared Linux hosting

2012-02-09T17:25:00+00:00

I have to look this up everytime, and for some reason it is really difficult to find a good resource. So after wasting another hour of my life searching random forums, here is what worked for me.

Using an FTP connection (it worked for me through a local FTP client or through the godaddy Hosting Control Center -> Content -> FTP File Manager), edit the php5.ini in your html directory. The full path is something like '/home/content/12/34567890/html/php5.ini' with different numerical values. Open that file. GoDaddy creates it for you when the account is created, if php5.ini is missing, someone probably deleted it, and you just need to make a new one.

In the php5.ini file, add the line:

memory_limit = 128M

The default is 64MB, which is enough for a lot of sites. Usually this needs to increase for the purpose of using particular extensions/plugins/modules in a CMS. Often image-handling extensions strongly encourage or even require 96M or 128M. I have not tested to see what the max is, but 128M is a good first step when 64M is no longer cutting it.

Now add a php file to that same 'html' directory. We need to use this for executing phpinfo(), and validating the change. Create a 'temp.php' file and add the line (be sure to add the open less than '<', i="" don't="" have="" time="" to="" wrestle="" with="" its="" display="" at="" the="" moment):=""
?php phpinfo(); ?>

If you load your new temp.php page in a browser (yourPrimaryDomain.com/temp.php), you should see the PHP version you are using and all the PHP info details. A couple of these are of primary interest:

Loaded Configuration File
memory_limit

Unless you got really lucky, "Loaded Configuration File" is probably "(none)" at this point. If so, then your memory_limit value is still "64M". The problem is that your server has a fastcgi process running, and hence the php5.ini contents were loaded before you made the change. In order to reload the new php5.ini file, you need to kill off the existent web processes. Go to your hosting control center, then Content -> System Processes, now use the 'End Web' button to kill the running processes. This does not impede your site loading, it just forces the server to spawn a new process for the next request.

If you refresh the phpinfo page, you should see updated values for Loaded Configuration File and memory_limit. The server should have loaded your php5.ini file, and the memory_limit now reflects the updated value.

A couple other notes:

Be sure you edit the php5.ini file in your root 'html' directory. If you have subdomains or addon domains with their own directories, you still want to edit the file in your root 'html' directory.
Lots of places have data about php.ini affecting PHP 4 and php5.ini affecting PHP 5. One would think that since GoDaddy is no longer offering PHP 4, you could use either php.ini or php5.ini. Nope. Stick to php5.ini.
Don't try to use the php_value_memory_limit directive in your .htaccess file, this causes the server to throw errors.
I see lots of accounts that indicate you must use GoDaddy's FTP File Manager to edit the php5.ini file in order for it to work properly. I can't confirm this, and I can only assume that this direction was coincidentally related to running processes for the users that reported the behavior.

Now delete the phpinfo() file; I called it 'temp.php'. You do not want to leave these laying about your server. While I'm offering suggestions, you should also consider transferring to another hosting provider.

Tuning Apache for a low memory server (like AWS Micro EC2 instances)

2012-01-09T16:40:06+00:00

One of my goals for 2012 is moving away from shared hosting and toward cloud and/or small VPS servers. For now, I am targeting AWS Micro instances for a lot of my efforts. Ultimately, I will probably move to Lighttpd or Nginx, but in the mean time I thought I would relay a configuration that is working well for me on low traffic sites.

For anyone seeing performance or stability issues on a micro instances (using LAMP) that get reasonable traffic, you are probably encountering something like:

WSOD (White screen of death) - most often this is actually a out of memory error in PHP
MySQL failing to start or getting killed - this is usually apache using all the memory and the kernel shutting down the MySQL server
Actual output of Out Of Memory errors in PHP - really the same as above
MySQL failing to start due to pthread create returned 11 - MySQL can't create a new thread, probably because apache is using too many.

The root cause of these problems is lack of memory. Before you shut down your micro instance in favor of a small instance, or go back to shared hosting, consider tuning apache down a few notches. The default apache configuration is actually quite inappropriate to a server with 1GB or less memory. The default changes a little from one Linux distribution to the next, but for reference I'll describe the Amazon Linux defaults.

Amazon Linux default apache config

This is all stored in the /etc/httpd/conf/httpd.conf file. There is a lot in this file, but most of what we want to discuss is near the beginning. Our biggest concerns have to do with KeepAlives and the prefork module. If you are using workers, you will also want to review the worker module configuration -- which is very analogous to the prefork module configuration.

Timeout

The default timeout is 60 (seconds). This is ridiculous. Have you ever waited 60 seconds for a site to load? I turn this down to the 20-30 second range.

KeepAlive

KeepAlive defaults to Off in Amazon Linux. Enabling KeepAlive can avoid generating/killing so many apache child threads, but if your users tend to only view a page or two, this makes no difference, because apache only persists the thread for a given connection. If you have high user engagement, you probably want KeepAlive on, but you should tune it down to keep your total apache thread count low. I have it enabled in my example config below, but for many of my sites, visitor engagement is relatively low, and I simply leave it disabled.

MaxKeepAliveRequests and KeepAliveTimeout

If you enabled KeepAlive on your low memory server, you should reduce the MaxKeepAliveRequests and KeepAliveTimeout. MaxKeepAliveRequests defaults to 100, which seems relatively low, but how many users do you actually have making 100 requests to your server per session? Related to this is the KeepAliveTimeout value, which defaults to 15 (seconds). In my mind, 15 seconds is longer than a short page view requires, and shorter than a long page view requires. That is, if someone hits my site and realizes the page is not what they want, they look at tags/categories/menu/whatever and decide to look at something else. The time required for this is usually more like 5-10 seconds. There is no reason to keep the thread alive for 15 seconds. The opposite end of this spectrum is a user who reviews an entire page, and then elects to review a previous or alternate article, in this scenario more than 15 seconds often elapses, and the user generates a new thread anyway. If you enabled KeepAlive, I recommend reducing KeepAliveTimeout to 5 or 10 seconds. MaxKeepAliveRequests probably won't be an issue, but 25 or 50 is likely to behave in the same way as 100, and under the low chance that something awkward is happening, the lower maximum will curtail the issue sooner.

Prefork Module

Prefork is where the real magic happens. This is where we can tell apache to only generate so many processes. The defaults here are high, limiting you to a max of 256 servers. Just to put this in perspective, let's say you get 10 concurrent requests for a php page, and that page happens to require around 64MB of RAM when requested (well within the default php memory_limit of 128MB on Amazon Linux). That's around 640MB of RAM usage on your 613MB micro instance. And that's with only 10 connections - apache is configured to allow 256! I scale these down a lot, usually sticking with 10-12 MaxClients. As we mentioned in our example, this is still a dangerous number because 10-12 concurrent connections would use all our memory. If you want to be really cautious, make sure that your max memory usage is less than 613MB (on an AWS micro instance - 512MB is common on VPS from other providers). Something like 64M php memory limit and 8 max clients keeps you under your limit with space to spare - this helps ensure that the kernel won't do something crazy like killing the MySQL process when your server is under load.

You can play with the MinSpareServers, MaxSpareServers, StartServers, and MaxRequestsPerChild; but within the context of less than 20 MaxClients, making changes like 3 StartServers vs 5 StartServers will have almost no visible impact.

Without further ado, here are some values to get you started. Tweak away, and have fun - welcome to httpd.conf (use apache2.conf if you're on debian).

/etc/httpd/conf/httpd.conf

Timeout 30
KeepAlive On
MaxKeepAliveRequests 50
KeepAliveTimeout 10


    StartServers          3
    MinSpareServers       2
    MaxSpareServers       5
    MaxClients            10
    MaxRequestsPerChild   1000


# if you are using workers, update the IfModule worker.c section similarly.

/etc/php.ini

memory_limit = 100M

How about some open source days?

2011-12-29T20:56:16+00:00

I want open source days. Add those to the list: healthcare, dental, prescription, vision, vacation days, sick days, etc. and open source days.

Many devs are complaining about perks, or lack thereof. Alternatively, many employers are advertising ridiculous benefits. One thing some companies offer is x% of your time for R & D, personal projects, or open source. This is close to what I want, but it fills a different need. Anyway, the following would be quite appealing to me.

----------------------

Some Position

Description: Responsible for doing some stuff. Full stack, rockstar, ninja, ginsu, terminator-alpha-squadron-hacker extraordinaire geek, whatever other catchy new descriptors are 'in' right now. Oh, and the company is really awesome, so: open source, beer, caffeine, hardware choice, cow, some cash money, and this crazy-niche nerd-lore adult toy.

Benefits: Equity, healthcare, 401k, 5% required research and development time, flexible schedule, 3 weeks vacation, 10 annual sick days, 5 open source days.

----------------------
Disclosure: I probably wouldn't apply anywhere that uses ninja/rockstar-esque terminology.

Open source days?

I don't think I'm the only one who has occasional trouble with traction in the morning. Or on the occasional Wednesday. Or Monday. Or Friday. Or...

Sometimes I am just a little burned out. My candle is going at both ends, and occasionally I just need to revert to a vegetative state for a while to get those brain juices flowing again. This is what vacation and/or sick days are for (most people need to use these more). Other times I have the urge to be extremely productive, but I have no motivation to move forward on my current task. These are the times when I'd like to be able to take an 'open source day'. I might want to work on a personal project that I have open sourced, I might want to support an existing open source project, I might just want to take a few open source solutions for a test drive. All of these are productive in their own right, but an employer is perfectly justified when highlighting that these activites are not offering (or rarely offer) a short-term and noticeable boon to the current task at hand. Solution: use an open source day!

Alas, I don't have open source days. On my 'off-days', rather than simply diverting my productivity to some other project (where I might be at peak productivity), I dick around fixing bugs at a snail's pace, reviewing reddit and hacker news obsessively, deleting spam comments from my blog, or maybe going through the xkcd catalog (again).

Some of the employers or productivity gurus out there might be concerned about this tactic. You might suggest that these are the days when you should employ productivity technique x, or that you've found technique y in combination with list-type z to work under similar scenarios. I only remind you that I said 5 days in a year. I'm not talking about resolving each and every Tuesday-lull by donating 8 hours (or so) of time to a random project. But about once a quarter I think some dedicated and endorsed open source involvement would be rejuvinating and productive for all parties involved. The employer gains some open source credibility, and possibly some employee education both for the individual and others with 'what are you working on?' and water-cooler-type insight. The employee gains experience on something that may or may not be directly in line with their position (both of which are productive). The open source project gains whatever it gains - evangelism, bug fixes, code cleaning, documentation, user support, whatever. And all this is gained at the expense of 8 man hours.

It's worth noting that the 8 man hours you exchanged were probably more like 2 man hours, because I wasn't likely to accomplish much that day anyway. Not only that, but the next day's 8 hours are more like 12, because I'm likely to be good and recharged after such a welcomed mental diversion.

Some may also say that an open source day is a perfectly good use of R & D time, or that this is a justifiable usage for vacation/sick time. While I can get behind both of these ideas, I am talking about an offering that would appeal to me. If an employer or potential employer announced that I get 5 open source days to use at my own discretion (usage within reason, of course - no open source weeks immediately prior to a launch date), it would offer a notable plus for said employer. I see this as an employer going out of their way to say a few things:

Open source is important to us.
We want open source to be important to you.
We trust your judgment, if today would be more productive for you spent on open source project x, we support that decision.
We know that whole-heartedly diverting your attention can sometimes promote epiphanies, strokes of genius, or just light bulbs with resolutions to bugs that you'd otherwise waste days trying to fix.

I doubt we'll see this offering (or maybe I'm just looking in the wrong places?), but I think it would be grand to take a proper open source day.

iwBase: A responsive starter theme for Habari

2011-12-18T17:23:48+00:00

My Summer Infant video monitor experience (fail)

2011-12-15T14:59:48+00:00

This is a tale of consumer experience and a formal venting of my frustrations with our Summer monitoring solutions.

About 18 months ago, we had a baby. Joy, frustrations, cute, poop, sleeplessness, etc. When we decided to move the baby to a location more than a few inches away from one of us, it became clear that a video monitor was a must have. The technology is there, it is not terribly expensive, and it surprasses the audio-only experience to a great degree. After cautiously reviewing Amazon ratings and the myriad baby item review sites, we came to the conclusion that Summer offers the best product for the price. They have nice features (remote camera direction/zoom capabilities, pairing multiple video cameras to a single monitor, digital transmission, and color displays), and they were constantly on sale somewhere.

We found a great deal on the BestView Handheld Color Video Monitor. Knowing that we could get another video camera later, and that the batteries are standard rechargeable batteries (that were cheap and easy to replace when they stopped holding a sufficient charge), we pulled the trigger on this purchase and didn't look back. That is, until we were 'blessed' with our second bundle of joy not long after.

In general, we were completely pleased with the BestView. The rechargeable batteries slowly diminished, but we could count on it lasting for at least the day. As I mentioned, when it came to needing a charge more than once a day (we kept it plugged in at night), we purchased new rechargeable AA-sized batteries, and the device was like new again. The batteries were around $20.00 from Summer directly, and we found them for $7 from either Amazon or all-battery.com (just be sure you get the same capacity). So, happy with our video monitor, we patted ourselves on the back and decided to purchase a second video camera for our monitor. Queue let-down music.

Summer changed their product line and no longer sold a video camera compatible with our device. Now, I could understand this occurring over the course of time, but the BestView was an multiple-award winner in 2010 (when we purchased it), and in January/February of 2011, when we were looking for a second video camera, it was not available from Summer. If you locate reviews on major retailers, the primary complaints about this monitor and its successor's cameras is the lack of compatibility. At this point, oh well. They changed their product lines, they want us to buy the new version if we need multiple video cameras at this point.

So we purchased a BabyTouch Digital Video Monitor from Summer. After all, this was brand new, Summer was obviously updating their product lines around the new monitors, so we should be safe for at least a few years. And the last video monitor from Summer was a good purchase, we were happy with the product itself. Our only frustration was that when we wanted to expand with an additional video camera, the products were no longer available. The BabyTouch: at a glance, everything seems nice. Lower profile monitor, lower profile video camera, touch screen, it even has an intercom.

After using the BabyTouch for only a short time, you realize that smartphone-syndrome affects any and all touch-screen-type devices. The bigger the monitor, the more advanced the features, the harder they are on battery life. From day 1, the BabyTouch rarely made it an entire day without requiring a charge. I'll admit we we weren't as dilligent as we could have been in turning it off when not in use, but with 2 young children on different sleep cycles, it was in use a good deal of the time (though we were attentive to turning off the screen when we weren't actually viewing it). So battery life sucks. Oh, and Summer decided it would be a good idea to use a non-standard battery pack, so no more cheap replacement batteries. The clip on the back is also far inferior to the clip on the BestView, as such, the BabyTouch finds itself in pockets a lot. What happens to a touch screen with no unlock feature when it's in your pocket? It turns on. And you pocket-manipulate the camera (which makes noise in the room where child was sleeping), and you drain the battery by having the screen on, and you change the camera that you're monitoring, and you manipulate the brightness settings. And the power button? Don't get me started on this. I can understand forcing the user to hold down the power button to turn the device off, but why do I need to hold down the power button (for a full few seconds) in order to turn my device on? One final minor nag, and I can't remember if the BestView suffered from this issue or not (I didn't think so, but I can't find details on it, and I no longer have the monitor to check), the BabyTouch doesn't persist any settings. It would be nice if when I turn it on, I didn't have to turn the volume way down, and reselect the camera I was previously monitoring.

So with my new pocket full of minor complaints and a lingering frustration with the fact that we had to purchase a new monitor and two cameras, instead of just the second camera that we had planned to purchase, I continued on my merry (sleepless) way. And then the fun started. As battery life continued to diminish (we've only had the device for two months now), we occasionally found that the monitor was simply turning off. "How often do you restart the device?" "How much battery was left?" "Blah blah blah..." I understand how electronics devices work, and it wasn't turning off because the battery was dead. The device just sporadically powered down. This is NOT what I was looking for in a baby monitor. And then the final blow - this morning the device powered down on it's own, and now it doesn't power on.

One more frustration to add to the pile. Whatever, at this point I've written Summer off of my preferred product manufacturer list anyway (even though they still offer the best features for the price in video monitors). And it does not really matter, we've only had this device for a couple months, surely they will replace it. And so it gets better (worse).

Summer will replace the monitor, but only after they receive the defective unit. Now, parents out there on these tubes that comprise the internet, let that settle. I have just realized that my already frustrating and lack-luster monitor is no longer functioning. I call the manufacturer, and they say something to the effect of, "Sure, we'll replace that. We just need to receive the defective unit first. We will overnight return packaging, and you can expect your replacement in 7-10 days." You've got to be F-ing kidding me. A baby monitor. That monitors my baby. 7-10 days? You can't overnight me the replacement and then upon receiving a mangled or functional origin device, just charge me for the device you shipped? Who designed this system, and what sort of customer service/satisfaction numbers are they targeting?

Summer, welcome to the wonderful world of epic customer service fail. At this point I would gladly pay the extra cost for a competitor's sub-par product, just to have that product: A) work. and B) receive reasonable support given the product and the services it entails. Summer, I will no longer be recommending your monitors to anyone, congratulations.