On Fri, Apr 15, 2022 at 3:50 PM Yann Ylavic <ylavic....@gmail.com> wrote: > > On Fri, Apr 15, 2022 at 2:16 PM 刘孟 <lium...@telemap.com.cn> wrote: > > > > > > What I want to ask is, will these 1000 sub processes fail at the same time, > > causing my httpd serivce to stop responding.But I think you have given the > > answer > > >because the clients connections themselves will not have the same > > >lifetime (including keep-alive in between requests). In my opinion the > > >risk is negligible. > > > > I think setting MaxConnectionsPerChild will lead to a slight decrease in > > the processing capacity of my server, > > but the possibility that all processes failed at the same time can be > > ignored.. Is my understanding correct > > Yes, and I don't think there will be a noticeable capacity change if > you don't set MaxConnectionsPerChild too low (the right tuning depends > on the number of connections per second). > > > > > in this way, the restart action usually occurs in the busiest period of the > > server in daytime, > > so I think your advice of using cron is a good suggestion. Of course, in > > order to prevent all httped services from > > stopping at the same time, I think I should set cron for the servers at > > different times. Is that I am in the right way? > > Yes, and ideally your DNS switches do not happen at the load peak, so > there should be too much processes restarted when the cron executes.
"there should *not* be" > > > > > I also thank you for your suggestions on max/minspareservers. The > > adjustment of them will also be in my plan. > > > you probably should raise it to something more close to MaxRequestWorkers > > > for efficiency. > > > > Do you mean I should adjust it to a daily peak of about 1000? > > Yes, that way at the load peak you have the full capacity of > processes, and after the peak they should be killed by > MaxConnectionsPerChild at some point (without being restarted) hence > move towards MinSpareservers, until the next peak.. > So you should find the MaxConnectionsPerChild setting that does kill "that does *not* kill" > processes too often at load peak but still kills enough processes > after the peak (during the ramp down). > > > Regards; > Yann. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
