настраивайте mysql: mysqltuner.pl (http://mysqltuner.com) launchpad.net/mysql-tuning-primer
в помощь.
настраивайте апач (или nginx + php-fpm)
и да, eaccelerator+memcache или xcache тоже даст выигрыш в скорости
Ловите фирменный рецепт для высоконагруженных проектов на LS (испробовано на личном опыте путём множества проб и ошибок.)
Во-первых, устраняем узкие места.
Начать надо не с LS и даже не с самого веб-сервера, а с общесистемных заморочек.
Иногда бывает так, что много процессорного времени уходит на дисковые операции, т.е. IOwait.
Здесь две задачи: выставить адекватный IO Sheduler (CFQ, или даже Noop), и перенести всё — слышите, всё, что можно, в RAM FS. Особые джедаи-оверклокеры переносят весь движок в оперативку (об этом расскажу позже.)
Вот уж теперь приходит очередь сервера. Толстый и неповоротливый апач, падающий от SlowLori-атаки в одиночку (банальный питоноскрипт), сносим к Дискорду.
Качаем исходники nginx'а.
./configure --help
Вдумчиво курим мануал, и определяемся, что нам надо. Потом курим опять, и вновь конфигурируем для сборки с нужными флагами (Модуль STUB не забудьте, ага), выставляем все пути соответственно FHS!
make
Витиевато выражаемся, доставляем нужные зависимости и пакеты (опять-таки, если вы джедаист-пингвиновод, этот пункт пропускаем.)
checkinstall
(аккуратно собираем в пакет). Ставим.
Всё, теперь у нас красивый, быстрый, аки Рэйнбоу Дэш, сверкающий новизной nginx. Конфигурирование его может ускорить ещё на 20%.
Затем — php. Естественно, работать будем только, и только через CGI-интерфейс. Джедаисты качают исходники, собирают@компиляют. Ленивые кунг-фу панды ставят из пакетов.
Затем приходит время настраивать ШINDOШS nginx и собственно связку php-fpm. Приблизительные цифры могу посоветовать только тогда, когда скажете параметры этого вашего сервера и среднюю нагрузку на сайт (посещаемость). Для статики ставьте expires: max и отфутболивайте вплоть до ~75% запросов статики не с 200, а с 304 ответом, ня!
Переносим временные каталоги nginx в предусмотрительно откушенный кусок оперативной памяти.
Настраиваем mysql… тот же mysqltuner.pl вам в помощь, а временные каталоги вы уже поняли, куда. Само взаимодействие тоже строго через сокет — линукс же!
Затем ставим ускоритель. eAccelerator, спросите вы? Да как бы не так. Во-первых, он древнее Селестии и Луны вместе взятых, и не развивается уже очень долго. И потом, из-за его вредной привычки не следить за целостностью shared memory, и при высокой нагрузке то и дело отправлять в 502 сайт, я и отказался от него — ну стопорит обработку php-cgi, и всё тут. Доработка напильником как spawn-fcgi, так и php-fpm помогала лишь временно — до первой же лавины запросов.
Иногда советуют ставить memcached… ИМХО, излишний велосипед. Да, у него есть няшная фича распределения по нескольким серверам, но оно вам надо? Запускать отдельный кеширующий сервер, особенно на слабых хостингах/серверах суть лишняя головная боль. Поэтому выбрасываем это звено также.
Два вышеназванные «ускорителя» успешно заменяет xCache — кеш как опкода, так и переменных (var cache). Гибкая настройка, наличие «админки», быстродействие и нетребовательность к ресурсам процессора — что ещё надо для полного счастья? Благо, LS с ним работать умеет (и по сокету тоже), посему ставим. Аппетиты настраиваем в xcache.ini, если захотели стабильности и решили включить RO-protection, то файл также ложим в RAM FS.
Ставим сфинкс, ротацию топиков-комментов вешаем на крон, сам сфинкс просто вешаем на сокет.
Если не можете позволить себе полностью переместить LS в RAM FS, сделайте это хотя бы для каталога шаблонов — и немного, и ощутимо сэкономите ресурсы.
Вот, в принципе, и всё… по просьбе могу расписать любой пункт более подробно.
А вообще, ваше мнение неверное в корне. Вот джва железобетонных пруфа:
1. Номер 1. Семь лет назад некто Baris Simsek на FreeBSD.org поинтересовался, что же лучше. И получил внятный и обоснованный ответ от Robert Watson — явно в пользу сокетов.
2. Исследование "Performance Analysis of Various Mechanisms for Inter-process Communication", проведённое Kartik Gopalan и Hui Kang из кафедры компьютерных наук Бингемтонского университета совместно с Kwame Wright из Cooper Union в 2007 году, также свидетельствует о значительном (едва ли не на порядок) преимуществе использования сокетов.
4 4. Conclusion
Unix domain sockets have proven to deliver the highest throughput when compared to the other mechanisms. While its dominance is still unclear for transfers of small amounts of data, it is otherwise the bestmechanism to use within a single machine.
Забыл добавить кое-что важное: если размещаете весь движок или хотя бы его часть в оперативке, обязательно позаботьтесь о регулярном резервном копировании на диск — дабы потом не было мучительно больно.
12 комментариев
Ну хоть больше данных, статистику там, top с сервера
mysqltuner.pl (http://mysqltuner.com)
launchpad.net/mysql-tuning-primer
в помощь.
настраивайте апач (или nginx + php-fpm)
и да, eaccelerator+memcache или xcache тоже даст выигрыш в скорости
фирменныйрецепт для высоконагруженных проектов на LS (испробовано на личном опыте путём множества проб и ошибок.)Во-первых, устраняем узкие места.
Начать надо не с LS и даже не с самого веб-сервера, а с общесистемных заморочек.
Иногда бывает так, что много процессорного времени уходит на дисковые операции, т.е. IOwait.
Здесь две задачи: выставить адекватный IO Sheduler (CFQ, или даже Noop), и перенести всё — слышите, всё, что можно, в RAM FS. Особые джедаи-оверклокеры переносят весь движок в оперативку (об этом расскажу позже.)
Вот уж теперь приходит очередь сервера. Толстый и неповоротливый апач, падающий от SlowLori-атаки в одиночку (банальный питоноскрипт), сносим к Дискорду.
Качаем исходники nginx'а.
Вдумчиво курим мануал, и определяемся, что нам надо. Потом курим опять, и вновь конфигурируем для сборки с нужными флагами (Модуль STUB не забудьте, ага), выставляем все пути соответственно FHS!
Витиевато выражаемся, доставляем нужные зависимости и пакеты (опять-таки, если вы джедаист-пингвиновод, этот пункт пропускаем.)
(аккуратно собираем в пакет). Ставим.
Всё, теперь у нас красивый, быстрый, аки Рэйнбоу Дэш, сверкающий новизной nginx. Конфигурирование его может ускорить ещё на 20%.
Затем — php. Естественно, работать будем только, и только через CGI-интерфейс. Джедаисты качают исходники, собирают@компиляют. Ленивые кунг-фу панды ставят из пакетов.
Затем приходит время настраивать
ШINDOШSnginx и собственно связку php-fpm. Приблизительные цифры могу посоветовать только тогда, когда скажете параметры этого вашего сервера и среднюю нагрузку на сайт (посещаемость). Для статики ставьте expires: max и отфутболивайте вплоть до ~75% запросов статики не с 200, а с 304 ответом, ня!Переносим временные каталоги nginx в предусмотрительно откушенный кусок оперативной памяти.
Настраиваем mysql… тот же mysqltuner.pl вам в помощь, а временные каталоги вы уже поняли, куда. Само взаимодействие тоже строго через сокет — линукс же!
Затем ставим ускоритель. eAccelerator, спросите вы? Да как бы не так. Во-первых, он древнее Селестии и Луны вместе взятых, и не развивается уже очень долго. И потом, из-за его вредной привычки не следить за целостностью shared memory, и при высокой нагрузке то и дело отправлять в 502 сайт, я и отказался от него — ну стопорит обработку php-cgi, и всё тут. Доработка напильником как spawn-fcgi, так и php-fpm помогала лишь временно — до первой же лавины запросов.
Иногда советуют ставить memcached… ИМХО, излишний велосипед. Да, у него есть няшная фича распределения по нескольким серверам, но оно вам надо? Запускать отдельный кеширующий сервер, особенно на слабых хостингах/серверах суть лишняя головная боль. Поэтому выбрасываем это звено также.
Два вышеназванные «ускорителя» успешно заменяет xCache — кеш как опкода, так и переменных (var cache). Гибкая настройка, наличие «админки», быстродействие и нетребовательность к ресурсам процессора — что ещё надо для полного счастья? Благо, LS с ним работать умеет (и по сокету тоже), посему ставим. Аппетиты настраиваем в xcache.ini, если захотели стабильности и решили включить RO-protection, то файл также ложим в RAM FS.
Ставим сфинкс, ротацию топиков-комментов вешаем на крон, сам сфинкс
просто вешаемна сокет.Если не можете позволить себе полностью переместить LS в RAM FS, сделайте это хотя бы для каталога шаблонов — и немного, и ощутимо сэкономите ресурсы.
Вот, в принципе, и всё… по просьбе могу расписать любой пункт более подробно.
Да пребудет с вами мудрость Селестии.
А если серьёзно, то почему?
1. Номер 1. Семь лет назад некто Baris Simsek на FreeBSD.org поинтересовался, что же лучше. И получил внятный и обоснованный ответ от Robert Watson — явно в пользу сокетов.
2. Исследование "Performance Analysis of Various Mechanisms for Inter-process Communication", проведённое Kartik Gopalan и Hui Kang из кафедры компьютерных наук Бингемтонского университета совместно с Kwame Wright из Cooper Union в 2007 году, также свидетельствует о значительном (едва ли не на порядок) преимуществе использования сокетов.