PHP Application and highload

[Kathrin]

Всем приветик! Начала изучать highload, так как это понадобится на работе.
Вроде информации много, но для связки с php не так уж и много.
Пишут используйте nginx вместо apache, но апач стал поддерживать потоки и в одном процессе может создать несколько поток, что увеличит производительность. А вот для отдачи статики то что нужно это Nginx.
Еще Nginx как балансировщик используют на несколько application server, но как не понятно.

Пишут используй php-fpm, но так же пишут, что не нужно ожидать прироста, так как компилятор запускается каждый раз заново. Правда плюшки безопасности + возможность остановить и запустить процесс (но насколько это плюшки не знаю).

А как быть с распределенной системой, например memcache плохо работает в распределенной системе (несколько application server например), можно данные перезатереть, а блокировка данных через одно место делается. Пишут надо Redis юзать, он отлично подходит для распределенных задач + реплицироватся может.

Где граница того что делает разработчик и сис-админ. Что должен предусмотреть разработчик в своем приложении?

Сори за поток мыслей, уж очень много информации. Еще изучаю очереди задач и сообщений, node.js, варнишь и т.д.

Может есть статьи для новичков по highload но главное в связке с приложением, а то большинство материалов для сис-админов.

 

[Фанат]

статьи для новичков по highload - оксюморон.

 

[Kathrin]

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

 

[С.]

Денормализации баз данных и кеширование это тоже начальный этап highload'а. В том-то и дело, что нет универсальных рецептов. Все решается в зависимости от условий и опыта архитектора.

 

[Фанат]

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

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

По самым общим вопросам можно, в принципе, ответить.
Парсер скриптов в хайлоад-системах запускается не каждый раз - используются акселераторы, которые хранят в оперативной памяти исполняемый код.
Nginx как балансировщик на несколько application server так и используют - один сервер с нжинксом и несколько аппликейшенов. В любом случае, настройка серверов в задачи миддл девелопера явно не входит.
Особых проблем с использованием мемкеша в распределенных системах не наблюдается, если применять его по назначению - для хранения временных данных, потеря которых никак на функциональности не сказывается - кэш просто формируется заново.

для новичков по highload но главное в связке с приложением

Сильно зависит, опять же, от конкретного приложения и используемого окружения.
В основном задача девелопера - аккуратнее дергать хранилища данных. Смотреть explain в mysql для каждого мало-мальски сложного запроса, думать над структурой БД (а вот архитектура серверов БД - уже не его забота), грамотно спроектировать модель, чтобы кэширование осуществлялось прозрачно для контроллера.

Так что позицию миддла я бы копал в сторону оптимизации работы с БД и кэшированием.

 

[Kathrin]

Денормализации баз данных и кеширование это тоже начальный этап highload'а. В том-то и дело, что нет универсальных рецептов. Все решается в зависимости от условий и опыта архитектора.

А откуда архитектор берет опыт? Ведь часто бизнес не терпит ошибок, не проверенное решение не дадут применить с угрозой для проекта. Играться не всегда получается ))

 

[Фанат]

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

 

[Kathrin]

"без реального понимания механизмов и важности того или иного элемента." Вот об этом и хочется узнать, на халяву нечего не нужно, главное понять базу, построить фундамент на котором пом можно будет воздвигнуть что то большое и красивое.

Спасибо, Фанат за грамотные ответы.
"а вот архитектура серверов БД - уже не его забота" я приводила пример на одной из прошлых работа где разработчик дорабатывал приложение под шардинг и реплику. Т.е. получаеться от разработчика все же требуются определенные знания что да как. Мне кажется, что разработчику в подобных вопросах было бы правильно контактировать с сис-админом, ведь разработчик лучше знает проект и его бизнес модель и может предположить будущие нагрузки и проблемные места + объемы данных.
Они должны работать вместе, что бы выдать хорошее решение, а для этого разработчик не должен смотреть на сис-админа как боран на новые ворота, понимание основ и базы должно быть.
Да и не все же сидеть в мидлах, хочется роста ))

Спасибки!

 

[Kathrin]

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

Я вас поняла.Я больше о таких вещах как " слушайте есть монго, а давайте его попробуем, многие юзают" или "node.js - супер вещь давайте приложение на нем строить" т.е. иногда говорят, но без аргументов, а каждое решение/продукт сделаны для своих задач и надо подходить с умом.

Насчет мэмкеша, встречала описание проблемы с хранением в нем сессий для распределенной системы, было перезатирание данных и навешивали костыли с блокировкой. А потом встретила, что Redis отлично подходит для этой задаче. Можно конечно и в MySQL хранить и не парится.

Очень радует конкретика в ответах, спасибо!

 

[Фанат]

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

не все же сидеть в мидлах, хочется роста

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

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

И на конфу обязательно приехать, разумеется.

 

[Фанат]

.Я больше о таких вещах как " слушайте есть монго, а давайте его попробуем, многие юзают"

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

Нет, разумеется - для конкретного сообщения об ошибке или известного бага решение найдётся. Но вот чем расплывчатее задача - тем сложнее найти на нее конкретный ответ.

Как уже писали выше, условия у всех разные. У одних монго идет, а у других - падает.
Тут без поиграться не получится.
И вполне может выйти фейл. И придется искать что-то другое. Но бизнес должен понимать, что no pains - no gains.

 

[Kathrin]

Я поняла, спасибо!

Все же "Который разрабатывает архитектуру и дает указания сисадмину," дает указание сис-админу, а то часто сис-админ просит не лезть в дела серверные ))
В подобной абстрактно-общей теме наверно попрошу скинуть ссылки на статьи, видео и сайты, которые следует почитать, посмотреть и почитать.
Спасибо за адекватные и правильные ответы. У девушек ум в 6 раз беспокойнее чем у парней (по ведам), сейчас мой ум слегка успокоился, буду читать изучать и не парится ))