PHWinfo banniere

Titres
PORTAIL ANNUAIRE ARTICLES COMPARATEUR HÉBERGEURS DEVIS FORUMS RÉDUCTEUR D'URL
Précédent   PHWinfo > Autres forums > Forum Programmation & Conception > comp.lang.php > mod_php and Fast CGI
S'inscrire FAQ Membres Recherche Messages du jour Marquer les forums comme lus
mod_php and Fast CGI

Réponse
 
LinkBack Outils de la discussion
Vieux 14/06/2008, 07h31   #1
setesting001@gmail.com
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut mod_php and Fast CGI

How many of you are running Fast CGI instead of the popular mod_php?

I planning to change to fast cgi since my applications need around
15MB memory to handle a single request, so consider if Apache running
in multi-process mode, serving 300 clients, then it nearly used up all
my memory in my server.

Any experience can share how to handle large concurrent clients for
PHP?


Thanks
  Réponse avec citation
Vieux 14/06/2008, 11h15   #2
C. (http://symcbean.blogspot.com/)
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: mod_php and Fast CGI

On Jun 14, 7:31 am, setesting...@gmail.com wrote:
> How many of you are running Fast CGI instead of the popular mod_php?
>
> I planning to change to fast cgi since my applications need around
> 15MB memory to handle a single request, so consider if Apache running
> in multi-process mode, serving 300 clients, then it nearly used up all
> my memory in my server.
>
> Any experience can share how to handle large concurrent clients for
> PHP?
>


300 is not a lot of clients. Unless you mean that you normally have
300 active connections to the webserver.

Why do you think it will need less memory with fast CGI?

Even if I could see that such a change was valid, it would be well
down my list of things to change. While changing a lot of legacy code
can be tricky, I'd start by looking to optimize memory usage within
PHP, consider using autoloader, check queries (which are typically
buffered oustide of PHP's memory limit) and look at front and back end
caching. Making the code go faster and get off the server more quickly
will relieve memory pressures too - so the usual process of
performance optimization. You do have compression enabled in your
webserver and a PHP aaccelerator running?

But sometimes the only solution is to just throw more hardware at it.
But do make sure you've exhausted the other approaches first.

C.
  Réponse avec citation
Vieux 14/06/2008, 12h57   #3
Jerry Stuckle
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: mod_php and Fast CGI

setesting001@gmail.com wrote:
> How many of you are running Fast CGI instead of the popular mod_php?
>
> I planning to change to fast cgi since my applications need around
> 15MB memory to handle a single request, so consider if Apache running
> in multi-process mode, serving 300 clients, then it nearly used up all
> my memory in my server.
>
> Any experience can share how to handle large concurrent clients for
> PHP?
>
>
> Thanks
>


First of all, Fast CGI will not use any less memory the mod_php. In
fact, it may use slightly more.

Are you saying you will be handling 300 requests concurrently? That
would be a very busy web server - with typical processing, you're
talking several million hits a day. If that's the case, memory isn't
going to be your only problem. In fact, it probably won't be your main
problem.

Also, if you are regularly using that much memory, chances are you're
code is quite inefficient. It's not unusual to require that much
occasionally. But not on a regular basis.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

  Réponse avec citation
Vieux 14/06/2008, 14h40   #4
setesting001@gmail.com
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: mod_php and Fast CGI

On 6$B7n(B14$BF|(B, $B2<8a(B6$B;~(B15$BJ,(B, "C. (http://symcbean.blogspot.com/)"
<colin.mckin...@gmail.com> wrote:
> On Jun 14, 7:31 am, setesting...@gmail.com wrote:
> 300 is not a lot of clients. Unless you mean that you normally have
> 300 active connections to the webserver.
>



ps ax | grep httpd | wc -l

>> 286


and an example of running httpd process:

>> 31594 web 15 0 142m 16m 8472 S 0 0.3 12:02.94 httpd


I believe it is currently using 16M of memory per httpd process (I am
running Apache 1.3, multi process mode)


I am thinking about using fastcgi as not all these 286 httpd process
need to use php at every instance? (E.g. create a pool of fast cgi
php , say 100 process, and let them share)

Then it may save me some memory becoz I don't have 300 CPU to server
all these php at anytime?


Thanks.














> Why do you think it will need less memory with fast CGI?
>
> Even if I could see that such a change was valid, it would be well
> down my list of things to change. While changing a lot of legacy code
> can be tricky, I'd start by looking to optimize memory usage within
> PHP, consider using autoloader, check queries (which are typically
> buffered oustide of PHP's memory limit) and look at front and back end
> caching. Making the code go faster and get off the server more quickly
> will relieve memory pressures too - so the usual process of
> performance optimization. You do have compression enabled in your
> webserver and a PHP aaccelerator running?
>
> But sometimes the only solution is to just throw more hardware at it.
> But do make sure you've exhausted the other approaches first.
>
> C.


  Réponse avec citation
Vieux 15/06/2008, 19h07   #5
C. (http://symcbean.blogspot.com/)
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: mod_php and Fast CGI

On Jun 14, 2:40 pm, setesting...@gmail.com wrote:
> On 6$B7n(B14$BF|(B, $B2<8a(B6$B;~(B15$BJ,(B, "C. (http://symcbean.blogspot.com/)"
>
> <colin.mckin...@gmail.com> wrote:
> > On Jun 14, 7:31 am, setesting...@gmail.com wrote:
> > 300 is not a lot of clients. Unless you mean that you normally have
> > 300 active connections to the webserver.

>
> ps ax | grep httpd | wc -l
>
> >> 286


You have about 300 httpd servers running at any one - time - this is
FAR from the same thing as 300 users OR 300 concurrent requests. Since
you think that's an answer to the question, I'm guessing you haven't
even done any basic tuning of your apache.

>
> and an example of running httpd process:
>
> >> 31594 web 15 0 142m 16m 8472 S 0 0.3 12:02.94 httpd

>


Without seeing the headers or knowing which ps was run with what
options, it's hard to tell what I'm looking at here, I would expect
the %CPU and %mem to be listed in most formats, so I suspect that this
is using 0.3% of the available memory - which suggests that your
system could cope (memory wise) with a lot more then 300 concurrent
connections. What OS are you running on? Do you see any signs of
swapping or even paging?

> I believe it is currently using 16M of memory per httpd process (I am
> running Apache 1.3, multi process mode)
>
> I am thinking about using fastcgi as not all these 286 httpd process
> need to use php at every instance? (E.g. create a pool of fast cgi
> php , say 100 process, and let them share)


mod_php will (and most likely IS) happily live in COW TXT segment -
i.e. there will be only one copy in memory, referenced mulitple times.
The usage reported in ps is how much memory would be used if one AND
ONLY ONE instance of apache was running.

Forget about using FastCGI - you're just going to end up using more
memory and running slower.

Start by tuning your apache config (there are lots of good books
available) and add a compressed output handler (like mod_gzip) then
install a PHP cache, then think about optimizing any database and file
I/O by PHP.

C.
  Réponse avec citation
Réponse


Outils de la discussion

Règles de messages
Vous ne pouvez pas créer de nouvelles discussions
Vous ne pouvez pas envoyer des réponses
Vous ne pouvez pas envoyer des pièces jointes
Vous ne pouvez pas modifier vos messages

Les balises BB sont activées : oui
Les smileys sont activés : oui
La balise [IMG] est activée : oui
Le code HTML peut être employé : non
Trackbacks are oui
Pingbacks are oui
Refbacks are oui


Fuseau horaire GMT +1. Il est actuellement 06h29.


Édité par : vBulletin® version 3.7.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0 RC5 Tous droits réservés.
Version française #16 par l'association vBulletin francophone
PHWinfo est un site Éducation Sans Frontières ©2000-2008
Ad Management by RedTyger
©Tous droits réservés par les parties respectives
Page generated in 0,17227 seconds with 13 queries