Сильнонагруженные сайты - как они реализованы?

ПРочитал дискуссию и не понял два момента.

1) Как строятся высоконагруженные приложения

2) У кого самая длинная пиписька

Проблема в терминологии. Некоторые сочли, что речь идёт об оптимизации форума, некоторые что речь о создании клона ЖЖ. Отсюда и дрязги.

Феерический бред. Практически сразу после развертывания php и на него вешается акселератор который единожды скомпилировав файл хранит его в памяти в виде байт-кода (компилятор php в исполняемый код я еще не видел, найдете - покажите).

Про MSSQL вместо MySQL я молчу вообще.

Еще раз добрый день, попытаюсь донести до масс, кому действительно интересны высокие нагрузки, немного разъяснений. Я не будут останавливаться на частностях, которые Вы уже должны знать, если Вы их не знаете или не можете узнать используя google, задумайтесь и лучше поручите эту работу кому-то другому (это я пытался донести в прошлом посте)

Во-первых, что такое highload (высоконагруженный) проект, это проект ну хотя бы от 1 млн. хитов в день, хотя это тоже субъективно - правильнее rps - request per second, то есть количество запросов в секунду, может быть проект с посещаемостью 100000 хитов быть более нагруженный из-за пиковых моментов, чем сайт с 1000000 хитов.

Тезис №1

Преждевременная оптимизация корень всех бед.

Если Вы никогда не делали аналогичный highload проект, Вы НИКОГДА не скажите где у Вас будет узкое место, а посему я ( и такое классики как Фаулер, например ) советую Вам не оптимизировать заранее. Это не значит, что можно писать криво, наоборот делайте все правильно, красиво, гибко. Использование ООП и Design Patterns (шаблонны проектирования), только поощряются, а не как многие заблуждаюсь, советуют наоборот. Сейчас мы рассмотрим почему.

Раньше, дела обстояли так, что не было OP cache программ (те кто берут php код и сохраняют его результат интерпретации в кэше), что приводило к тому что интерпретация большого кода (а ООП код всегда несет в себе излишество) существенно замедляла отдачу. Теперь же есть много таких программ, я лично считаю лучшей бесплатную Xcache (которую, кстати, начинают ставить даже на простых хостингах).

Дальше, вспоминая 1 тезис, мы не знаем где будет узкое место, а когда сделали проект и увидели под реальной загрузкой что в таком-то месте у нас тормозит ( для этого можно например погонять в Xdebug) то мы всегда может сделать хак который ускорит это место убрав оттуда ООП или другой код внедрив или дополнительный кэш этого места. Всегда можно от высокого спустится к низшему. А, ухудшая изначально свой код, Вы делаете непоправимое - скоро крупный проект выйдет у Вас из под контроля и Вам придется переписывать заново его или мучаться с поддержкой этого жиле.

Тезис №2

Умный в гору не пойдет, умный гору обойдет.

Любой highload это масштабирование, масштабирование бывает 2 видов:

- вертикальное, когда увеличивают мощность сервера.

- горизонтальная, когда нагрузку разносят на несколько серверов.

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

Масштабировать лучше начать (повторюсь, надо смотреть на проект, всё тут очень и очень уникально) с разнесения на 3 сервера:

1) Статические файлы. Поставить веб сервер Nginx, он замечательно справляется с отдачей статических файлов. Сюда относиться js, css, картинки любой контент и если вы используете html кэш, который потом собираете SSI директивой.

2) Логика. Я бы посоветовал тут поставить lighttpd.

3) Базы данных. Ставим MySQL и memcache на отдельный сервер, желательно чтоб на нем было побольше и побыстрее оперативной памяти.

Когда и если вам перестанет хватать этих серверов, Вы спокойно можете поставить еще один и с помощью аппаратного балансировщика нагрузки или программного (например nginx) и увеличить в двое ресурсы. Единственная сложность MySQL сервер, так как там надо поддерживать актуальную информацию, а она часто изменяется, то можете либо при вставке или изменении делать их сразу на всех таблицах или сделать master – slave и синхронизировать контент с мастер на слейв с какой-то периодичностью по cron. Делать кластер не советую на MySQL заметно падает производительность, тут уже стоит посмотреть на другие СУБД.

Тезис №3

Кэшируй все что можно.

Тут думаю все понятно, просто храним в КЭШе все что можно, чтоб не нагружать сервера, в основном это касается запросов в базу данных, как мы видим из предыдущего тезиса, это самое узкое место и сложных расчетов, например статистических. Для КЭШа советую использовать memcache.

Заключение.

Соблюдая эти 3 простых тезиса, Вы может и не сделаете google, но выдержите любую адекватную нагрузку в разумных пределах, а если ее Вам не будет хватать, то тут уже думаю, Вас будет меньше всего заботить, как это реализовать, ведь вы сможете себе позволить курировать этот проект с Гавайских островов!

Надеюсь это кому-то поможет, с уважением Александр.

Не претендуя на highload, кратко опишу с чем сталкивался по оптимизации нагрузки. Был один сайт, все на нем было здорово (php+MySQL) до поры до времени, пока он не начал грузить сервак кучей зависших процессов, которые плодились пачками и висели в топе по полчаса. Одновременно с этим стал наблюдаться нелостаток памяти, которой выделялось по полгига и более!

Так вот, оказалось следующее. Во-первых при выяснении причин происходящего обнаружилось, что кеш из-за жуткой неоптимизированности разрастался непропорционально быстро и на момент недостатка памяти весил более 5 метров. Первую проблему решил программной оптимизацией кеша, после которой его размер уменьшился в 10 раз (!!!) и рост стал много меньше.

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

Мораль сей басни такова - прежде чем применять новые технологии, стоит разобраться с собственным кодом🚬

Мораль этой басни такова, очередной сайт сделаный идуссами. Понятно что с таким успехом кладутся сайты и с 1000 уников в день. Это не highload,а джамшут&рамшуд™. В таких случаях xdebug Вам в руки.