ИМХО: с производительностью с любых точек зрения админа/программиста/владельца все достаточно просто ибо 100% будет работать любой нижеприведенный подход:
1. Апгрейдим железо пока не станет жалко денег — процесс может продолжаться вечно, ибо новое железо может стоить ГОРАЗДО меньше прибыли которую приносит проект.
2. Меняем софт. С этим тоже все понятно. сменили apache+mod-php на php-fpm + nginx или стали nginx-ом статику раздавать вроде стало полегче и т. д.
3. Тюнинг выбранного софта.
4. Тюнинг используемого приложения.
Повторюсь, работать до определенного момента будет любой подход, просто в определенные моменты времени нанять админа чтобы он сменил железо дешевле чем нанимать программиста чтобы тот переписал некоторые ключевые части софта.
К сожалению игры с nice и повышением приоритетов процессов приводят только к ухудшению управляемостью системы.
ИМХО: имело бы смысл если бы допустим у большинства сетевых сервисов была возможность менять приоритет при обслуживании определенных групп пользователей в зависимости от текущей нагрузки на систему.
В соответствии с этим делаются выводы как повысить производительность и сделать приложение более масштабируемым.
1. Апгрейдим железо пока не станет жалко денег — процесс может продолжаться вечно, ибо новое железо может стоить ГОРАЗДО меньше прибыли которую приносит проект.
2. Меняем софт. С этим тоже все понятно. сменили apache+mod-php на php-fpm + nginx или стали nginx-ом статику раздавать вроде стало полегче и т. д.
3. Тюнинг выбранного софта.
4. Тюнинг используемого приложения.
Повторюсь, работать до определенного момента будет любой подход, просто в определенные моменты времени нанять админа чтобы он сменил железо дешевле чем нанимать программиста чтобы тот переписал некоторые ключевые части софта.
tcpkill -i eth0 host 10.0.0.1
tcpkill: listening on eth0 [host 10.0.0.1]
и соединение отвалилось.
conntrack -D conntrack --orig-src 127.0.0.1
на выходе получаем
tcp 6 40 TIME_WAIT src=127.0.0.1 dst=127.0.0.1 sport=55307 dport=9000 packets=18 bytes=1864 src=127.0.0.1 dst=127.0.0.1 sport=9000 dport=55307 packets=18 bytes=136736 [ASSURED] mark=0 use=1
tcp 6 5 TIME_WAIT src=127.0.0.1 dst=127.0.0.1 sport=55306 dport=9000 packets=7 bytes=1372 src=127.0.0.1 dst=127.0.0.1 sport=9000 dport=55306 packets=7 bytes=13372 [ASSURED] mark=0 use=1
tcp 6 46 TIME_WAIT src=127.0.0.1 dst=127.0.0.1 sport=55308 dport=9000 packets=6 bytes=1560 src=127.0.0.1 dst=127.0.0.1 sport=9000 dport=55308 packets=6 bytes=400 [ASSURED] mark=0 use=1
conntrack v0.9.15 (conntrack-tools): 3 flow entries have been deleted.
Вообще советую набрать команду conntrack без параметров.
Может делать с Вашей conntrack таблицей такое, о чем Вы и помыслить не могли :)
ИМХО: имело бы смысл если бы допустим у большинства сетевых сервисов была возможность менять приоритет при обслуживании определенных групп пользователей в зависимости от текущей нагрузки на систему.