Does this release fix one of Apache's biggest problems, that the default Apache config file assumes that you've got 10 gigabytes of RAM in your server? Stuff like setting maxclients to a default of 150 has got to be the single biggest cause of Apache servers blowing up at dedicated and virtual private server hosts.
I don't understand your comment, do you actually have a server with less than 10GB RAM? Or do you want defaults that will assume all available RAM should be dedicated to Apache. Do you consider 150 maxclients to be too high? That would only handle a fraction of our current traffic, we had to increase it by a lot and our servers handled it without a problem.
Yes, I do actually. Most Apache installations are going to be at dedicated and VPS server hosts, due to the sheer number of customers in that market, and they're typically going to have tens of thousands of servers with far far less than 10GB of RAM.
150 max clients is enormously too high for a LAMP stack, or serving static content (unless you're dealing mostly in very large files). Most cases where I see people running that sort of concurrency with enough RAM to back it up are caused by people misconfigurin
by Anonymous Coward writes:
on Tuesday February 21, 2012 @01:43PM (#39113337)
Ok, I get it now. You only work with a LAMP stack on a bunch of tiny servers hosting some light PHP applications. And your expectation is that Apache defaults should cater to that.
I've been too far away from the Apache project for too long, so I guess I don't really know their direction. But some of us use it for real enterprise applications. There are other sorts of application servers we could use, but Apache works very well.
My point is that those "bunch of tiny servers" vastly outnumber the "real enterprise applications".
Shouldn't your hosting provider be doing this for you, or shouldn't you be doing this on install? This thread has been going on and on over a handful of config options. So you need configuration management. The apache config is flexible enough and unlike sendmail completely readable and comprehensible.
You are a fucking retard. Yes, some of you can justify the large concurrency and memory requirements. Most of the world doesn't. The bulk of Apache deployments are not what you think they are. So why should the default configuration cater to them?
I have a, perhaps stupid, question: how in the fuck do you know what the "bulk of Apache deployments" are, exactly? Do you just "know it" because of your "common sense?"
Ok, I get it now. You only work with a LAMP stack on a bunch of tiny servers hosting some light PHP applications. And your expectation is that Apache defaults should cater to that.
That would be my expectation too.
The smaller numbers of high traffic sites with lots of hardware are going to be monitored and tuned by experienced sysadmins anyway - no matter what the defaults are. ie they won't be using the default settings.
The far more numerous low traffic sites on virtual servers running mostly off the shelf
If in any problem you find yourself doing an immense amount of work, the
answer can be obtained by simple inspection.
Defaults still insane? (Score:5, Informative)
Does this release fix one of Apache's biggest problems, that the default Apache config file assumes that you've got 10 gigabytes of RAM in your server? Stuff like setting maxclients to a default of 150 has got to be the single biggest cause of Apache servers blowing up at dedicated and virtual private server hosts.
Re: (Score:0)
I don't understand your comment, do you actually have a server with less than 10GB RAM? Or do you want defaults that will assume all available RAM should be dedicated to Apache. Do you consider 150 maxclients to be too high? That would only handle a fraction of our current traffic, we had to increase it by a lot and our servers handled it without a problem.
Re: (Score:3, Interesting)
Yes, I do actually. Most Apache installations are going to be at dedicated and VPS server hosts, due to the sheer number of customers in that market, and they're typically going to have tens of thousands of servers with far far less than 10GB of RAM.
150 max clients is enormously too high for a LAMP stack, or serving static content (unless you're dealing mostly in very large files). Most cases where I see people running that sort of concurrency with enough RAM to back it up are caused by people misconfigurin
Re:Defaults still insane? (Score:1)
Ok, I get it now. You only work with a LAMP stack on a bunch of tiny servers hosting some light PHP applications. And your expectation is that Apache defaults should cater to that.
I've been too far away from the Apache project for too long, so I guess I don't really know their direction. But some of us use it for real enterprise applications. There are other sorts of application servers we could use, but Apache works very well.
Re: (Score:1)
My point is that those "bunch of tiny servers" vastly outnumber the "real enterprise applications".
Re: (Score:3)
My point is that those "bunch of tiny servers" vastly outnumber the "real enterprise applications".
Shouldn't your hosting provider be doing this for you, or shouldn't you be doing this on install? This thread has been going on and on over a handful of config options. So you need configuration management. The apache config is flexible enough and unlike sendmail completely readable and comprehensible.
Re: (Score:0)
You are a fucking retard. Yes, some of you can justify the large concurrency and memory requirements. Most of the world doesn't. The bulk of Apache deployments are not what you think they are. So why should the default configuration cater to them?
Re: (Score:0)
I have a, perhaps stupid, question: how in the fuck do you know what the "bulk of Apache deployments" are, exactly? Do you just "know it" because of your "common sense?"
Re: (Score:2)
That would be my expectation too.
The smaller numbers of high traffic sites with lots of hardware are going to be monitored and tuned by experienced sysadmins anyway - no matter what the defaults are. ie they won't be using the default settings.
The far more numerous low traffic sites on virtual servers running mostly off the shelf