APC, Custom PHP5, phpize, autoconf issues

I used the php5 develscript from the wiki:

And successfully installed php 5.2.3. After that, I installed the autotools packages, and got the newest source for APC. When I try to phpize it (/home/dreamuser/php/bin/phpize) it shows the build numbers, and says it can’t find autoconf. When I try to specify PHP_AUTOCONF using export, it still won’t work. Any suggestions?

I got it to compile, as it turns out my .bash_profile had my path screwed up…

I dropped the apc.so file into my extensions directory, and added it to php.ini, but no dice. It isn’t loading, it is like my php (5.2.3) isn’t even seeing it in the ini file. I disabled zend’s stuff in the ini, and those changes showed, but no APC. Help!?! Why does it seem nobody on this forum is even willing to say anything?

Well, in your two posts in this thread you have asked two questions, so I’ll give it a try:

“Any suggestions?” (from the first post) - No, not really. The wiki article is pretty straight-forward, though many seem to have trouble with it. It is very much a “without support” thing, so there is a bit of an assumption that if you are going to do this, you should know how.

“Why does it seem nobody on this forum is even willing to say anything?” - Probably no one has taken the time to try to decipher what you may have done that is preventing the install from working as you expected. The common first advice is to retrace your steps in following the Wiki article and the APC docs to see what you have missed, or done incorrectly.


Sorry, I’ve been really busy this week playing Zelda: Twilight Princess. Yes, it sounds lazy, but I’ve been dying to play it for months now! :stuck_out_tongue:

I’ll get around to a wiki doc on it by Friday, and sorry I have no idea what you’re doing wrong from your current description. You seem to have followed all of the general steps for it though, so I suppose we’ll find out soon enough as to what the problem is :wink:

Chips N Cheese - Custom PHP installs and the like!

It isn’t that big of a deal, enjoy life, etc. In reality, shouldn’t we do real-world stuff first? My site isn’t going anywhere…I just want to get it working before 2600 puts out the next issue, as I have an article with my URL coming out, and they have 70,000 subscribers, NOT COUNTING NEWSTAND PURCHASES! So, I may be slammed really soon.

PHP works like a charm…its just getting the extensions noticed in the ini file. Maybe I need to wait until DH restarts Apache?

You’re definitely not doing something right. Any and all PHP extensions I’ve tried thus far, whether it be something as “advanced” as eAccelerator or as easy as ionCube have worked as the install instructions have said.

I suppose something you might consider: Are you calling the full path to the extension? For example, my eAccelerator and Suhosin extensions are in the following directory, /php5/lib/php/extensions/ (that is root from my home directory) and I call the extension from within php.ini just by the full library name (ie. “suhosin.so” - quotes included). Notice that I’m not included the full path to the extension at all, just the name itself.
Outside of that I really can’t imagine what else may be the cause of your problems. Apache however certainly doesn’t need to be reset as it automatically re-loads your config changes.

I’d also like to address another point real quick while I’m at it. Autoconf is removed after php5 is installed successfully and therefore you need to re-compile it during the installation process of APC. In fact, installing APC is very similar to installing the Suhosin extension that I’ve documented in the wiki.
That said, I’ll take the time this evening after class to document the install process of APC and I’ll be sure to leave a link to it in this thread once it’s finished :wink:

Hopefully that covers some of your concerns/questions for now, until the wiki article is done.

Chips N Cheese - Custom PHP installs and the like!

First off, 1000 thank yous…

Secondly, I figured out the whole autoconf thing, and have tried both the full extension path, as well as just using the extension name (have it in a similar structure to yours… /phplib/php/extensions) So, it should work, but isn’t. I have to have overlooked something.

Also, I don’t mean to take from your time, or your class time, or your homework time…take your time! (have I said “time” enough?)

Oh, and I will link to your site from mine if you want, currently PR 2, but should be PR 4 next update, if G ever updates.

Okay, I’m pretty sure I’ve found the problem.
The actual install of APC is really simple/straightforward as I’d said; however, it appears it requires that pear be enabled in order to actually utilize the APC extension (considering it’s a Pecl module/extension, this makes sense I guess). This means re-compiling PHP5 and altering the pear ‘Feature Flag’. I’ll alter the PHP5 dev script to include some information on why pear support is disabled by default, along with info on how to enable it should you need it.

As for APC - give me a bit longer on documenting the process, as I have to do a few more tests to make sure my instructions are accurate and such. My server (dads) is at around 10-ish load right now, so it’s going to take some time to re-compile for the tests, heh. Ah well… I’ll post back when it’s finished :slight_smile:

Chips N Cheese - Custom PHP installs and the like!

I know how to enable Pear…I will try that here in a few…good grief, I was really sweating all this…sorry to put you through the install process, although I know you probably need to know details like this for your upcoming launch.

Apparently, I am not smart enough, as I recompiled with pear and it isn’t working…I think I forgot to get some other source files or something, as the end of the PHP compile, PEAR complained a bit…

Oh, as for server load, it isn’t a problem for mine, as it usually is fast (pacer)…

Alrighty… we have success!
First, I found that using PHP in FCGI mode totally killed APC, irregardless of using PEAR or not. Using PHP in standard CGI mode however has made it fully functional. I recall APC WAS working with FastCGI in the past, as per this thread, but it doesn’t seem to want to work currently with it. I’ll continue to poke around with it and see if I can come up with anything… in the meantime I’ll work on putting up the guide on how to install it. That I know at least works :stuck_out_tongue:

EDIT: Oops, it seems I spoke too soon!
It actually does work with FCGI now… just took some time to reload? I dunno. I switched to normal CGI, opened a phpinfo() page a couple times, switched back to FCGI and all is well. Weird! Should have the install instructions up soon - nothing fancy required! :slight_smile:
This is with PHP 5.2.2 btw… perhaps it’s an issue with 5.2.3? I’ll be upgrading soon to find out!

EDIT #2 It works with PHP 5.2.3 as well, I noticed I’d set the memory allotment to the original “recommended” level of 128 when I did the 5.2.3 testing (which would obviously exceed our user’s memory space).
Proof of operation can be seen here. :slight_smile:

Chips N Cheese - Custom PHP installs and the like!

The completed wiki article can now be found here.
Please let me know if you experience any problems and I’ll try to figure out what might be the cause. Temporarily switching over to standard CGI, killing all the FCGI processes (or letting them die-out on their own), and then switching back to FCGI after loading a page once with standard CGI seemed to work perfectly in getting PHP to recognize APC.

Be sure you set APC’s memory cache to something low (the default value in the wiki article is 16, which I find to be low enough) as well or APC may not work at all.

Chips N Cheese - Custom PHP installs and the like!

w00t! it works! I love you! LOL! (in a hetero way)

LOL… scary :stuck_out_tongue:

Very glad it works though!! Hopefully many others can benefit from this as well :wink:

Chips N Cheese - Custom PHP installs and the like!

One issue…I have 2 fcgi processes running, and after 1-12min, the process killer kills one of them, and it seems that an instance of APC is running for each too. I have APC set to use 16mb of memory, and PHP set to use 32mb, but because there are multiple processes, it isn’t working right, as the cache gets killed every time more than one page is loaded.

Yup, this has always been a problem with DreamHost due to the userspace memory restrictions and is pretty much unavoidable I’m afraid. You could always set APC to cache its contents on disk however. Or you might consider renaming your fcgi wrapper-script to dispatch.fcgi (if you haven’t done so already). Personally I found when I named mine to dispatch.fcgi, it was continuously killed anyways, so I named mine to php5-wrapper.fcgi and it works almost perfectly… at least it gets killed much less :wink:

Chips N Cheese - Custom PHP installs and the like!

I have it tweaked now to the point of it working…I think. I use Joomla, and a Page cache extension i use supports APC, but it is faster when I use its database caching method, with APC enabled, with APC just caching scripts as it chooses, rather than having the component manage it. After all of the scripts have been cached, it seems that the pages really fly, and there is one persistant php process all the time (is this ok?) also, how do you tell APC to use the disk for caching, or at least for overflow? If we did that, our cached pages would still exist even when DH kill the processes…The only time I see another php.fcgi launched is when APC has to cache something it doesn’t already have cached…So, should I just set TTL to 0 so that nothing ever expires?