Skip to main content
replaced http://serverfault.com/ with https://serverfault.com/
Source Link

I propose a change to the FAQ and closing policy:

I'd like to see all of the benchmarking questions closed with prejudice; I'm tired of seeing them. In my mind, the answer is almost always the same:

Put your scenario in place, add monitoring, add traffic, evaluate results. Modify based on results. Rinse. Repeat.

Add to the FAQ that questions ranging from the awful

"howhow manymany usersusers can acan a webweb serverserver taketake"

to the specific

"I have a 42U rack with maxed-out HP Proliant DL360 G8's; how many concurrent users will that support running [app environment] on [platform]"

are going to be closed, because each application and environment is a unique and (more often ugly than beautiful) snowflake. You need to test your particular snow-flakey circumstances.


This is not to say that questions about poor performance shouldn't be allowed. "I'm running XYZ on ABC with CMYK and I'm RGB is slower than I'd expect. What should I check and what could I do to mitigate?" seems like a reasonable question to me...

I propose a change to the FAQ and closing policy:

I'd like to see all of the benchmarking questions closed with prejudice; I'm tired of seeing them. In my mind, the answer is almost always the same:

Put your scenario in place, add monitoring, add traffic, evaluate results. Modify based on results. Rinse. Repeat.

Add to the FAQ that questions ranging from the awful

"how many users can a web server take"

to the specific

"I have a 42U rack with maxed-out HP Proliant DL360 G8's; how many concurrent users will that support running [app environment] on [platform]"

are going to be closed, because each application and environment is a unique and (more often ugly than beautiful) snowflake. You need to test your particular snow-flakey circumstances.


This is not to say that questions about poor performance shouldn't be allowed. "I'm running XYZ on ABC with CMYK and I'm RGB is slower than I'd expect. What should I check and what could I do to mitigate?" seems like a reasonable question to me...

I propose a change to the FAQ and closing policy:

I'd like to see all of the benchmarking questions closed with prejudice; I'm tired of seeing them. In my mind, the answer is almost always the same:

Put your scenario in place, add monitoring, add traffic, evaluate results. Modify based on results. Rinse. Repeat.

Add to the FAQ that questions ranging from the awful

"how many users can a web server take"

to the specific

"I have a 42U rack with maxed-out HP Proliant DL360 G8's; how many concurrent users will that support running [app environment] on [platform]"

are going to be closed, because each application and environment is a unique and (more often ugly than beautiful) snowflake. You need to test your particular snow-flakey circumstances.


This is not to say that questions about poor performance shouldn't be allowed. "I'm running XYZ on ABC with CMYK and I'm RGB is slower than I'd expect. What should I check and what could I do to mitigate?" seems like a reasonable question to me...

Ever-important "Rinse. Repeat" steps
Source Link
gWaldo
  • 12k
  • 17
  • 12

I propose a change to the FAQ and closing policy:

I'd like to see all of the benchmarking questions closed with prejudice; I'm tired of seeing them. In my mind, the answer is almost always the same: Put your scenario in place, add monitoring, add traffic, evaluate results.

Put your scenario in place, add monitoring, add traffic, evaluate results. Modify based on results. Rinse. Repeat.

Add to the FAQ that questions ranging from the awful

[how][1] [many][2] [users][3] [can a][4] [web][5] [server][6] [take][7]

"how many users can a web server take"

to the specific

"I have a 42U rack with maxed-out HP Proliant DL360 G8's; how many concurrent users will that support running [app environment] on [os]"

"I have a 42U rack with maxed-out HP Proliant DL360 G8's; how many concurrent users will that support running [app environment] on [platform]"

are going to be closed, because each application and environment is a unique and (more often ugly than beautiful) snowflake. You need to test your particular snow-flakey circumstances.


This is not to say that questions about poor performance shouldn't be allowed. "I'm running XYZ on ABC with CMYK and I'm RGB is slower than I'd expect. What should I check and what could I do to mitigate?" seems like a reasonable question to me...

I propose a change to the FAQ and closing policy:

I'd like to see all of the benchmarking questions closed with prejudice; I'm tired of seeing them. In my mind, the answer is almost always the same: Put your scenario in place, add monitoring, add traffic, evaluate results.

Add to the FAQ that questions ranging from the awful

[how][1] [many][2] [users][3] [can a][4] [web][5] [server][6] [take][7]

to the specific

"I have a 42U rack with maxed-out HP Proliant DL360 G8's; how many concurrent users will that support running [app environment] on [os]"

are going to be closed, because each application and environment is a unique and (more often ugly than beautiful) snowflake. You need to test your particular snow-flakey circumstances.


This is not to say that questions about poor performance shouldn't be allowed. "I'm running XYZ on ABC with CMYK and I'm RGB is slower than I'd expect. What should I check and what could I do to mitigate?" seems like a reasonable question to me...

I propose a change to the FAQ and closing policy:

I'd like to see all of the benchmarking questions closed with prejudice; I'm tired of seeing them. In my mind, the answer is almost always the same:

Put your scenario in place, add monitoring, add traffic, evaluate results. Modify based on results. Rinse. Repeat.

Add to the FAQ that questions ranging from the awful

"how many users can a web server take"

to the specific

"I have a 42U rack with maxed-out HP Proliant DL360 G8's; how many concurrent users will that support running [app environment] on [platform]"

are going to be closed, because each application and environment is a unique and (more often ugly than beautiful) snowflake. You need to test your particular snow-flakey circumstances.


This is not to say that questions about poor performance shouldn't be allowed. "I'm running XYZ on ABC with CMYK and I'm RGB is slower than I'd expect. What should I check and what could I do to mitigate?" seems like a reasonable question to me...

Source Link
gWaldo
  • 12k
  • 17
  • 12

Can we weed out the benchmarking questions?

I propose a change to the FAQ and closing policy:

I'd like to see all of the benchmarking questions closed with prejudice; I'm tired of seeing them. In my mind, the answer is almost always the same: Put your scenario in place, add monitoring, add traffic, evaluate results.

Add to the FAQ that questions ranging from the awful

[how][1] [many][2] [users][3] [can a][4] [web][5] [server][6] [take][7]

to the specific

"I have a 42U rack with maxed-out HP Proliant DL360 G8's; how many concurrent users will that support running [app environment] on [os]"

are going to be closed, because each application and environment is a unique and (more often ugly than beautiful) snowflake. You need to test your particular snow-flakey circumstances.


This is not to say that questions about poor performance shouldn't be allowed. "I'm running XYZ on ABC with CMYK and I'm RGB is slower than I'd expect. What should I check and what could I do to mitigate?" seems like a reasonable question to me...