Nothing’s cooler than writing a bad-ass site or application and watching it gain popularity and a significant user base. By the same token, nothing’s more frustrating than watching your app fall on its face when its running under high load. If you’re like me, you know how disheartening this can be, as it usually means that its time for a hard dose of reality: your code probably isn’t as awesome as you thought it was.

Or is it? There’s a whole slew of things that a person could point a finger at regarding slowly running code. The most-oft thing that gets called out is code with a lot of overhead (a ton of includes, excessive logic, and the like), and right behind that is poorly designed databases (unoptimized indexes, no indexes, ridiculous amounts of joins, blah, blah, blah). Well, let’s assume for a minute that you’ve got a fair amount of experience under your belt, so you know your code is pretty damn optimal, and you also have a DBA buddy that took a look at your database and helped you tweak it up a bit. What do you do if this isn’t enough? Before you say, “throw more / better hardware at that mo-fo”, why not take a moment and learn about APC: Alternative PHP Cache…
(more…)

Let me first start by saying that I’m currently working at a startup, and for anyone who’s ever done this, you know it sucks up a LOT of your time… in my case pretty much all of it. I’m not complaining by any means, I’m doing some of the coolest work I’ve ever done in fact! However, I just wanted to explain my little posting hiatus…

Anyway, on to the matter at hand. I have found myself in a position where I am writing scripts that may need to upload fairly large files. My scripts were timing out, and I couldn’t seem to figure out why. For the unitiated, there are some standard things that you usually do to both your php.ini and in your script in this situation:

• Set your max_upload_size in php.ini higher (it’s only 2M out of the box)
• Set your script timeout to never (set_time_limit(0); in your scripts… don’t do this in your php.ini)

However, it turns out there are some other php.ini config variables that you may need to look at:

• memory_limit - This may also be an obvious one to some people, but for those of you who don’t know, this restricts how much memory PHP is allowed to consume while processing. When working with images and large files, this needs to be upped to accommodate these needs.
• post_max_size - This was the one killing me, and it was a major “Duh” moment as well. If you aren’t allowed to create a large post, how can you expect to upload a large file?? This should be set the same as your max_upload_size.
• max_input_time - the time that the script should spend in accepting input. This is setting defaults to 60 seconds, and you will probably need to update this as well

That’s about it! Quick and simple solution to a problem that is probably pretty common.

So, I have to say that I’m no server admin, but I certainly can accomplish most everything I need to do. Today I was working on setting up php on a production server to fit some unique needs, and ran into an interesting problem. The only unique thing about this setup is that mysql is installed in a non-standard way (two instances running on the same box so we can have replication), and basically all that was weird about this was the path to the mysql binaries and support files. So, what went wrong anyway?

Well, I got everything set up, and did my first test promotion from the production environment. I hit the site, and… nothing. Not an error message, just a white, useless screen. First thing I checked was that my show_errors directive was set to on, and it was, so no luck. The next step was to restart apache and check for any errors… again, nothing. Starting to get a little frustrated, I took a peek at my error logs (/var/log/httpd/error_log for the unitiated), and discovered a wonderful message:

[notice] child pid 32222 exit signal Segmentation fault (11)

As any person scratching their head would do, I hit up google… to no real avail. Just a bunch of php bug reports. So, what happened, and how did I fix it? Read on…
(more…)

I’ve been using zend studio for quite some time now, and have found it to be extremely useful. My only compaint with it is that it’s written in java, but I do understand the cross-platform benefits of doing this. I’ve also heard from various people that they have issues with it lagging and crawling along, but never had any issue myself… until today. I just switched jobs, so I naturally needed to install studio on my new workstation. Well, wouldn’t you know, but I became one of those people. I did a lot of searching through many forums and came across many different things to try, but none of them seemed to work. Not being one to give up, I finally found the solution to my problem, and it was baffling to say the least. Oh well, problem solved, and I can get on with my day. However, to save everyone the time that I spent pouring over the forums, here’s a list of all the possible solutions for speeding up zend studio… (more…)