Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 19
Убьете вы сервер таким способом.
Основывать такие вещи надо не на оригинальном друпале, а на Pressflow, а перед вебсервером, на котором работает PHP (надеюсь, у вас нe Apache + mod_php, a nginx + PHP-FPM?) надо бы еще Varnish поставить и ESI наладить. Тогда уже можно и социальную сеть строить. А без этого — ну максимум очень маленькое камерное сообщество.
Основывать такие вещи надо не на оригинальном друпале, а на Pressflow, а перед вебсервером, на котором работает PHP (надеюсь, у вас нe Apache + mod_php, a nginx + PHP-FPM?) надо бы еще Varnish поставить и ESI наладить. Тогда уже можно и социальную сеть строить. А без этого — ну максимум очень маленькое камерное сообщество.
насчёт Pressflow я подумаю, не знал, спасибо за подсказку.
насчёт сервера — стоит XAMPP, соответственно, вывод — стоит Апач. пока пусть будет так, со временем разгребусь.
насчёт сервера — стоит XAMPP, соответственно, вывод — стоит Апач. пока пусть будет так, со временем разгребусь.
Ну, XAMPP это для разработки, а о продакшне вы думаете уже? Нагрузки-то принципиально разные.
Основная критическая разница между PressFlow и Drupal в том, что первый не пытается создать сессию (и положить куку) для неавторизованных пользователей. Следовательно, для них можно вообще целиком всю страницу загнать в кеш reverse proxy, и при последующем обращении к сайту обращения к вебсерверу, поднимающему PHP, даже не произойдет, страница просто мгновенно отдастся из кеша.
Для авторизованных пользователей контент может быть закеширован поблочно, поскольку бОльшая часть блоков для разных пользователей все равно выглядит одинаково — следовательно, их не нужно перегенерировать, а можно опять же моментально отдать из кеша. Ну а дальше уже надо тонко настраивать Varnish в зависимости от проекта.
Основная критическая разница между PressFlow и Drupal в том, что первый не пытается создать сессию (и положить куку) для неавторизованных пользователей. Следовательно, для них можно вообще целиком всю страницу загнать в кеш reverse proxy, и при последующем обращении к сайту обращения к вебсерверу, поднимающему PHP, даже не произойдет, страница просто мгновенно отдастся из кеша.
Для авторизованных пользователей контент может быть закеширован поблочно, поскольку бОльшая часть блоков для разных пользователей все равно выглядит одинаково — следовательно, их не нужно перегенерировать, а можно опять же моментально отдать из кеша. Ну а дальше уже надо тонко настраивать Varnish в зависимости от проекта.
XAMPP для разработки, само собой :)
Для продакшна два варианта — либо IT-Patrol, либо Fozzy. Оба привлекательны как по цене, так и по характеристикам. Другие даже не рассматриваю.
Насчёт Varnish — предлагают вместо него APC и FastCGI, мол, неплохо ускоряет отдачу страничек.
Ну и кеширование блоков, само собой. Заодно, возможно, настройки кеширования в самом Drupal сделать.
Для продакшна два варианта — либо IT-Patrol, либо Fozzy. Оба привлекательны как по цене, так и по характеристикам. Другие даже не рассматриваю.
Насчёт Varnish — предлагают вместо него APC и FastCGI, мол, неплохо ускоряет отдачу страничек.
Ну и кеширование блоков, само собой. Заодно, возможно, настройки кеширования в самом Drupal сделать.
Неправильно предлагают.
APC работает на уровне PHP, FastCGI вообще не из этой оперы (это не значит, что надо обходиться без APC, это значит что не в нем дело)
Varnish вам позволит для определенной части посетителей вообще не обращаться к PHP-серверу, если нужный им контент уже закеширован. Как только вы допустили посетителя до PHP — все, производительности каюк — вам придется поднимать весь друпаловский бутстрап, даже для того чтобы один-единственный блок отдать. Лучше этого избегать как только можно. Для этого Varnish и нужен. Поищите в гугле Varnish Pressflow, там будет много подробных объяснений, как это и зачем.
Ну и конечно, если уж обращение к веб-серверу неминуемо, всегда дешевле сгенерировать только нужные блоки, чем страницу целиком. К тому же в Varnish вполне можно настроить для каждого блока индивидуально правила кеширования — на уровне пользователя и группы (вся группа пользователей шарит один экземпляр закешированного блока, при этом у каждой группы этот блок свой — например, у разных групп пользователей разная навигация), и на уровне времени протухания кеша (блок со списком комментариев протухает за минуту, блок с навигацией протухает за сутки, блок с основным контеном ноды протухает за час).
А насчет хостинга — нуууууу даже не знаю… Взяли бы DigitalOcean и не парились. Решение с Varnish требует физического сервера или VPS, виртуальный хостинг тут не поможет.
APC работает на уровне PHP, FastCGI вообще не из этой оперы (это не значит, что надо обходиться без APC, это значит что не в нем дело)
Varnish вам позволит для определенной части посетителей вообще не обращаться к PHP-серверу, если нужный им контент уже закеширован. Как только вы допустили посетителя до PHP — все, производительности каюк — вам придется поднимать весь друпаловский бутстрап, даже для того чтобы один-единственный блок отдать. Лучше этого избегать как только можно. Для этого Varnish и нужен. Поищите в гугле Varnish Pressflow, там будет много подробных объяснений, как это и зачем.
Ну и конечно, если уж обращение к веб-серверу неминуемо, всегда дешевле сгенерировать только нужные блоки, чем страницу целиком. К тому же в Varnish вполне можно настроить для каждого блока индивидуально правила кеширования — на уровне пользователя и группы (вся группа пользователей шарит один экземпляр закешированного блока, при этом у каждой группы этот блок свой — например, у разных групп пользователей разная навигация), и на уровне времени протухания кеша (блок со списком комментариев протухает за минуту, блок с навигацией протухает за сутки, блок с основным контеном ноды протухает за час).
А насчет хостинга — нуууууу даже не знаю… Взяли бы DigitalOcean и не парились. Решение с Varnish требует физического сервера или VPS, виртуальный хостинг тут не поможет.
Кстати, в этом топике предлагают использовать Squid вместо Varnish. Только в синтаксисе ни nginx, ни Apache пока не силён :( только-только начинаю его изучать
Может быть, у меня со сквидом и ESI (ESI — это важно!) опыта не было.
Но я вам так скажу — если вы останетесь на голом друпале+Apache, и ваш сайт на данном оборудовании потянет 20 одновременных подключений, то правильно сконфигурированный Pressflow + Varnish вам даст на том же оборудовании уже тысячи. Возможно, сквид даст миллион или миллиард ;-) — но для начала и тысячи неплохо. По настройке Pressflow+Varnish вы в комьюнити гораздо легче поддержку найдете.
Синтаксис у nginx и Apache несложный, чего там разбираться… гугл в руки и вперед, сложнее (и нужнее) понять, что конкретно надо делать, а не как именно это делать.
Но я вам так скажу — если вы останетесь на голом друпале+Apache, и ваш сайт на данном оборудовании потянет 20 одновременных подключений, то правильно сконфигурированный Pressflow + Varnish вам даст на том же оборудовании уже тысячи. Возможно, сквид даст миллион или миллиард ;-) — но для начала и тысячи неплохо. По настройке Pressflow+Varnish вы в комьюнити гораздо легче поддержку найдете.
Синтаксис у nginx и Apache несложный, чего там разбираться… гугл в руки и вперед, сложнее (и нужнее) понять, что конкретно надо делать, а не как именно это делать.
Кстати, по поводу Pressflow: ребята не рекомендуют сейчас ставить его, потому что
Но, что бы там ни было, загрузил с GitHub сборку Pressflow… лучше уж сразу, нежели потом.
the key enhancements from Pressflow 6 were added to Drupal 7.
Но, что бы там ни было, загрузил с GitHub сборку Pressflow… лучше уж сразу, нежели потом.
А знаете, может в таком случае я и неправильный совет дал, но тем не менее
If your project is built on Drupal 7 you might not need to use Pressflow at this time because the key enhancements from Pressflow 6 were added to Drupal 7.
Pressflow был актуален для шестерки, а для семерки его наработки были включены в ядро.
Сейчас на шестерке нет смысла разрабатывать что либо.
Подборка модулей стандартная, считаю не хватает еще IMCE и IMCE_MK_Dir.
Transliteration нужен больше для того, чтобы файлы на кириллице перекодировались на латиницу.
Transliteration нужен больше для того, чтобы файлы на кириллице перекодировались на латиницу.
Дальше нам нужно дополнительно как минимум два модуля: Views и CCK. Несмотря на то, что оба модуля включены в ядро
Во-первых, филды в D7 != CCK в D6
Во-вторых, у вас включён в ядро D7? Это что-то новое.
В целом, польза статьи сомнительна.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Создание медиаплощадки средствами Drupal. Задачи и обзор соответствующих модулей и библиотек