Тогда цитируйте то, что хотите обсудить, я же видел цитату за простоту настройки :-)
Вот и я о том же, о чем и bolk — как можно совмещать темы простоты настройки и горизонтального масштабирования? Вы просто спутали эти две очень разные темы. Кстати автор топика по простоте ничего не писал.
Чтобы учиться делать производительные системы и становиться профессионалом нужно знать недостатки всех остальных систем, разве нет?
Абсолютно не означает, что надо игнорировать хорошие советы, чтобы самому набить шишки.
Я знаю достаточное количество довольно нагруженных проектов, которые используют Apache+mod_php, без особых проблем просто потому, что прежде, чем использовать тот или иной инструмент люди подумали головой и зная эти недостатки умеют их либо обходить, либо считают, что они несущественны по сравнению со «стоимостью владения» других решений.
Я уверен, что под «достаточно нагруженными проектами» мы с вами понимаем несколько разные вещи. Разумеется никто не мешает ограничить настройками число форков apache, но именно с точки зрения горизонтального масштабирования Apache + mod_php представляет собой проблему. Впрочем это лишь при определенных условиях. Но при прочих архитектурных правильностях связка nginx + php-fpm ничем не уступает связке nginx + apache + mod_php по производительности, но выигрывает по нагрузке на процессор и количеству занимаемой памяти. Вопрос: зачем же нужен Apache, кроме нежелания переписать правила для mod_rewrite, если настройку связки нужно сделать всего раз, а недостатки архитектуры хлебать при каждом запросе к динамическому контенту?
(Имеется ввиду, что найти на рынке *nix-админа, который сможет тупо развернуть «из коробки» LAMP гораздо проще и дешевле, чем гуру, способного собрать из некоторого количества true-on-the-edge решений что-то работоспособное, да и с разработчиками, четко понимающими суть этих технологий есть определенные проблемы)
На мой взгляд вы очень поверхностно считаете затраты на админа. Никто не мешает обходиться shared-хостингом и пенять на его «нерадивых» админов, из-за которых ваш проект заDDoSили посетители. А можно один раз разобраться самому или заплатить специалисту за настройку связки на своем сервере и больше на это не тратиться. В любом случае тема статьи предполагает что потребность в масштабировании подкреплена возможностями. Хотя бы возможностями разобраться в теме и настроить самостоятельно. Иначе статья состояла бы из одной фразы «вам нужно нанять специалиста, который настроит вам горизонтальное масштабирование».
Кстати, dns балансер по-моему самое не очень хорошее решение балансирования
а мужики от и не знают :)
$ for i in {1..5}; do host google.com | head -n 1; sleep 5; done;
google.com has address 74.125.143.113
google.com has address 74.125.143.100
google.com has address 74.125.143.101
google.com has address 74.125.143.129
google.com has address 74.125.143.131
$ for i in {1..5}; do host yandex.ru | head -n 1; sleep 5; done;
yandex.ru has address 213.180.193.11
yandex.ru has address 213.180.204.11
yandex.ru has address 93.158.134.11
yandex.ru has address 213.180.193.11
yandex.ru has address 213.180.204.11
с моей точки зрения удобнее более управляемые решения, в зависимости от предпочтений это могут быть NGINX, HAProxy, Cisco CSS и т.п.
Без dns-балансировщика они представляют собой единую точку отказа. Причем при горизонтальном масштабировании трафик упрется в производительность и полосу пропускания одного устройства, на котором и стоит load balanсer. Это вообще может лишить смысла горизонтально масштабированную архитектуру вашего сайта.
Таки нет :)
Главная проблема Apache — многопоточность. Именно в моменты большой популярности он может съесть всю память и залипнуть или выпасть в swap. И самое главное «нет» в том, что новичкам лучше не выбирать что проще, а учиться делать надежные производительные системы или нанимать профессионалов. Не крутить носом и отвергать «правильные» решения в пользу привычных. В конце концов зачем нужна статья, которая утверждает, что поможет повысить устойчивость к нагрузке и при этом содержит самое явное «бутылочное горлышко» в виде Apache. (Кстати в следющей статье таковым будет Mysql, если я правильно понимаю направление мысли автора).
Мой бы рецепт скорее всего состоял бы из изначального использования высокопроизводительной архитектуры с возможностями для горизонтального масштабирования. Например в случае с php я предложил бы писать приложение на reactphp.org, используя на фронтенде чистый nginx, а на бэкэнде MongoDB с GridFS, который имеет возможность горизонтального масштабирования «из коробки». При этом load balancer реализовал бы на основе dns и nginx.
Не так уж давно, но правда — речь шла о не самой новой версии даже на тот момент. А ситуация с качеством имеющихся в свободном доступе и особенностями разработки собственных дополнений к Joomla и сейчас не привлекает меня заново знакомиться с этим продуктом.
Нет, не предлагаю. Просто философски замечаю, что нахожу много не логичного во вполне работающем (если не трогать) продукте. И иронически отношу это на счет различия между мышлением землян и инопланетян.
Поисковики при индексации тоже. А поскольку база данных не часто целиком помещается в память (даже если говорить только о тех таблицах, что задействованы в запросе, сгенерированном модулем views), то по мере роста числа материалов в базе вы столкнетесь с тем фактом, что запрос «SELECT… LIMIT $offset, $items_per_page» при $offset = 100500 будет выполняться существенное время, блокируя другие запросы к базе данных (замерьте сами например здесь habrahabr.ru/posts/collective/page6821/ несколько раз с интервалом не меньше минут 15, чтобы не обольщаться ответом из query_cache). При этом несмотря на вашу, кстати не распространенную, привычку пользоваться этой ссылкой, на большинстве сайтов, существующих продолжительное время (как и в сыше приведенной ссылкой на хабре), пользователям совершенно не актуально начинать чтение с первых материалов, а стало быть и поисковикам незачем давать приоритет для них в индексации, располагая на всех страницах с этим пейджером ссылку на них.
По опыту, поисковики после отключения этой ссылки, перестают давать приоритет индексации древних, не актуальных материалов, а заодно несколькими медленными запросами становится меньше.
«5 must have пунтктов, которые безболезненно подойдут всем и каждому»:
— Не активируйте модули, в которых нет насущной необходимости. Почти любой модуль так или иначе ухудшает производительность
— Не забивайте базу ревизиями
— Уберите из шаблона пейджинга ссылку ">>" (перейти на последнюю страницу)
— Ставьте Recaptcha на формы логина и восстановления пароля
— Не связывайтесь с Drupal, без знания php и без готовности разбираться в его архитектуре.
«тонкий тюнинг для продвинутых в разных ситуациях» требует навыков телепатии.
А вообще я предлагал лишь описание конкретного опыта оптимизации Drupal с учетом недостатков его архитектуры и конкретной задачи повышения производительности на большом количестве данных при высоких требованиях к их актуальности.
Задачу оптимизации работы сервера под Drupal (тогда еще версия 6) я систематически решал в течении длительного времени. Просто перечислю то, что делал, чтобы выдерживать приличную нагрузку при весьма специфической задаче (поддержания электронного сми средней руки) с 14 блоками views только на главной и не менее трех на всех остальных. Помимо упомянутого вами это было:
1. Модуль cacherouter для переключения механизма кеширования с базы MySQL на APC (memcached при этом оказалось слишком прожорливым по ресурсу процессора, по крайней мере на коде годичной давности)
2. Патчем модуля локализации загнал почти все переводы интерфейса в кеш, что уменьшило приблизительно на 40 штук количество запросов к MySQL на страницу. В Drupal7 это сделать легче — достаточно изменить на большое значение одну строку в таблице variables
3. Написал собственный модуль на замену views. Разумеется без всякой универсальности, но достаточно гибкий, чтобы легко добавлять новые старницы и блоки со списками статей по новым тематикам. Главная его задача была в том, чтобы держать результаты в кеше и перечитывать MySQL только если были опубликованы новые статьи или изменено что-то в старых. Кроме того там решалась другая проблема — даже запрос на получение количества страниц в разделе мог занимать более секунды с учетом всех join по нескольким тегам и объема материалов на сайте. В общем там решался большой комплекс проблем, связанный с архитектурными ограничениями Drupal.
4. Глубокая инспекция запросов к MySQL (точнее к MariaDB, у которого изначально чуть лучше с query_cache). Дело в том, что когда количество реальных материалов в базе превысило разумные пределы оперативной памяти (характерная для MySQL проблема), некоторые весьма обычные запросы из Drupal стали выполняться по секунде и более, тормозя не только генерацию конкретной страницы, но и создавая заторы на веб-сервере вплоть до ошибки 502 из-за таймаута при пиковых количествах одновременных посетителей на сайте. В частности запросы поисковиков на страницу № 3000 (архивные для разделов, но индексируемые поисковиками ежедневно), которой нет в query_cache (а быть ее там в любой момент и не может, поскольку индексы по всем необходимым критериям физически не поместились бы в доступную оперативную память), затягивались и на секунду и на 3 и даже, иногда, на 8-10 секунд.
5. По результатам этой инспекции и принято решение о том, чтобы написать свои варианты вместо модулей views и sitemap, а также заменить встроенный поиск на Sphinx search
Был еще вагон различных более мелких оптимозаций, часть которых для Drupal7 не актуальна. В результате холодный (пустые кеши двух уровней) старт стартовой страницы стал занимать 3-4 секунды вместо 40-70 (что весьма вероятно означало ошибку 502 без этих оптимизаций), до 300-450 милисекунд на разогретой базе и заполненном кеше APC.
Из не относящегося к оптимизации Drupal было сделано следующее — LAMP изначально заменен на nginx + php-fpm + MariaDB. Настроен дисковый кеш для nginx на 30 секунд — минуту (специфика оперативных новостей больше не позволяла), что избавило от проблем с пиковыми нагрузками, которые доходили вплоть до 4000 одновременных посетителей (а 200 одновременных посетителей в то время были вполне будничным явлением).
Для большего числа подробностей лучше писать статью, так что дайте знать, если этот опыт актуален.
«Не верить — это право, а верить — привилегия». Так написал бы я, если бы хотел напустить тумана. А если серьезно, то нет ничего предосудительного в недоверии заявлениям о криптостойкости. На этом криптография и держится, а не на «привилегии» быть наивным.
Не знаю, как у вас, в в моей прошивке там есть еще меню с пунктом Advanced, где индивидуальные разрешения отзываются на ура. На более старых андройдая я использовал permission manager, который вырезал разрешения прямо из манифеста в apk.
Если кто-то еще не знает, то первым проектом по внедрению GlobalMoney были отделения самих мобильных операторов. То есть вроде бы приходишь в центр обслуживания Киевстар, даешь наличность на пополнение счета, а оказывается, что деньги зачислены через GlobalMoney. По неподтвержденной информации с этим «крышеванием» операторов связан и «вынос» комиссии за пополнение счетов — раньше карточки пополнения стоили столько же, сколько было на их счету, поскольку распространители получали их со скидкой, а потом комиссию сделали внешней и теперь за пополнение нужно везде доплачивать.
Если я правильно понял, то женское или мужское имя будет у урагана зависит от направления его закручивания. Поэтому в северном полушарии чаще бывают женские ураганы, чем мужские. Поправьте, если я не прав.
Надеюсь они ограничат возможность запрашивать фотки только номерми, которые есть в адресной книге аккаунта, но и это не самая надежная защита персональной информации.
Вот и я о том же, о чем и bolk — как можно совмещать темы простоты настройки и горизонтального масштабирования? Вы просто спутали эти две очень разные темы. Кстати автор топика по простоте ничего не писал.
Абсолютно не означает, что надо игнорировать хорошие советы, чтобы самому набить шишки.
Я уверен, что под «достаточно нагруженными проектами» мы с вами понимаем несколько разные вещи. Разумеется никто не мешает ограничить настройками число форков apache, но именно с точки зрения горизонтального масштабирования Apache + mod_php представляет собой проблему. Впрочем это лишь при определенных условиях. Но при прочих архитектурных правильностях связка nginx + php-fpm ничем не уступает связке nginx + apache + mod_php по производительности, но выигрывает по нагрузке на процессор и количеству занимаемой памяти. Вопрос: зачем же нужен Apache, кроме нежелания переписать правила для mod_rewrite, если настройку связки нужно сделать всего раз, а недостатки архитектуры хлебать при каждом запросе к динамическому контенту?
На мой взгляд вы очень поверхностно считаете затраты на админа. Никто не мешает обходиться shared-хостингом и пенять на его «нерадивых» админов, из-за которых ваш проект заDDoSили посетители. А можно один раз разобраться самому или заплатить специалисту за настройку связки на своем сервере и больше на это не тратиться. В любом случае тема статьи предполагает что потребность в масштабировании подкреплена возможностями. Хотя бы возможностями разобраться в теме и настроить самостоятельно. Иначе статья состояла бы из одной фразы «вам нужно нанять специалиста, который настроит вам горизонтальное масштабирование».
а мужики от и не знают :)
Без dns-балансировщика они представляют собой единую точку отказа. Причем при горизонтальном масштабировании трафик упрется в производительность и полосу пропускания одного устройства, на котором и стоит load balanсer. Это вообще может лишить смысла горизонтально масштабированную архитектуру вашего сайта.
Главная проблема Apache — многопоточность. Именно в моменты большой популярности он может съесть всю память и залипнуть или выпасть в swap. И самое главное «нет» в том, что новичкам лучше не выбирать что проще, а учиться делать надежные производительные системы или нанимать профессионалов. Не крутить носом и отвергать «правильные» решения в пользу привычных. В конце концов зачем нужна статья, которая утверждает, что поможет повысить устойчивость к нагрузке и при этом содержит самое явное «бутылочное горлышко» в виде Apache. (Кстати в следющей статье таковым будет Mysql, если я правильно понимаю направление мысли автора).
Мой бы рецепт скорее всего состоял бы из изначального использования высокопроизводительной архитектуры с возможностями для горизонтального масштабирования. Например в случае с php я предложил бы писать приложение на reactphp.org, используя на фронтенде чистый nginx, а на бэкэнде MongoDB с GridFS, который имеет возможность горизонтального масштабирования «из коробки». При этом load balancer реализовал бы на основе dns и nginx.
Поисковики при индексации тоже. А поскольку база данных не часто целиком помещается в память (даже если говорить только о тех таблицах, что задействованы в запросе, сгенерированном модулем views), то по мере роста числа материалов в базе вы столкнетесь с тем фактом, что запрос «SELECT… LIMIT $offset, $items_per_page» при $offset = 100500 будет выполняться существенное время, блокируя другие запросы к базе данных (замерьте сами например здесь habrahabr.ru/posts/collective/page6821/ несколько раз с интервалом не меньше минут 15, чтобы не обольщаться ответом из query_cache). При этом несмотря на вашу, кстати не распространенную, привычку пользоваться этой ссылкой, на большинстве сайтов, существующих продолжительное время (как и в сыше приведенной ссылкой на хабре), пользователям совершенно не актуально начинать чтение с первых материалов, а стало быть и поисковикам незачем давать приоритет для них в индексации, располагая на всех страницах с этим пейджером ссылку на них.
По опыту, поисковики после отключения этой ссылки, перестают давать приоритет индексации древних, не актуальных материалов, а заодно несколькими медленными запросами становится меньше.
— Не активируйте модули, в которых нет насущной необходимости. Почти любой модуль так или иначе ухудшает производительность
— Не забивайте базу ревизиями
— Уберите из шаблона пейджинга ссылку ">>" (перейти на последнюю страницу)
— Ставьте Recaptcha на формы логина и восстановления пароля
— Не связывайтесь с Drupal, без знания php и без готовности разбираться в его архитектуре.
«тонкий тюнинг для продвинутых в разных ситуациях» требует навыков телепатии.
А вообще я предлагал лишь описание конкретного опыта оптимизации Drupal с учетом недостатков его архитектуры и конкретной задачи повышения производительности на большом количестве данных при высоких требованиях к их актуальности.
1. Модуль cacherouter для переключения механизма кеширования с базы MySQL на APC (memcached при этом оказалось слишком прожорливым по ресурсу процессора, по крайней мере на коде годичной давности)
2. Патчем модуля локализации загнал почти все переводы интерфейса в кеш, что уменьшило приблизительно на 40 штук количество запросов к MySQL на страницу. В Drupal7 это сделать легче — достаточно изменить на большое значение одну строку в таблице variables
3. Написал собственный модуль на замену views. Разумеется без всякой универсальности, но достаточно гибкий, чтобы легко добавлять новые старницы и блоки со списками статей по новым тематикам. Главная его задача была в том, чтобы держать результаты в кеше и перечитывать MySQL только если были опубликованы новые статьи или изменено что-то в старых. Кроме того там решалась другая проблема — даже запрос на получение количества страниц в разделе мог занимать более секунды с учетом всех join по нескольким тегам и объема материалов на сайте. В общем там решался большой комплекс проблем, связанный с архитектурными ограничениями Drupal.
4. Глубокая инспекция запросов к MySQL (точнее к MariaDB, у которого изначально чуть лучше с query_cache). Дело в том, что когда количество реальных материалов в базе превысило разумные пределы оперативной памяти (характерная для MySQL проблема), некоторые весьма обычные запросы из Drupal стали выполняться по секунде и более, тормозя не только генерацию конкретной страницы, но и создавая заторы на веб-сервере вплоть до ошибки 502 из-за таймаута при пиковых количествах одновременных посетителей на сайте. В частности запросы поисковиков на страницу № 3000 (архивные для разделов, но индексируемые поисковиками ежедневно), которой нет в query_cache (а быть ее там в любой момент и не может, поскольку индексы по всем необходимым критериям физически не поместились бы в доступную оперативную память), затягивались и на секунду и на 3 и даже, иногда, на 8-10 секунд.
5. По результатам этой инспекции и принято решение о том, чтобы написать свои варианты вместо модулей views и sitemap, а также заменить встроенный поиск на Sphinx search
Был еще вагон различных более мелких оптимозаций, часть которых для Drupal7 не актуальна. В результате холодный (пустые кеши двух уровней) старт стартовой страницы стал занимать 3-4 секунды вместо 40-70 (что весьма вероятно означало ошибку 502 без этих оптимизаций), до 300-450 милисекунд на разогретой базе и заполненном кеше APC.
Из не относящегося к оптимизации Drupal было сделано следующее — LAMP изначально заменен на nginx + php-fpm + MariaDB. Настроен дисковый кеш для nginx на 30 секунд — минуту (специфика оперативных новостей больше не позволяла), что избавило от проблем с пиковыми нагрузками, которые доходили вплоть до 4000 одновременных посетителей (а 200 одновременных посетителей в то время были вполне будничным явлением).
Для большего числа подробностей лучше писать статью, так что дайте знать, если этот опыт актуален.