Что влияние увеличения является приоритетом процесса httpd (отрицательный хороший)?
Вы могли просто породить набор процессов radclient в фоновом режиме, для моделирования одновременных соединений. Это не было бы ужасно точно... с другой стороны, так как radclient является единственным, распараллелил, затем это должно быть одно к одному отображению (порождающий 300 одновременных фоновых процессов, было бы эквивалентно 300 одновременным пользователям). Конечно, начиная с Вашей автоматизации соединений, Вашей попытки поразить сервер Радиуса тяжелее затем 300 фактических пользователей, если они все не проходят проверку подлинности в то же самое время, но это могло бы встретить Ваши цели.
Если бы Ваш в сценарии, Вы могли бы записать быстрый сценарий Perl, чтобы также выполнить аутентификацию, но необходимо было бы, вероятно, породить дочерние процессы или поточную обработку использования, оба из которых более сложны затем вышеупомянутое, но может дать Вам больше контроля.
Я высоко предложил бы не делать этого. Если Ваш сервер будет так в большой степени загружен, что апач не получает процессорное время, в котором требуется, то renicing процесс будет иметь очень минимальный эффект, если таковые имеются. Кроме того, у апача будет много различных процессов, работающих в любой момент. Вы могли renice родительский процесс, и его дети наследуют правильность родителя, но затем все процессы httpd будут бороться друг с другом в течение времени.
В старых ядрах (говорят в конце 90-х / ранних 00-х), я нашел там, чтобы быть некоторым значением в процессах renicing (хотя я обычно только уменьшал приоритет, не увеличенный). С планировщиком в современных ядрах я никогда не находил, что это необходимые или даже стоящие взгляды о.
В заключение для решения проблем производительности существует множество других областей, я обратил бы внимание на то, прежде чем я начну обвинять приоритет процесса.
Предупреждение: IANAKD (я не Разработчик Ядра :)
Принятие нас говорит о Linux, можно читать о том, как хороший реализован в:
http://www.kernel.org/doc/Documentation/scheduler/sched-nice-design.txt
Чтобы попытаться ответить на Ваш вопрос, это не будет влиять на пропускную способность, потому что процессы являются deprioritized при блокировании на вводе-выводе, и веб-сервер, служащий статическому содержанию, скорее всего, будет связанным вводом-выводом.
См. также команду "ionice" - хотя это не полезно, если различные процессы не борются за ввод-вывод.
В конечном счете я не думаю, что сокращение контекстных переключений будет иметь значение. Скорее всего, веб-сервер, служащий статическому содержанию, проводит все свое время, делая ввод-вывод (сеть или диск), и ЦП относительно неактивен. Процессоры настолько более мощны, чем подсистемы ввода-вывода в эти дни, что они редко - узкое место во многих серверных сценариях. (Очевидно чистое перемалывание чисел или 3D рендеринг и такой являются исключениями к этому.), Если бы Вы полагаете, что реализация этого на реальном сервере улучшает производительность, я предложил бы сначала контролировать системные инструменты использования как вершина, iostat, vmstat, dstat, и т.д. видеть, где это проводит большую часть своего времени. После того как у Вас есть данные по узкому месту, Вы будете в хорошем положении для поиска решений его.