PHP performance issues under RedHat

I don't know that anyone here will have any experience with this, but....

A coworker of mine is attempting to set up SquirrelMail under RedHat. When he uses the PHP RPM, everything's good, except there's a bug in the version of PHP they've packaged up, so he goes to compile it himself. When he does that, PHP's performance goes down the pooper. So he tried recompiling the source RPM for the one RedHat ships. And it's performance is bad.

So that would tend to point to a compiler performance issue, since the source RPM should compile with the same options as they used for the binary RPM.

Has anyone else encountered this and found a solution?

And it's performance is bad.

And its performance is bad.

Oh my God, Bitt's been Bitted. This kind of fundamental paradox can only lead to a chain reaction resulting in the collapse of the space-time continuum as we know it.

Ouch.

Any optimized CFLAGS being used?

Also, what configure flags are being used?

What do you mean by performance issues, exactly?

I've compiled PHP4 on Red Hat countless times and have never had performance issues.

Did he build in the Zend Optimizer?

Correct me if I'm wrong, but wouldn't all the CFLAGS and configure options and whatnot be contained within a RedHat source RPM? And isn't it supposed to match how the binary RPM was made?

If I'm right, then all those questions about CFLAGS and configure options are moot, as it's supposed to be being built with the exact same options and it's slower anyway.

By performance issues, I mean that with the binary RPM PHP, the SquirrelMail installation responds over its web interface immediately. With the locally-built one, it takes a still small but noticeable amount of time. Given that it'll probably be used by thousands of people, a small wait with no load does not bode well.

I've honestly not had the ability to play with it myself, and I don't know if he's rebuilding Apache along with it or what. For all I know, he's building it in a totally unoptimized manner. But I was hoping someone might say ``Oh, yeah! I've had that problem; use gcc 3.<no one else uses it>''.

Right. If the spec is being used then all the patches will be applied and the configure options specified in the spec will be used (duh ). I don't believe there are many default CFLAGS options set (I think just -O2), so he might want to optimize those anyway.

I am not sure if there are any additional CFLAGS set when the original RPM is built, but I imagine they really can't add much or it would break compatibility.

Either way, I'd recommend tweaking the spec before compiling, or not using it at all and doing it all from clean source. I've always just done the latter and haven't had any problems.

Then again, what do I know?

Oh my God, Bitt's been Bitted. This kind of fundamental paradox can only lead to a chain reaction resulting in the collapse of the space-time continuum as we know it.

Man, we can only hope. Maybe we'll find ourselves in a parallel universe - one where the 9/11 attacks never happened, the DMCA and Patriot Act never got passed, Herr Ashcroft never got confirmed and the economy wasn't in the toilet bowl.

[do] it all from clean source

As I attempted to say, he already tried that and it didn't help.

I understood that he tried it, but did he try it with all the optimizations and such? Maybe a newer version?

I don't know; now I'm just getting annoying and not helping at all. I'll just shut-up now.