Это частный случай того, что описали выше, причём с использованием инструмента, который тут не нужен...
По поводу того, как разруливать скриптом обращение - смотреть заголовки. Например в php можно можно смотреть на $_SERVER['HTTP_HOST'], подробнее в мануале (http://php.net/manual/en/reserved.variables.server.php).
Создаётся файлик с конфигурацией vhost в папке, которая инклюдится в конфиге apache(или дописывается секция в конфиг, но это менее удобно), запускается apachectl graceful. Конфигурация перезагружается, клиенты не отваливаются. Profit.
Лучше отделить от интерфейса, и создавать задание на эту процедуру, и выполнять в кроне.
Да, в минимальном варианте нужно только это.
Числу потоков чего?
В простейшем случае числу ядер, чтобы можно было равномерно распараллелить между ними нагрузку.
Бывают и другие случаи, например если вам надо отдавать большие файлы.
Nginx не форкается в процессе работы в принципе, php-fpm умеет работать в двух режимах - либо у него уже запущено заданное количество процессов, либо аналогично apachе prefork.
По поводу отдачи статики, проведите ради интереса эксперимент, возьмите апач с отключённым балластом, и nginx. Загрузите запросами. Посмотрите на производительность и потребление ресурсов.
Ну вы указали мало информации, и никто не протелипатировал, что у вас есть nginx, хотя зацепка в вопросе и была.
На будущее, стоит в вопросе указывать больше информации о вашей системе.
Отключать, кстати, не обязательно, можно было просто таймауты в nginix ещё поправить...
9 07:37:02 Suse-server kernel: [1709421.643423] httpd2-prefork invoked oom-killer:
Памяти не хватает на все процессы, которые вы пытаетесь запустить.
Посмотрите, кто её потребляет. Вполне вероятно, что у вас стоит лимит на количество процессов apache куда больше, чем может себе позволить ваш сервер.
В данном случае, наличие APC или аналогичного кешера, уберёт как раз задержку, за счёт исключения следующих этапов:
-считывание с диска всех необходимых скриптов. Да, они могут быть в кеше fs, но вполне могут быть и вытеснены уже оттуда, и тогда, особенно при большой нагрузке на диск, разница будет очень ощутимой - это могут быть _секунды_, при наличии нескольких инклюдов, если скрипты вытеснены из кеша FS, и физически читаются с диска.
-его парсинга и компиляции. Даже если скрипты маленькие и простые, каждый запрос выполнять эту операцию немалый оверхед, который может быть вполне заметен.
И где тут инертность может добавиться? А затраты невелики - весьма небольшой кусочек памяти, куда поместятся скомпилированные скрипты, меньше при этом, чем если бы скрипты были в кеше FS.
Т.е. преимущество очевидно, вне зависимости от того, вордпресс-ли это или любой другой скрипт на php.
1. root вам не нужно устанавливать в локейшене, установите его общим для этого хоста.
2. yamdi работает с flv контейнером. Для mp4 можно пользоваться qt-faststart из комплекта ffmpeg или другими подобными программами, переносящими метаданные в начала файла.
3. В случае с флеш в байтах, в случае с mp4 в секундах.
Ну для одиночного проекта это не проблема.
Пожалуй мог бы. Во-первых nginx стал более чем творением одного человека в свободное время очень недавно. И поэтому нет пока бумажных книжек, хотя я думаю, очень скоро появятся, учитывая то, в каком направлении сейчас развивается проект.
Посмотрите также на динамику распределения сайтов по веб серверам, например http://news.netcraft.com/archives/2011/10/06/october-2011-web-server-survey.html
Nginx на третьем месте, и показывает наибольшую динамику роста. Ещё чуть-чуть и на второе выйдет, если уже не вышел. Особенно стоит обратить внимание на последний график.
По поводу же хостеров, самый большой сдерживающий фактор, огромная инерция массового софта, который держится на mod_rewrite, вместо того, чтобы реализовать нормальную маршрутизацию/редиректы на уровне приложения. И это проблема не только nginx, а практически всех веб серверов отличных от apache.
Но опять же, как прокси, он сейчас очень активно используется хостерами.
Я пока не видел ни одной панели, на которой можно было бы из коробки использовать Nginx, более чем как прокси, без проблем и не оглядываясь на приложения, которые будут хостится.
Но это на мой взгляд тоже вопрос времени скорее. Поддержка из коробки nginx практически только-только начинает появляться.
Я, вот, в свободное время потихоньку пишу себе панельку, как раз под связку, которую я упоминал раньше. =)
В общем-то я с вами согласен в том, что это не некая "серебрянная пуля", и любой софт надо использовать с умом в нужном месте и уметь правильно настраивать под ситуацию.
А вот по поводу сравнения с лайти, вы тут хватили имхо. Сколько раз я его не использовал, из-за той или иной весьма нужной возможности, которой на ммоент использования небыло у других серверов, столько раз плевался и сносил, всегда находились проблемы. Nginx же с ранних версий весьма стабилен.
Почему вы считаете, что 5 это нормально? =)
А почему например не диски? И если проц, то потому что стоит какой-нть говнокодерский плагин или потому, что нет кешера опкода, и постоянно приходится парсить php? =)
Гадание в чистом виде...
ТС, вам нужен сисадмин, или долгое гугление на предмет методик и инструментов анализа нагрузки, или долгое и подробное обсуждение на форуме с большим количеством данных от вас, и массой флейма не по делу...
Начните хотя бы с вывода top в момент высокой нагрузки что-ли.
Перекладывание данных из базы в сеть занимается практически любое веб приложение, и с какого перепугу они стали вредны в случае вордпресса? Хранить промежуточные значения может там и не стоит если есть кеширование страниц целиком, например, а вот кешировать опкод ну ни разу не вредно.
