Хотелось бы услышать в первую очередь ответ от тех, у кого был практический опыт.
Преамбула.
У нас есть небольшой форум на vbulletin (сайт на *-нюке, суммарная посещаемость не выше 1000 хостов). Хостинг обычный, виртуальный.
Посещаемость достаточно стабильная на протяжении года и последние дни была даже ниже среднего. Поэтому когда нам сегодня отключили сайт за нагрузку это было неожиданностью.
Одна из цитат по логам 20.00% 0.40s GET /forum/attachment.php?attachm. При том что хостер вроде бы карает за нагрузку начиная с 7.5%. Сайт нам включили, скрипт мы тут же отключили. Смотрели load average (uptime командой) в ближайший час после включения сайта - было в районе 20, от 10 до 30 где-то. Потом с хостером договорились что скрипт включим (по его инициативе кстати), сейчас все нормально, load average упал до примерно 12. В среднем (исходя из предыдущего опыта) la колбасит от 10 до 25 (в зависимости от времени суток в основном).
У нас мысли закопошились о возможной неизбежности переезда на выделенный сервер, но цену вопроса считаем неадекватной своим задачам, хотя долларов за 200 с чем-нибудь и было предложено организовать сервер.
Насколько мы поняли, возможно мы попали под замес как одни из наиболее грузящих во время большой загруженности сервера и на самом деле мы тут не при чем (посещаемость у нас была не выше других дней, нагрузка по LA была высокая и без нас, раньше мы грузили меньше 7.5% всяко - иначе бы раньше отключали тоже). В принципе это не особо важно, но интересно.
А теперь собственно вопросы.
1) Если у кого-то хостятся форумы на vbulletin и с включенными аттачментами, до какой посещаемости они живут на обычном хостинге? Какую нагрузку дают при посещаемостях разных?
2) Нам был дан совет проверять la на сервере и не запускать скрипт если оно больше 10, а просто "умирать". Совет хороший, но хотелось бы узнать, насколько замена "немедленной отдачи картинки" на "сон до нормального la" может помочь снижению нагрузки, всё-таки процесс будет висеть... зато картинка будет отдаваться... со временем.
3) Насколько серверу "понравится" около 20,000 правил в mod_rewrite по переписке урлов? Ибо определённо есть доля смысла выгрузить все в статику (хотя очень этого не хотелось бы - это крайняя мера), но старые линки терять не хотелось бы категорически. Почему-то нам не кажется что 20к правил хорошая идея, если плохая - то есть ли нескриптовые альтернативы?
4) Насколько вообще сильная нагрузка (по сравнению с 10-20 несложными запросами в базу) создается при "простой" отдаче файла (допустим размером 50кб) скриптом? Хотя бы порядок цифр.
5) Были еще вопросы, но мы их благополучно забыли пока формулировали предыдущие, поэтому если кто-нибудь что-нибудь может посоветовать или сказать (крайне желательно исходя из практики относящейся к делу) - будем благодарны.
P.S.: Хостера называть не будем, в предложении нового хостинга пока не заинтересованы

Именно это и произошло, попросите перенести Ваш сайт на менее загруженный сервер, чтобы наверняка выявить на сколько он грузит текущий сервант.

Спасибо за ответ, но просить переносить сайт скорее всего не будем, слишком напряжно, да и мы вроде на лучшем сервере сидим. Украдем однако из совета идею померять загрузку на меньших la

Неужели эти правила нельзя как то оптимизировать?


Апач у хостера второй или первый?

Преобразование вида
из att.php?id=29722 в /forimages/vasya_v_derevne.jpg
из att.php?id=29720 в /forimages/vasya_v_gorode.jpg
при том что
из att.php?id=29730 должно будет просто запустить скрипт аттача.
Это поддается оптимизации? Честно говоря просто в голову ничего не идет и не подумали.
Вариант давать имена файлам картинок на базе id рассматривался, но очень не хочется терять имена файлов, тогда уж проще сделать скриптом редирект.
1-ый.

Попросите хостера поставить php в fastcgi - будет быстрее.

Вряд ли это возможно, повлияет ведь на весь сервер. И... мы всегда считали что php как модуль апача быстрее, заблуждались? Или неправильно поняли что такое fastcgi ?

Объясняю. Когда работает первый апач, то он на каждый коннект плодит наследника (ну за исключением keepalive), который связан с mod_php и php исполняется в контексте апача. И все это отнимает память.

Когда php работает в режиме fastcgi, то это экономит память, и соответственно нагрузка падает.

Честно говоря не поняли, и хотя это уже не совсем по теме, но спросим. Разве в режиме fastcgi на каждый коннект не происходит запуск скрипта, который естественным образом загружает в память пхп интерпретатор солидных размеров? И только потом уже начинает кушать... то же количество памяти под исполнение самого скрипта?

FastCGI работает как сервер, запускающий на какое-то время отдельный PHP-процесс, все запросы с вебсервера обрабатываются этим процессом. Mod_php запускает интерпретатор PHP на каждый процесс.

Решили перегнать всё старое в статику.
Скрипт будет отдавать 301 редирект на старые файлы, и просто отдавать новые.
Новые со временем тоже будем гнать в статику.
Немного печальный выход, но что ж поделаешь.
К нашему изумлению оф. вбуллетин абсолютно не внял призывам сделать такую выгрузку (или опцию размещения и отдачи файлов прямыми линками) на автомате хотя бы в будущем.