[CLOSED] Apache 2.0.54 or php 5.0.4 very slow. which one?

trossachs · Veteran Joined: 22 Jan 2004 Posts: 1204 Location: London

Which one is it? Having just installed Apache 2.0.54 in the last ten days, I notice that when I use Webmail (php web client), it is horrendously slow. However, when Apache serves pages over the Internet via html, I am told by numeous people that it is very quick and the pages load without a prob.

I also started looking more at php, but for the fact I have not changed the install but also, I have just been studying "top" when I execute any functions within Webmail and I have noticed that there are two apache2 processes that come to the top, consuming resources. This is strange as I do not know of any reason why two apache2 pocesses would be looking to operate simultaneously. Has anyone ever seen this with Apache?

I know that there are Apache resources/child processes whichn site waiting to process any calls, but I have never seen two always working together.

I am assuming that this could have something to do with why Webmail has become just unbearable.

adaptr · Posted: Wed Jul 20, 2005 7:17 pm Post subject:

Doesn't it work with php 4 ?
I'd downgrade php.

The fact that you see two apache processes may mean many things - apache 2 has the capability to stream connections, i.e. use one child for each simultaneous connection that is opened, up to the max number of children obviously, but when you have very few connections this can easily mean more than one child per client.
It can also mean that the php script is run under a second child, although I'm a lot less sure about that...

You do realise you are using the newest versions of both apache and php, no ?

Unless you run something that definitely needs php 5 I would trust in the good old 4.x branch.
_________________
>>> emerge (3 of 7) mcse/70-293 to /
Essential tools: gentoolkit eix profuse screen

trossachs · Veteran Joined: 22 Jan 2004 Posts: 1204 Location: London

Thanks for this adaptr. But I had already tried downgrading to php-4.3.4 which is the last of the 4.x.x series that I was using and it makes no difference. Like I said earlier, Apache serving pages out on the net is fine and also locally; very quick. It is just this Webclient that takes so long. I was even thinking of using the php-accelerator that I saw posted somewhere to try and speed things up. However, I would prefer to know what has suddenly slowed things down before I add further components and complexities.

trossachs · Veteran Joined: 22 Jan 2004 Posts: 1204 Location: London

I've changed the NICE value of both Apache2 and courier-imap just to see if this makes a difference. Will be monitoring very closely.

adaptr · Posted: Thu Jul 21, 2005 12:41 pm Post subject:

Are you going to reveal which webmail program this is ?
Just in case somebody wants to do independent verification, say ?
_________________
>>> emerge (3 of 7) mcse/70-293 to /
Essential tools: gentoolkit eix profuse screen

trossachs · Veteran Joined: 22 Jan 2004 Posts: 1204 Location: London

Hastymail.sourceforge.net

adaptr · Posted: Thu Jul 21, 2005 1:08 pm Post subject:

Heheh okay, I'll check it out.
_________________
>>> emerge (3 of 7) mcse/70-293 to /
Essential tools: gentoolkit eix profuse screen

trossachs · Veteran Joined: 22 Jan 2004 Posts: 1204 Location: London

takaiNomuren · n00b Joined: 27 Jul 2005 Posts: 3

Just to add, im having exactly the same difficulty.
Anyone have a solution.
In my case it seems to be when accessing data external to either Apache or PHP. i.e. non-external content data PHP files are fast, as are pure HTML files. But when PHP has to reference anything else, MySQL, SVN, or CURL (that i have tested) it becomes exceedingly slow.

Now i have to use PHP5 and Apache2 due to SVN and another project which i am working on atm.

Any ideas?
_________________
--takai
I cant get no sleep...

trossachs · Veteran Joined: 22 Jan 2004 Posts: 1204 Location: London

Come along adaptr! :lol:

I am still Googling about. Some say that I should return to php v4 but I think that this would be a retrograde step.

takaiNomuren what kind of box are you running; drives, DMA enabled?

adaptr · Posted: Wed Jul 27, 2005 11:04 am Post subject:

Like I said earlier: I don't run PHP5 and don't intend to, either - not in the foreseeable future, anyway.

Yes, downgrading from PHP5 to PHP4 is a retrograde step - that's what retrograde means.

Use PHP4, and all your troubles are belong past.

For an Englishman you sure write like a Frenchman ;-)

_________________
>>> emerge (3 of 7) mcse/70-293 to /
Essential tools: gentoolkit eix profuse screen

trossachs · Veteran Joined: 22 Jan 2004 Posts: 1204 Location: London

LOL, I'm not quite sure how to take that! :wink:

However, the good grace by which it was intended should be a good start. I take your advice adaptr, but can't just see that step back for the moment. PHPv5 is working ok now other than with Webmail which is still painfully slow.

I have increased the nice value of courier-imap to -5 to give this extra priority over everything else. There is a slight improvement, but not much. I tried to implement Dovecot, but when switched over, imap got screwed up my maildirs and because this is a working box, I cannot have various components switched off for long. Even at night here in London, I have people from the other end of the world browsing webpages!

takaiNomuren · n00b Joined: 27 Jul 2005 Posts: 3

Sure, downgrading to PHP4 is one fix for it.... but it doesnt work in most situations. Remember some people dont simply upgrade to the latest packages because they want the latest and greatest...

Im currently considering just building from scratch by hand. Much easier.
_________________
--takai
I cant get no sleep...

trossachs · Veteran Joined: 22 Jan 2004 Posts: 1204 Location: London

Guess we will have to just wait and see what happens and browse the forums. I have made great strides in the interim though by ditching Courier-imap and using Dovecot. Have also increased the memory foot print of PHP from the standard 8MB to 64M.

Look in your php.ini file for details.