|
|
|
#1 |
|
Messages: n/a
Hébergeur: |
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 |
|
|
|
#2 |
|
Messages: n/a
Hébergeur: |
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. |
|
|
|
#3 |
|
Messages: n/a
Hébergeur: |
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 ================== |
|
|
|
#4 |
|
Messages: n/a
Hébergeur: |
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. |
|
|
|
#5 |
|
Messages: n/a
Hébergeur: |
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. |
|
![]() |
| Outils de la discussion | |
|
|