Как уменьшить нагрузку сайта на сервер? (собираем инфу по теме)

Вы будете смеяться, но проще именно закешировать данные, а потом поставить дополнительный (ые) сервер (а). Как правило, это будет значительно дешевле, чем оптимизировать код. Месяц работы программиста (разобраться в обширном коде, поправить и всё протестировать заново) стоит 3К баксов с налогами. Новый сервак в стойку - 1-2К баксов в год в зависимости от качества сервера (500 баксов на колокейшн в год учтены).

Он не будет смеяться, он программист.

Поэтому для него есть только один способ - сесть и начать переписывать код.

А такие скромные меры, позволяющие учетверить переносимую нагрузку, как оптимизация размеров буферов mySQL, включение Query Cache, установка разумных Expires для статических элементов страниц и так далее - это все слишком просто. Нормальные герои всегда идут в обход.

Слава Шевцов,

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

=offtop=

За чтож так программистов не уважаете?

И к словам цепляться не надо, их не для того говорят :)

=/offtop=

Абсолютно неуместный стёб.

Всё верно, это один из путей снижения нагрузки. Но как говориться, одно другому не мешает.

Наша тема о том какие варианты снижения нагрузки существуют/доступны, а какие из них выбрать это уже дело владельца сайта.

А Вы, я так понимаю, сейчас ищите оптимальный метод снижения нагрузки. Не об этом у нас речь.

Но за Ваш вариант, спасибо, он весьма актуальный.

Перед тем как заниматься оптимизацией сервера, сначала надо выявить узкие места и тяжелые процессы, а то может случится так, что вы будете оптимизировать MySQL, а в памяти будет висеть сотня почтовых процессов, обрабатывающих спам+прожорливый СпамАссассин или дело вообще в узком канале, через который сетевые процессы не могут пробраться, ожидая в очереди.

При оптимизации любого сервера (и не только) надо четко представлять, что и как оптимизировать. Примерная последовательность действий:

Другие действия напоминают врача, к которому пришел пациент с жалобой, что болит непонятно что непонятно где, и врач прописывает ему аспирин или панадол, приговаривая "всем помогает и вам тоже должно помочь", вместо того, чтобы осмотреть или отправить на обследование.

Gray верно говорит. Програмисты не в ту сторону смотрят. Сам был таким.

Вы сами сядьте и посчитайте какая часть нагрузки приходится на код, на процессы (по памяти) и на базу данных. В подавляющем числе случаев проблема будет не в скорости кода. Вы просто сядьте и посчитайте. Или возьмите реальные проекты: пару-тройку своих маленьких или Wikipedia с LiveJournal, для которых есть хорошие отчёты ( http://solutions.mysql.com/mysql-dell/mysql-livejournal-slides.pdf ), и посмотрите, где возникает основная нагрузка и как с ней справляются. Если бы скрипты были узким местом, то там бы часть PHP/Perl скриптов переписали на С/С++ вместо добавления очередного десятка мощных серверов. Не переписывают - добавляют сервера. Причём сервера под базы, сами базы делят на логические части, ставят мемкешед-сервера. Код как был на тормознутом PHP/Perl, так и крутится. Для большей тормознутости его переписали на объектно-ориентированный вариант 😆

А еще для некоторых программистов бывает откровением что с помощью двух процессов можно достичь большего, чем с помощью одного.

FixGuitar,

Нельзя сделать велосипед, а потом начать бороться за его качество.

1. Если стоит вопрос в уменьшении нагрузки, нужно сразу писать все под эту задачу(это для скриптов)

2. Конфигурировать сервак так, чтобы при выполнении требуемой задачи, он имел минимальную загруженность.

3. Выбрать соотвествующую платформу. (как серверного ПО так и поддерживаемых скриптов). И здесь Явзка xNIX + PHP не единственная и далеко не оптимальная.

4. Отказаться , в особо нагруженных задачах, от скриптов, переведя часть кода в исполняемые(бинарные) файлы.

5. Четко разделиять что нужн делать постоянно, а что один раз в час/сутки/месяц/год.

а это - больше напоминает набор мыслей из учебника информатики для начальной школы.

И как вы сие предлагаете использовать в конкретном контексте?

Ладно, открою большую тайну менеджеров. Если в процессе эксплуатации сайта вдруг выясняется, что написанный некоторое время назад код не позволяет серверу выдержать нагрузку и причина действительно именно в коде или архитектуре софта, которая не позволяет его масштабировать - разработчика сервиса надо расстрелять, а сервис выбросить.

В остальных случаях проще и дешевле масштабировать сервис и использовать прозрачные для кода серверные решения.

Например:

Для MySQL:

- увеличение буферов.

- построение индексов.

- отслеживание long-queries.

- включение кэша запросов.

Для Апача + PHP

- установка любого из акселераторов. Рекомендую XCache.

- поддержка keep-alive.

- разумные таймауты.

- gzip. Нагрузка на процессор растет не очень сильно, а вот время отдачи=время существования процесса сильно уменьшается.

- вынос всей статики из-под апача - пусть nginx ее отдает, он маленький и быстрый.

- вынос всех скриптов и стилей из кода, генерируемого апачем, в отдельные файлы - пусть это отдает nginx.

Очень рекомендую memcached - правда, скрипт должен уметь с ним работать.

Дальше можно говорить о масштабировании - например, вынести mysql-сервер на отдельную машину. Наладить репликацию баз и использовать реплицированную базу для некритичных операций. Ну, например, на этом форуме можно среплицировать базу и весь поиск проводить только на реплике.

По мере роста проекта увеличить число веб-серверов и поставить перед ними load balancer или хотя бы round-robin DNS настроить.

Короче, есть еще масса способов выдерживать нагрузку, не трогая код.

Сообщу также, товарищ программист, что ваша тема вами же размещена в разделе "Администрирование серверов" - поэтому, извините, но говорить здесь мы будем о настройках серверов, а не о переписывании проектов.

У меня есть ощущение, что бинарники будут работать не на порядок быстрее, чем прекомпиленный код php-скрипта с Апачем. Тем более, что на время ответа mysql, например, это мало повлияет.

Гораздо эффективнее может оказаться переход с mod_php на FCGI-решение.