Маловероятно, но попробуйте опцию --skip-name-resolve
Может оно ДНС ждет... Фиг его знает, чего ему еще ждать...
По show processlist во время обращения к странице ничего не видно?
Если процессор не нагружен, то вполне возможно, что это не вина mysql.
Скрипт чего-то ждет. Возможно там идет какой-то обращение во внешний мир. Попробуйте запустить netstat во время работы скрипта - может что-то заметите.
Еще может быть полезным расставить в скрипте метки времени, чтобы найти медленную часть. Типа echo "<!-- ".date("r")."-->"
Если таки mysql, попробуйте во время выполнения скрипта дать несколько раз с mysql-консоли
show full processlist;
Вы своими глазами сможете увидеть долгоиграющие запросы, если таковые есть.
Если 1000 запустятся одновременно, то сервер скорее всего упадет ;)
На практике количество процессов апача обычно ограничено сотнями. Причем это делается в расчете, что большинство процессов будут выполнять нересурсоемкие медленные запросы, например к статическим картинкам.
Но даже 10 одновременно выполняющихся скриптов означают нагрузку больше 100% даже для восьмиядерного сервера.
В реальности сервер не должен обрабатывать больше чем несколько скриптов одновременно. Он должен успевать выполнить один скрипт до того, как придет следующий запрос. Иначе количество активных процессов апача будет накапливаться как снежный ком, вызывая нестабильность системы.
fastcgi лишен этого недостатка. Обычно под ним запускается ограниченное число процессов. Пришедшие избыточные запросы будут ждать в очереди или же будут отфутболены.
Подсчет времени выполнения скрипта может иметь смысл для определенного промежутка времени. Например, один запрос выполняется за 0.021с, значит 1000 восполняются в сумме 21с, следовательно сервер может обработать ~50 запросов в секунду. А если у сервера 4 ядра, то ~200 запросов в секунду.
Но есть большое НО. Это все умозрительные вещи. На практике такие расчеты редко соответствуют истине. Например, если скрипт работает с файлами или с базой, то ни на какую линейность зависимости рассчитывать нельзя. Вполне может быть, что один скрипт выполнится за 0.02с, десять последовательных за 0.5с, а 10 одновременных - за 1с. А может и все наоборот...
Самое разумно, что можно делать - это тестировать производительность в условиях, приближенных к реальности. Хотя бы с помощью апачевской утилиты ab
Будет наглядно видно, как ведет себя скрипт при большой нагрузки и при разном числе одновременных запросов.
Можно попоробовать использовать страницы-ловушки - такие на которые человек никак не зайдет, а грабер поведется. Например, делать ссылку в виде прозрачной точки 1х1 пиксель или в невидимом div'е.
На этой странице-ловушке анализировать запрос и если это не известный порядочный бот типа гугликовского, то банить ip.
Ну или таки внимательно анализировать логи - в них таки все зафиксированно...
Перед покупкой поищите в сети бенчмарки ваших дисков по ключевым словам типа multi-threaded read hdd benchmark.
Обычно многопоточная скорость чтения меньше линейной в 2-4 и более раз. Для scsi подание скорости обычно меньше чем для sata.
Таким образом, если надеяться только на диски, вполне вероятно, что нужно делать райд-0 из 2 sas или по крайней мере 10к sata дисков.
НО. Очень много зависит от характера организации сервера. Абсолютно не факт, что все 2000 человек будут смотреть разные фильмы. Наоборот, вполне вероятно, половина из них будет смотреть 2-3 фильма, например, ссылки на которых будут висеть на заглавной странице сайта. Так что в реальных условиях все может быть далеко не так, как в бенчмарке.
Кеш - ваше всё.
Винты не выдадут такой скорости на 2000 потоков - затренеруются головками стучать...
Так что чем больше будет отдаваться из кеша - тем легче будет винтам. Вполне реально собрать сервер с 32ГБ ОЗУ.
Также стоит основательно подумать над выбором ФС и параметрами форматирования винтов.
В общем, теоретизировать можно до посинения, но точки над i может расставить только практика. Задача вполне реализуемая.
Это ограничение файловой системы ext2/ext3
Выход - либо использовать другую файловую систему либо иначе организовать хранение данных.
Для начала ограничьте количество процессов у апача и mysql, дабы они не могли съесть всю память. Типа MaxClients 50 у апача и max_connections=50 в /etc/my.cnf
Может быть стоит заменить апача на менее прожорливый сервер или поставить перед ним nginx для раздачи статических файлов.
Для mysql также настройте размеры буферов. Вот тут есть очень полезная утилитка: http://mysqltuner.com/
Второе, что можно сделать - написать скрипт, которые следит за нагрузкой сервера и свободной памятью и в случае необходимости останавливает/рестартует апача.
Уж не знаю, кто у вас кого куда сует...
Еще можно каждому клиенту свой php скомпилить, с подходящими ему умолчаниями чтобы вообще без .ini обойтись. И еще много чего можно. Только я не спрашивал, как мне хостинг организовать, а задал вполне конкретный вопрос. На который только два человека (исключая вас) дали толковый ответ. Им спасибо.
И пофигу, что производительность на порядок упадет и php_value в .htaccess не будет восприниматься?
vapetrov добавил 28.01.2009 в 18:19
Спасибо, попробую на досуге
