Apache зачем нужен: Apache

Содержание

Что такое веб-сервер Apache и как им пользоваться 🍂

4 июня 2020

1 390

Время чтения ≈ 11 минут

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

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

Звание самого популярного веб-сервера в мире уже более 25 лет удерживает за собой Apache HTTP Server, который принято называть сокращенно Apache или «Апач». Сегодня программа обслуживает более 40% всех существующих серверов, включая проекты IBM, eBay, PayPal и Facebook.

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

Что это такое

Apache – это открытое программное обеспечение для создания веб-сервера (HTTP-сервера). Его главная функция – быстрая и надежная доставка контента в сети Интернет. Веб-сервер принимает запросы от клиентов через веб-браузер по протоколу HTTP/HTTPS. В ответ Apache отправляет браузеру искомый контент (документы, изображения, видео) в виде статических HTML-страниц.

История создания

Apache HTTP Server был выпущен в 1995 году разработчиком Робертом Маккулом из Университета штата Иллинойс (UIUC). Продукт возник как доработанная версия другого HTTP-клиента – NCSA HTTPd 1.3, созданного Робертом ранее.

Основой для модификации стали многочисленные «патчи» или программные «заплатки» для NCSA. Именно отсюда (а не от индейского племени апачей) изначально и происходит название Apache. Оно расшифровывается как «a patchy server» или «сервер с патчами».

Разработкой и поддержкой продукта с 1999 года занимается организация Apache Software Foundation (ASF) – сообщество экспертов-энтузиастов со всего мира. Этим же некоммерческим фондом была создана официальная лицензия ПО – Apache License.

В 2000 году ASF представило новую версию Apache 2.0 с полностью переработанной архитектурой, свободной от кода NCSA. С этого момента веб-сервер развивается по двум основным веткам – 1.х и 2.х.

Достоинства и недостатки Apache

Плюсы

Доступность. Это программное обеспечение с открытым исходным кодом. Значит, его может бесплатно использовать или модифицировать любой желающий. Разработчики по всему миру создают конфигурации и модули веб-сервера для своих специфических нужд. По этой же причине Apache регулярно получает полезные дополнения, расширяющие его базовый функционал.
Удобство и гибкость настройки. Приложение легко настраивается через текстовые конфигурационные файлы. Apache способен обрабатывать большой объем трафика и быстро масштабироваться, даже без сложного дополнительного конфигурирования.
Функциональность. У Apache динамическая модульная структура. Можно быстро подключать дополнительный функционал в виде скачиваемых модулей, даже без обращения к внешним источникам. Это позволяет решать целый комплекс важнейших задач в области безопасности, кэширования, редактирования URL, распределения нагрузки. Благодаря гибридным модулям MPM, Apache может одинаково успешно обслуживать статический и динамический контент. Есть возможность оперативно отключать ненужные модули и ускорять работу веб-сервера
Короссплатформенность. Сервер работает как на Windows и MacOS, так и на всех Unix-подобных системах. Система администрирования не имеет серьезных отличий на разных операционках. Различаи только в процессе установки и путям к директориям.
Совместимость. Apache работает на базе скриптовых или веб-ориентированных языков (PHP, Python, Tcl, Ruby, Perl, ASP), что делает его совместимым с самым широким спектром баз данных и серверного ПО. Многие веб-приложения и инструменты сразу выходят со средствами запуска из-под Apache в виде PHP-модуля. Веб-сервер, поддерживает технологии FastCGI и CGI, позволяющие пользоваться программными продуктами на объектно-ориентированных языках Java, sh, C, C++.
Масштабируемость. Подходит для веб-ресурсов любого масштаба. Apache хорошо работает как на одностраничном сайте (лендинге), так и на многостраничном сайте с ежедневной аудиторией в десятки тысяч посетителей.
Поддержка пользователей. Apache удерживает первенство популярности среди веб-серверов с 1996 года. За прошедшее время для него создана обширнейшая база документации – как официальной, так и созданной сторонними разработчиками. Готовые, подробно описанные руководства можно найти практически на любой сценарий.

Минусы

Трафик влияет на производительность. На сайтах с большой посещаемостью производительность веб-сервера может значительно снижаться, что замедляет работу самого ресурса. Это связано с тем, что работа Apache основана на модели «процессов» и обрабатывает каждый пользовательский запрос отдельно.
Сложная конфигурация повышает уязвимость. Возможность подключать модули в Apache это не всегда преимущество. Чем больше модулей, тем сложнее становятся настройки. Соответственно, больше шансов допустить критические пробелы в контуре безопасности.
Неудобное редактирование. В операционных системах семейства Unix/Linux конфигурационные файлы Apache приходится редактировать вручную. Это связано с отсутствием встроенного графического интерфейса для настройки. Решение проблемы – бесплатный инструмент Apache GUI, позволяющий настраивать функции веб-сервера прямо из браузера.
Излишний функционал. Даже без дополнительных модулей Apache предоставляет пользователям массу возможностей. Правда, большинство использует лишь небольшую часть базового функционала приложения. Поэтому часто после установки приходится тратить время на отключение «лишних» модулей.

Как устроен Apache

Архитектура

Apache состоит из ядра и динамической модульной системы. Параметры системы изменяются с помощью конфигурационных файлов. Для запуска на сервере нескольких веб-проектов одновременно используется механизм виртуальных хостов.

Ядро

Ядро Apache разработано Apache Software Foundation на языке C. Основные функции — обработка конфигурационных файлов, протокол HTTP/HTTPS и загрузка модулей. Ядро может работать без модулей, но будет иметь ограниченный функционал.

Модульная система

Модуль – отдельный файл, подключение которого расширяет изначальный функционал ядра. Они могут включаться в состав ПО при первоначальной установке или подгружаться позже через изменение конфигурационного файла.

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

Для Apache существует больше 500 модулей. Многие популярные веб-приложения сразу выпускаются в виде модуля к Apache. Например, ISPmanager и VDSmanager.

Конфигурация

Система конфигурации Apache работает на текстовых файлах с прописанными настройками. Она подразделяется на три условных уровня, для каждого из которых имеется свой конфигурационный файл:

Уровень конфигурации сервера (файл httpd.conf) – основной конфигурационный файл. Действие распространяется на весь механизм веб-сервера.
Уровень каталога (файл .htaccess) – дополнительный конфигурационный файл. Его директивы охватывают только каталог, где расположен файл, а также вложенные подкаталоги.
Уровень виртуального хоста (файл httpd.conf или extra/httpd-vhosts.conf).

Обычно конфигурационные файлы Apache находятся в папке «conf», а дополнительные конфигурационные файлы во вложенной в нее папке «extra». Внести изменения можно как через редактирование самого файла, так и через командную строку.

Виртуальные хосты

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

В Apache можно установить настройки модуля и ядра, а также вводить лимиты на потребление серверных ресурсов (трафик, RAM, CPU) для каждого виртуального хоста в отдельности. Это технологическая основа всего механизма веб-хостинга.

Альтернативы Apache

NGINX

Nginx (Engine-X, «энжинкс») — второе по популярности веб-серверное приложение и главный конкурент Apache. Было выпущено в 2004 году под открытой лицензией BSD. Изначально приложение создавалось для решения проблемы масштабирования, известной как «10 тысяч соединений» (С10к). Это значит, что до Nginx веб-сервер не был способен одновременно обрабатывать пользовательские запросы более чем с 10 000 подключений.

У этого веб-сервера асинхронная событийно-ориентированная архитектура (event-driven), которая позволяет добиваться быстрого масштабирования даже при минимальных ресурсах. Вместо того, чтобы создавать новый процесс для каждого пользовательского запроса, Nginx обрабатывает множество соединений в едином потоке.

Nginx отлично подходит для веб-проектов с высокой посещаемостью. Однако веб-сервер не может самостоятельно работать с динамическим контентом. Поэтому его чаще используют для статических веб-сайтов или например, в связке с PHP-FPM или Apache HTTP Server как прокси-сервер.

Lighttpd

Веб-сервер Lighttpd (произносится «лайти») — кроссплатформенное программное обеспечение на языке С. Выпущено в 2003 году под лицензией BSD. «Лайти» работает на операционных системах Windows и семейства Unix/Linux. Приложение поддерживает технологии FastCGI, SCGI, HTTP proxy, Auth, перезаписи URL и AJP (с версии 1.5).

Как и Nginx, изначально «Лайти» создавалось для решения проблемы «С10к». Неудивительно, что его специализация — веб-проекты с большой посещаемостью. В числе компаний, использующих Lighttpd, такие гиганты, как Google, Википедия, Яндекс и Ubuntu.

Microsoft IIS

Internet Information Services (IIS) — набор сервисов для создания веб-сервера от компании Microsoft. Распространяется в комплекте с операционными системами Windows NT как дополнительно устанавливаемый компонент. Веб-сервер поддерживает технологии CGI, FastCGI, ISAPI и SSI.

Главная сила IIS – в глубокой интеграции и поддержке продуктов Microsoft. Его часто выбирают те, чьи ресурсы работают на движке ASP.NET и используют скриптовый язык ASPX. Главный недостаток – жесткая привязка к операционной системе Windows и отсутствие версий для Unix/Linux.

Tomcat

Apache Tomcat — это контейнер сервлетов, который обрабатывает спецификации Java. Например, Java Servlet, Java Server Pages (JSP), Java EL и WebSocket. Продукт был разработан фондом Apache Software Foundation на основе открытой лицензии Apache License 2.0. Tomcat используется как в качестве самостоятельного веб-сервера, так и в связке с Apache HTTP Server.

Приложение написано на языке Java и способно автоматически загружать Java-библиотеки. Его основная специализация — веб-проекты с динамическим содержимым. Но у Apache Tomcat хуже возможности для настройки, что сужает его сферу применения. Например, для запуска WordPress эффективнее использовать обычный HTTP-сервер Apache.

Заключение

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

Система конфигурационных файлов дает «Апач» гибкие возможности для настройки, а динамически подгружаемые модули расширяют функционал до максимума. Особенно эффективно использовать веб-сервер Apache в связке с ближайшим аналогом – Nginx.

Для работы с «Апач» пользователю нужен определенный уровень IT грамотности. Желательно знать основы программирования и веб-администрирования. Но процесс сильно упрощает активное сообщество поддержки и отлично развитая база официальной документации.

Раскройте все возможности и преимущества веб-сервера Apache с надёжным хостингом от Eternalhost!

Оцените материал:

[Всего голосов: 3 Средний: 5/5]

Apache vs Nginx: практический взгляд / Хабр

Введение

Apache и Nginx — 2 самых широко распространенных веб-сервера с открытым исходным кодом в мире. Вместе они обслуживают более 50% трафика во всем интернете. Оба решения способны работать с разнообразными рабочими нагрузками и взаимодействовать с другими приложениями для реализации полного веб-стека.

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

Общий обзор

Прежде чем погрузиться в различия между Apache и Nginx давайте бегло взглянем на предысторию каждого из этих проектов.

Apache

Apache HTTP Server был разработан Робертом Маккулом в 1995 году, а с 1999 года разрабатывается под управлением Apache Software Foundation — фонда развития программного обеспечения Apache. Так как HTTP сервер это первый и самый популярный проект фонда его обычно называют просто Apache.

Веб-север Apache был самым популярным веб-сервером в интернете с 1996 года. Благодаря его популярности у Apache сильная документация и интеграция со сторонним софтом.

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

Nginx

В 2002 году Игорь Сысоев начал работу над Nginx для того чтобы решить проблему C10K — требование к ПО работать с 10 тысячами одновременных соединений. Первый публичный релиз был выпущен в 2004 году, поставленная цель была достигнута благодаря асинхронной event-driven архитектуре.

Nginx начал набирать популярность с момента релиза благодаря своей легковесности (light-weight resource utilization) и возможности легко масштабироваться на минимальном железе. Nginx превосходен при отдаче статического контента и спроектирован так, чтобы передавать динамические запросы другому ПО предназначенному для их обработки.

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

Архитектура обработки соединений

Одно из самых существенных отличий между Apache и Nginx состоит в том как они обрабатывают соединения и отвечают на различные виды трафика.

Apache

Apache предоставляет несколько модулей мультипроцессинга (multi-processing modules, MPM), которые отвечают за то как запрос клиента будет обработан. Это позволет администраторам определять политику обработки соединений. Ниже представлен список MPM-модулей Apache:

mpm_prefork — этот модуль создает по одному процессу с одним потоком на каждый запрос. Каждый процесс может обрабатывать только одно соединение в один момент времени. Пока число запросов меньше числа процессов этот MPM работает очень быстро. Однако производительность быстро падает когда число запросов начинает превосходить число процессов, поэтому в большинстве случаев это не самый лучший выбор. Каждый процесс потребляет значительный объем RAM, поэтому этот MPM сложно поддается масштабированию. Но он может быть использован вместе с компонентами, которые не созданы для работы в многопоточной среде. Например, PHP не является потокобезопасным, поэтому этот MPM рекомендуется использовать как безопасный метод работы с mod_php.

mpm_worker — этот модуль создает процессы, каждый из которых может управлять несколькими потоками. Каждый поток может обрабтывать одно соединение. Потоки значительно более эффективны чем процессы, что означает что mpm_worker масштабируется значительно лучше чем mpm_prefork. Так как потоков больше чем процессов это означает, что новое соединение может быть сразу обработано свободным потоком, а не ждать пока освободится процесс.

mpm_event — этот модуль похож на mpm_worker, но оптимизрован под работу с keep-alive соединениями. Когда используется mpm_worker соединение будет удерживать поток вне зависимости от того активное это соединение или keep-alive. Mpm_event выделяет отдельные потоки для keep-alive соединений и отдельные потоки для активных соединений. Это позволяет модулю не погрязнуть в keep-alive соединениях, что необходимо для быстрой работы. Этот модуль был отмечен как стабильный в Apache версии 2.4.

Как вы можете видеть Apache предлагает гибкие возможности для выбора различных алгоритмов обработки соединений и запросов.

Nginx

Nginx появился на сцене позднее Apache, по этой причине, его разработчик был лучше осведомлен о проблемах конкурентности, с которыми сталкиваются сайты при масштабировании. Благодаря этим знаниям Nginx изначально был спроектирован на базе асинхронных неблокирующих event-driven алгоритмов.

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

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

Этот подход к обработке соединений позволяет Nginx’у невероятно масштабироваться при ограниченных ресурсах. Поскольку сервер однопоточный и он не создает процессы под каждое соединение, использование памяти и CPU относительно равномерно, даже при высоких нагрузках.

Статический и динамический контент

Если рассматривать жизненные примеры, то основные различия между Apache и Nginx в том как они обрабатывают запросы к статическому и динамическому контенту.

Apache

Apache может раздавать статический контент используя стандартные file-based методы. Производительность таких операций зависит от выбранного MPM.

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

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

Nginx

Nginx не имеет возможности самостоятельно обрабатывать запросы к динамическому контенту. Для обработки запросов к PHP или другому динамическому контенту Nginx должен передать запрос внешнему процессору для исполнения, подождать пока ответ будет сгенерирован и получить его. Затем результат может быть отправлен клиенту.

Для администраторов это означает, что нужно настроить взаимодействие Nginx с таким процессором используя один из протоколов, который известен Nginx’у (http, FastCGI, SCGI, uWSGI, memcache). Это может немного усложнить процесс настройки, в особенности когда вы будете пытаться предугадать какое число соединений разрешить, так как будет использоваться дополнительное соединение с процессором на каждый пользовательский запрос.

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

Распределенная конфигурация против централизованной

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

Apache

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

Так как такие конфигурационные файлы находятся в директриях с контентом, Apache вынужден при обработке каждого запроса проверять не содержит ли каждый компонент запрашиваемого пути файл .htaccess и исполнять директивы в найденных файлах. Это позволяет децентрализовать конфигурирование веб-сервера, что позволяет реализовать на уровне директорий модификацию URL’ов (URL rewrite), ограничения доступа, авторизацию и аутентификацию и даже политики кеширования.

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

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

Nginx

Nginx не интерпретирует файлы .htaccess и не предоставляет механизм конфигурирования на уровне директорий за пределами основного конфигурационного файла. Этот подход может показаться менее гибким чем в случае с Apache, но он имеет свои преимущства.

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

Так как Nginx не позволяет переопределять конфиги на уровне директорий, он может обрабатывать запросы быстрее, ведь ему достаточно сделать один directory lookup и прочитать один конфигурационный файл на каждый запрос (предполагается, что файл найден там где он должен быть по соглашению).

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

Имейте ввиду, что вы можете отключить поддержку .htaccess в Apache, если сказанное выше произвело на вас впечатление.

Интерпретация базирующаяся на файлах и URI

То как веб-сервер интерпретирует запрос и сопоставляет его с ресурсом в системе это еще одна отличительная особенность в этих двух серверах.

Apache

Apache имеет возможность интерпретировать запрос как физический ресурс в файловой системе или как URI, который требует дополнительной обработки. Первый тип запросов использует конфигурационные блоки <Directory> или <File>, второй — блоки <Location>.

Так как Apache изначально был спроектирован как веб-сервер, он по умолчанию интерпретирует запросы как ресурсы в файловой системе. Он берет document root веб-сервера и дополняет его частью запроса, которая следует за именем хоста и номером порта, чтобы найти запрашиваемый файл. В общем случае, иерархия файловой системы представленная в вебе доступна как дерево документов.

Apache предоставляет ряд альтернатив на случай когда запрос не соответствует файлу в файловой системе. Использование блоков <Location> это метод работы с URI без отображения на файловую систему. Также возможно использовать регулярные выражения, которые позволяют задать более гибкие настройки для всей файловой системы.

Так как Apache может оперировать и c файловой системой, и с webspace, то он в основном опирается на методы работы с файловой системой. Это видно в некоторых решениях в дизайне архитектуры веб-сервера, например, в использовании файлов .htaccess для конфигурирования на уровне директорий. Документация к Apache не рекомендует использовать URI-блоки для ограничения доступа для запросов к файловой системе.

Nginx

Nginx создан, чтобы работать и в качестве веб-сервера, и в качестве прокси-сервера. По этой причине он работает в первую очередь с URI, транслируя их при необходимости в запросы к файловой системе.

Эта особенность прослеживается в том как для Nginx конструируются и интерпретируются конфигурационные файлы. В Nginx нет способа создать конфигурацию для заданной директории, вместо этого он парсит URI.

Например, основными конфигурационными блоками в Nginx являются <server> и <location>. В блоке <server> определяется хост, который будет обслуживаться, блок <location> отвечает за обработку части URI, которая идет после имени хоста и номера порта. Таким образом, запрос интерпретируется как URI, а не как путь в файловой системе.

В случае запросов к статическим файлам все запросы должны быть отображены (mapped) на путь в файловой системе. Сначала Nginx выбирает блоки server и location, которые будут использованы для обработки запроса и затем объединяет document root с URI, в соответствии с конфигурацией.

Эти подходы (интерпретация запроса как пути в файловой системе и как URI) могут показаться похожими, но тот факт что Nginx рассматривает запросы как URI, а не как пути в файловой системе позволяет ему легче справляться одновременно и с ролью веб-сервера, и с ролью прокси. Nginx конфигурируется так, чтобы отвечать на различные шаблоны запросов. Nginx не обращается к файловой системе до тех пор пока он не готов обслужить запрос, что объясняет почему он не реализует ничего похожего на файлы .htaccess.

Модули

И Apache, и Nginx могут быть расширены при помощи системы модулей, но способы реализации модульной системы принципиально отличаются.

Apache

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

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

Использование модулей не ограничивается лишь обработкой динамических запросов. Среди других возможностей модулей: изменение URL’ов (URL rewrite), аутентификация клиентов, защита сервера, логгирование, кеширование, сжатие, проксирование, ограничение частоты запросов, шифрование. Динамические модули могут значительно расширить функцональность ядра.

Nginx

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

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

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

Модули Nginx реализуют те же возможности, что и модули Apache: проксирование, сжатие данных, ограничение частоты запросов, логгирование, модификация URL’ов, гео-локация, аутентификация, шифрование, потоковое вещание, почтовые функции.

Поддержка, совместимость, экосистема и документация

В процессе использования приложения важными являются экосистема созданная вокруг него и возможность получения поддержки.

Apache

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

Существует много инструментов и веб-проектов идущих в комплекте со средствами запуска самих себя из под Apache. Это относится как к самим проектам, так и к системам управления пакетами.

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

Nginx

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

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

Разработчики стороннего ПО также начинают поддерживать работу с Nginx и некоторые из них уже предлагают на выбор пользователя конфиги для работы или с Apache, или с Nginx. И даже без поддержки приложением работы с Nginx не составляет большого труда написать свой конфиг для интеграции приложения с Nginx.

Совместное использование Apache и Nginx

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

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

Nginx будет самостоятельно обслуживать статический контент, а для динамического контента, например для запросов к PHP-страницам, будет передавать запрос к Apache, который будет рендерить страницу, возвращать ее Nginx’у, а тот в свою очередь будет передавать ее пользователю.

Такая конфигурация очень популярна, Nginx используется в ней для сортировки запросов. Он обрабатывает сам те запросы которые может и передает Apache только запросы, которые не может обслужить сам, снижая таким образом нагрузку на Apache.

Эта конфигурация позволяет горизонтально масштабировать приложение: вы можете установить несколько бэкенд серверов за одним фронтендом и Nginx будет распределять нагрузку между ними, увеличивая тем самым отказоустойчивость приложения.

Заключение

Как вы можете видеть и Apache, и Nginx — это мощные, гибкие и функциональные инструменты. Для того чтобы выбрать сервер под ваши задачи необходимо определиться с требованиями к нему и провести тесты на всех возможных паттернах использования вашего приложения.

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

Веб сервер Apache (Web Апач) ➡ что это, как работает и какие у него преимущества

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

Сегодня, одним из наиболее популярных веб-серверов, является Apache. Именно его мы и разберем в данной статье. По разным данным, он занимает от 50 до 65%.

Веб-сервер Apache – что это?

HTTP-сервер Apache, является свободным, кроссплатформенным программным обеспечением, которое отлично работает со следующими ОС:

Windows;
BeOS;
BSD;
Mac OS;
Linux;
И др.

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

Обработанные файлы превращаются в статический файл HTML, и передаются пользователю.

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

Web-сервер Apache, был создан в далеком 1995-м году. Считается, что его название было дано не в честь гордого племени Апачи, а происходит из игры слов «a patchy» (заплатка на английском). Дело в том, что первая версия этой программы изначально использовалась для устранения множества неисправностей популярного в то время сервера NCSA HTTPd. В новых версиях http сервер apache, избавился от чужого кода и стал полностью автономной системой.

На сегодняшний день, веб-сервер Апач, работает на трети всех веб-серверов в мировой сети. Это более трехсот миллионов сайтов.

Преимущества веб-сервера Апач

Разумеется, главным достоинством данного веб-сервера, является не возможность свободно его использовать. К преимуществам http сервера Apache, необходимо отнести высокий уровень надежности и гибкие настройки. В частности, к нему можно подключать большое количество внешних модулей, систем управления базами данных и т.п. Также он поддерживает интернет-протокол IPv6.

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

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

При работе с сайтами на Вордпрессе, не требует дополнительных настроек после установки.

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

Недостатки сервера Апач

Как и у любой другой вещи, все недостатки Apache, являются логическим продолжением его достоинств. Наиболее вескими недостатками являются:

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

Ядро веб-сервера Апач

Ядро этого ПО, разрабатывается фондом Apache Software Foundation, который поддерживает огромное количество разработчиков по всему миру. Его основными функциями являются:

Передача данных по HTTP;
Обработка файлов;
Загрузка и поддержка модулей.

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

Конфигурация web-сервера Apache

Конфигурацию данного ПО, можно разделить на три основных уровня:

Конфигурация сервера;
Конфигурация виртуального хоста;
Конфигурация уровней каталога.

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

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

Разумеется, ряд настроек может задаваться с помощью командной строки.

Доступные варианты многопроцессорных моделей (MPM)

Как и многие современные веб-сервера, Apache поддерживает несколько разных вариантов архитектуры для многопроцессорных систем. К ним относится:

Worker – модель разработанная создателями веб-сервера. Предназначена для работы с ОС Linux и FreeBSD. Её отличительными чертами является высокий уровень стабильности и возможность работать с большим количеством клиентов, при средней загруженности;
Pre-fork – работает с теми же операционными системами, но позволяет получить большую безопасность и стабильность, благодаря изоляции вычислительных процессов;
Perchild – гибридная модель, которая работает только с Линуксом и поддерживает ограниченное количество процессов. В будущем, планируется что эту архитектуру будут использовать для высоконагруженных процессов, но сегодня она не может похвастаться высокой стабильностью работы, и поэтому находится в стадии разработки;
NetWare – как становится понятно из названия, данная архитектура предназначена для работы с одноименной ОС;
Winnt – если вам нужен веб сервер Apache для Windows, то эта архитектура – лучший вариант.

Модули

Как уже было сказано, система модулей позволяет существенно расширить функционал веб-сервера, и на сегодняшний день, голое ядро практически никто не использует. Например, если вы планируете работать на веб-сервере Apache с PHP и MySQL.

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

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

Различные модули позволяют:

Поддерживать разные языки программирования;
Расширять функционал веб-сервера;
Исправлять различные ошибки;
Улучшать безопасность работы.

Важно знать, что некоторые приложения, например, популярные панели управления сайтами, по сути являются модулями для web-сервера Апач.

Виртуальный хосты для серверов Апач

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

Локальный сервер Apache

Локальный сервер является крайне полезной вещью, если вы планируете экспериментировать с кодом, тестировать сайты или ПО на уязвимость, и т.п. Такой сервер позволяет проверить все планируемые изменения, перед тем, реализовывать их на «живом» сайте.

В общем и целом, процесс установки такого сервера не сильно отличается от стандартного. Однако ряд отличий все же имеется.

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

Работа с разными языками программирования

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

ASP;
Ruby;
PHP;
Tcl;
Python;

Безопасность сервера Apache

Основными механизмами разграничения доступов к данным, а также обеспечения безопасности, для веб-серверов Апач, являются:

Возможность ограничения доступа к папкам и файлам;
Модули, позволяющие авторизироваться через PAM или системы управления базами данных;
Механизм авторизации, основанный на HTTP и digest аутентификации;
Возможность запретить доступ к файлам конфигурации для некоторых, или для всех пользователей;
Запрет или ограничение доступа по IP-адресам.

Шифрование данных, при использовании протокола HTTPS, применяется библиотека OpenSSL. Подлинность серверов, обеспечивается с помощью сертификатов X.059.

Региональные настройки для Apache

Возможность определения региональных настроек для конкретного пользователя, появилась с второй версии веб-сервера Апач. К таким настройкам относятся:

Часовой пояс;
Определение географического местоположения;
Язык интерфейса и сообщений о происшествиях и ошибках;
Наборы символов;
Используемые денежные единицы и др.

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

Вывод

Сегодня веб-сервер Apache, является заслуженным лидером в своем сегменте. Это программное обеспечение сочетает в себе три черты, которые вывели его на первые позиции, а именно:

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

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

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

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

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

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

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

что это, как работает и почему лучше других брокеров сообщений

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

Давайте посмотрим, что такое Apache Kafka, как он работает и кому пригодится.

Нервная система бэкенда: зачем нужен Apache Kafka

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

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

Но таким распределенным системам нужно как-то передавать данные между собой. В этом месте на сцене появляются системы обмена сообщениями (брокеры сообщений, диспетчеры сообщений). Это некая разветвленная система труб, в которую с одного конца можно бросить, например, контейнер с сообщениями, а с другого конца его кто-то получит и прочитает. К таким системам относят и Apache Kafka.

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

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

Почему установка Apache Kafka — лучший выбор

Как и любая дополнительная система, механизм обмена сообщениями добавляет сложности и создает ряд дополнительных проблем в обслуживании вашего приложения:

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

Для устранения этих проблем и был создан Apache Kafka — сверхнадежная сверхмасштабируемая сверхгибкая система обмена сообщениями внутри бэкенд-приложений.

Описание Apache Kafka

Брокер сообщений Kafka — распределенная система. Его серверы объединяются в кластеры. Хранение и пересылка сообщений идет параллельно на разных серверах, а это дает большую надежность и отказоустойчивость. Даже при выходе из строя нескольких машин, сообщения все еще будут пересылаться и обрабатываться.

Также сервис легко масштабируется горизонтально. То есть, для наращивания мощности Apache Kafka достаточно вводить в строй дополнительные серверы. Это самый простой в реализации способ масштабирования систем, но подходит он не для всех. Например, с базами данных такой подход не работает — непонятно, что делать с записями в таблицах на новых серверах. Kafka же изначально заточен под взрывной рост производительности.

Еще один плюс — консистентность данных. Записи в Apache Kafka хранятся в виде журнала коммитов. Это выглядит как очередь сообщений, в которую можно добавлять записи, а вот удалять или модицифировать — нет. Такой подход дает огромную надежность и простоту изменения любых состояний — всегда понятно, что, как и в какой последовательности менялось.

Перечисленные пункты — это, разумеется, далеко не все, чем хорош Apache Kafka. Есть еще хранение сообщений на диске, репликация, роутинг данных по куче параметров и десятки других полезных примочек.

Apache Kafka: обзор возможностей

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

Самый очевидный подход — для связи микросервисов между собой. Сделал действие, послал сообщение другим сервисам — все, молодец. Или подписался на обновления от других частей системы и потихоньку на них реагируешь.
Организация потоков данных. Допустим, у вас идет постоянный стрим каких-то событий, их нужно передавать по цепочке и на каждом этапе что-то с ними делать. Apache Kafka идеально реализует этот сценарий с помощью грамотной организации роутинга сообщений.
Агрегация записей. В Apache Kafka можно писать данные куда быстрее, чем в обычную базу данных. Это значит, что с помощью сообщений можно организовать сбор кучи метрик, считать от них, например, средние, и уже эти значения писать в БД.
Сбор логов. Apache Kafka дает возможность хранить сообщения в течение определенного времени. Это значит, что сообщения можно использовать для кратковременного (часы/сутки) хранения логов. Это позволяет разгрузить БД и медленные системы логирования.

Зачем разработчикам нужен Apache Spark

Зачем используется Apache Spark? В статье рассмотрим, какую проблему обработки больших объёмов данных решает этот фреймворк.

Данные повсюду вокруг нас. В IDC оценили размер «цифровой вселенной» в 4,4 зеттабайта (1 триллион гигабайт) в 2013 году. По наблюдениям, цифровая вселенная ежегодно увеличивается на 40%. К 2020 году IDC ожидает, что размер достигнет 44 зеттабайтов – хватит по одному биту данных на каждую звезду физической вселенной.

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

Чтобы продемонстрировать полезность Spark, начнём с примера. 500 ГБ выборочных данных о погоде включают:

Страна | Город | Дата | Температура

Для расчёта максимальной температуры по стране для этих данных начинаем с нативной программы на Java, поскольку Java – наш второй любимый язык программирования:

Решение на Java

Однако при размере 500 ГБ даже такая простая задача займёт 5 часов с использованием этого нативного Java-метода.

«Java отстой, напишу это на Ruby и круто, если быстро, Ruby – мой любимый»

Решение на Ruby

Однако любимый Ruby больше не подходит для этой задачи. Ввод-вывод – не сильная сторона Ruby, поэтому Ruby потребуется ещё больше времени на поиск максимальной температуры, чем Java.

Задачу поиска максимальной температуры по городам лучше решить с помощью Apache MapReduce (держим пари, вы подумали, что скажем Spark). Конкретно здесь MapReduce блистает. С преобразованием городов в ключи, а температур – в значения, получаем результаты за гораздо меньшее время — 15 минут, по сравнению с предыдущими 5+ часами в Java.

MaxTemperatureMapper MaxTemperatureReducer

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

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

Что, если вместо максимальной температуры, нас попросят найти максимальную температуру по стране и городу, а потом разбить по дням? Что, если мы перепутали, и нужно найти страну с самыми высокими средними температурами? Или, если хотим найти среду обитания, где температура никогда не ниже 15°C и не выше 20°C (Антананариву, Мадагаскар, кажется привлекательной).

MapReduce справляется с пакетной обработкой данных. Однако отстаёт, когда дело доходит до повторного анализа и небольших циклов обратной связи. Единственный способ повторно использовать данные между вычислениями – записать их во внешнюю систему хранения (например, HDFS). MapReduce записывает содержимое всех Map для каждого задания – до Reduce-шага. Это означает, что каждое MapReduce-задание выполнит одну задачу, которая определена в его начале.

Для выполнения упомянутого выше анализа потребовалось бы три отдельных задания MapReduce:

MaxTemperatureMapper, MaxTemperatureReducer, MaxTemperatureRunner
MaxTemperatureByCityMapper, MaxTemperatureByCityReducer, MaxTemperatureByCityRunner
MaxTemperatureByCityByDayMapper, MaxTemperatureByCityByDayReducer, MaxTemperatureByCityByDayRunner.

Очевидно, что это легко выйдет из-под контроля.

Обмен данными в MapReduce происходит медленно из-за самой природы распределённых файловых систем: репликации, сериализации и, главное, дискового ввода-вывода. Приложения MapReduce тратят до 90% времени на чтение и запись с диска.

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

Spark решает эту проблему. Spark обрабатывает несколько запросов быстро и с минимальными издержками.

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

Spark-реализация MaxTemperaMapper с использованием RDD

Spark ещё и выполняет обработку в 10 раз быстрее, чем MapReduce, при сопоставимых задачах, поскольку Spark работает только в оперативной памяти. Поэтому не используются операции записи и чтения с диска, как правило, медленные и дорогостоящие.

Apache Spark – удивительно мощный инструмент для анализа и преобразования данных. Если эта публикация пробудила в вас интерес, следите за обновлениями. Скоро будем постепенно углубляться в тонкости Apache Spark Framework.

Оригинал

Apache Kafka и миллионы сообщений в секунду / Блог компании Tinkoff / Хабр

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

Зачем нам это?

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

Чтобы все работало, нам необходимо осуществлять обмен данными между разными приложениями. Причем обмен должен происходить достаточно быстро и без потерь, ведь, в конечном счете, это выливается в эффективность подбора персонала.

Для решения этой задачи нам предстояло выбрать среди нескольких доступных на рынке брокеров сообщений, и мы остановились на Apache Kafka. Почему? Потому что она быстрая и поддерживает семантику гарантированно единственной доставки сообщения (exactly-once semantic). В нашей системе важно, чтобы в случае отказа сообщения все равно доставлялись, и при этом не дублировали бы друг друга.

Как все устроено

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

Для Apache Kafka все сообщения – это логи. Они передаются от производителей (producer) к потребителям (consumer) через кластер Apache Kafka. Вы можете адаптировать кластер Apache Kafka под свои задачи для повышения производительности. Помимо изменения настроек брокеров (машин в кластере), настройки можно менять у производителей и потребителей. В статье пойдет речь об оптимизации только производителей.

Есть несколько важных концепций, которые нужно понять, чтобы знать, что и зачем “тюнить”:

Нет потребителей — скорость падает

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

Чем больше размер сообщения, тем выше пропускная способность

Факт, что гораздо “легче” записать на диск 1 файл размером в 100 байт, чем 100 файлов в 1 байт. А ведь Apache Kafka при необходимости скидывает сообщения на диск. Интересный график с сайта Linkedin:

Новые производители/потребители почти линейно увеличивают производительность

Но не забываем о пункте №1.

Асинхронное реплицирование может потерять ваши данные

В отличие от синхронного механизма реплицирования, при асинхронном главная нода Apache Kafka не дожидается подтверждения получения сообщения от дочерних нод. И при сбое мастер-ноды данные могут быть утеряны. Так что надо решать – или скорость, или живучесть.

Про параметры производителей

Вот основные параметры конфигурации производителей, которые влияют на их работу:

Batch.size

Размер пакета сообщений, который отправляется от производителя к брокеру. Производители умеют собирать эти “паки“, чтобы не отправлять сообщения по одному, т.к. они могут быть достаточно маленькими. В общем случае, чем больше этот параметр, тем:
- (Плюс) Больше степень сжатия, а значит выше пропускная способность.
- (Минус) Больше задержка в общем случае.

Linger.ms

По умолчанию равно 0. Обычно продюсер начинает собирать следующий пакет сообщений сразу после того, как отправляет предыдущий. Параметр linger.ms говорит продюсеру, сколько нужно подождать времени, начиная с предыдущей отправки пакета и до следующего момента комплектации нового пакета (batch) сообщений.

Compression.type

Алгоритм для сжатия сообщений (lzip, gzip, и т.д). Этот параметр сильно влияет на задержку.

Max.in.flight.requests.per.connection

Если этот параметр больше 1, то мы находимся в так называемом режиме “трубы” (“pipeline”). Вот к чему это ведет в общем случае
- (Плюс) Более хорошую пропускную способность.
- (Минус) Возможность нарушения порядка сообщений в случае отказа.

Acks

Влияет на “живучесть” сообщений в случае отказа чего-либо. Может принимать четыре параметра: -1, 0, 1, all (то же самое, что -1). В таблице ниже сведения о том, как и на что он влияет:

Как выжать максимум

Итак, вы хотите подкрутить параметры производителя и тем самым ускорить систему. Под ускорением понимается увеличение пропускной способности и уменьшение задержки. При этом должна сохраниться “живучесть” и порядок сообщений в случае отказа.

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

Понять в чем “затык” можно с помощью файла bin\windows\kafka-producer-perf-test.bat. Это достаточно гибкий инструмент для профилирования Apache Kafka, и для построения графиков я использовал именно его. А если его пропатчить (git pull github.com/becketqin/kafka KAFKA-3554), в нем можно выставлять два дополнительных параметра: —num-threads (кол-во потоков производителей) и —value-bound (диапазон случайных чисел для нагрузки компрессора).

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

Найти оптимальный размер пакета (batch.size).

Увеличить кол-во производителей и кол-во разделов в топике (partitions).

Мы воспроизвели это все у себя. И вот что получилось:

Как видно, при увеличении дефолтного размера пакета сообщений, увеличивается пропускная способность и уменьшается задержка. Но всему есть предел. В моем случае, когда размер пакета перевалил за 200 КБ, функция почти “легла”:

Другим вариантом является увеличение количества разделов в топике при одновременном увеличении количества потоков. Проведем те же тесты, но с уже 16 разделами в топике и 3-мя разными величинами –num-threads (теоретически это должно повысить эффективность):

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

Заключение

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

Список использованной литературы

Официальный сайт Apache Kafka

Статья о производительности Apache Kafka

Презентация о производительности от главного инженера LinkedIn

Apache Maven — основы / Хабр

После публикации топика о Maven в комментариях возникли вопросы о том, как начать с ним работать, с чего начать, как составлять файлы pom.xml, откуда брать плагины и т.п. Данный топик будет своего рода getting started или f.a.q.

Как в любой системе, в Maven, есть свой набор терминов и понятий.

Вся структура проекта описывается в файле pom.xml (POM – Project Object Model), который должен находиться в корневой папке проекта. Ключевым понятием Maven является артефакт — это, по сути, любая библиотека, хранящаяся в репозитории. Это может быть какая-то зависимость или плагин.

Зависимости — это те библиотеки, которые непосредственно используются в вашем проекте для компиляции кода или его тестирования.

Плагины же используются самим Maven’ом при сборке проекта или для каких-то других целей (деплоймент, создание файлов проекта для Eclipse и др.).

В самом начале работы с Maven, пользователь непременно столкнется с таким понятием как архетип. Архетип — это некая стандартная компоновка файлов и каталогов в проектах различного рода (веб, swing-проекты и прочие). Другими словами, Maven знает, как обычно строятся проекты и в соответствии с архетипом создает структуру каталогов.

Как правило, название артефакта состоит из названия группы, собственного названия и версии. К примеру Spring будет иметь вот такое название в среде Maven: org.springframework.spring:2.5.5. Последний домен означает всегда artifactId, все, что перед ним – groupId – хорошо это запомните!

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

Последнюю версию всегда можно скачать на странице загрузки на официальном сайте. Просто распаковываем архив в любую директорию. Далее необходимо создать переменную в Path, в которой необходимо указать путь к Maven. Заходим в Win + Pause – Дополнительно – Переменные среды – в верхнем окошке нажимаем Создать, вводим имя M2_HOME и значение допустим “C:\apache-maven-2.2.1”. Далее там же создаем еще одну переменную M2 со значением %M2_HOME%\bin. Так же убеждаемся, что есть переменная JAVA_HOME с путем к JDK. Ее значение должно быть примерно таким «c:\Program Files\Java\jdk1.6.0_10\». И наконец в том же окошке создаем/модифицируем переменную Path, в нее необходимо просто написать %M2%, чтобы наша папочка с исполняемым файлом Maven была видна из командной строки. Теперь необходимо проверить работоспособность нашей установки. Для этого заходим в командную строку и вводим команду

   mvn –version

Должна появиться информация о версиях Maven, jre и операционной системе, что-то вроде:


   Maven version: 2.2.1
   Java version: 1.6.0_10
   OS name: "windows 2003" version: "5.2" arch: "x86" Family: "windows"

Maven создаст вам локальный репозиторий в вашей личной папке, например в каталоге C:\Documents and Settings\username\.m2\repository

Все, Maven готов к работе, можно приступать к созданию приложения.

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

Итак, допустим нас интересует веб-приложение – находим подходящий архетип, называется он maven-archetype-webapp. В командной строке, в необходимом каталоге выполняем команду Maven:

   mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-webapp 
      -DarchetypeArtifactId=maven-archetype-webapp

Теперь мы можем лицезреть довольно наглядную структуру каталогов с говорящими названиями java – здесь будут ваши классы, webapp – здесь размещаются странички веб-приложения, resources – различного рода ресурсы в classpath (файлы конфигурации, например), test – юнит-тесты, соответственно и т.п.
Здесь все просто – выполняем команду

   mvn package

или

   mvn install

в корневом каталоге приложения, там, где находится файл pom.xml. Первая команда скомпилирует ваш проект и поместит его в папку target, а вторая еще и положит его к вам в локальный репозиторий.

Есть полезная функция, наподобие конвеера, то есть можно написать

   mvn clean install

и Maven сначала очистит папку target проекта, потом соберет его и положит в репозиторий.

Минимальный набор действий для работы Maven мы изучили, теперь переходим к кастомизации и добавлению зависимостей проекта.

Как правило, большинство популярных библиотек находятся в центральном репозитории, поэтому их можно прописывать сразу в раздел dependencies вашего pom-файла. Например чтобы подключить Spring Framework необходимо определить следующую зависимость:


   <dependencies>
      ...
      <dependency>
         <groupId>org.springframework</groupId>
         <artifactId>spring</artifactId>
         <version>2.5.5</version>
      </dependency>
   </dependencies>

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

Специфические вещи обычно не находятся в центральном репозитории и тогда вам придется указать репозиторий производителя вручную. Для примера добавим зависимость JSF-фреймворка ajax-компонентов JBoss RichFaces.

С зависимостями все просто:


   <dependencies>
      <dependency>
         <groupId>org.richfaces.ui</groupId>
         <artifactId>richfaces-ui</artifactId>
         <version>3.3.1.GA</version>
      </dependency>        
   </dependencies>

А вот репозиторий JBoss теперь необходимо прописать ручками либо в файле settings.xml, который лежит в корне вашего локального репозитория, либо в самом файле pom.xml, в зависимости от того, нужен ли данный репозиторий во всех проектах, либо в каком-то одном конкретном, соответственно:


   <!-- JBoss RichFaces Repository -->
   <repositories>
      <repository>
         <releases>
            <enabled>true</enabled>
         </releases>
         <snapshots>
            <enabled>false</enabled>
            <updatePolicy>never</updatePolicy>
         </snapshots>
         <id>repository.jboss.com</id>
         <name>Jboss Repository for Maven</name>
         <url>
            http://repository.jboss.com/maven2/
         </url>
         <layout>default</layout>
      </repository>
   </repositories>

Как правило на сайтах крупных проектов пишут всю информацию, необходимую для встраивания их библиотеки в проект на основе Maven, но бывают случаи, когда артефакт приходится искать очень и очень долго. Здесь нам очень сильно может помочь MVNrepository.com — он вам всегда подскажет где может находиться искомая библиотечка. Но если уж и там не нашлось, то из собственного опыта могу посоветовать гуглить «<название библиотеки> pom.xml». Бывает так, что проекты уже давно закрыты и в репозитории не положены потому что разработчики уже не заботятся об их распространении. Тогда остается один единственный способ – добавить файл в репозиторий вручную командой:


   mvn install:install-file
     -Dfile=<path-to-file>
     -DgroupId=<group-id>
     -DartifactId=<artifact-id>
     -Dversion=<version>
     -Dpackaging=<packaging>

Последний параметр чаще всего имеет значение jar.
Так как плагины являются такими же артефактами, как и зависимости, то они описываются практически так же. Вместо раздела dependencies – plugins, dependency – plugin, repositories – pluginRepositories, repository – pluginRepository.

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

Посмотрим как настроить плагин для создания проекта для Eclipse с использованием WTP ver. 2.0. В раздел plugins нашего pom.xml прописываем следующий плагин:

        
   <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-eclipse-plugin</artifactId>
      <configuration>
         <wtpversion>2.0</wtpversion>
      </configuration>
   </plugin>

Теперь идем опять таки в командную строку и выполняем команду

   mvn eclipse:eclipse

Ждем пока Maven найдет все библиотеки в репозитории или скачает их и вуаля – теперь наш Maven-проект можно открыть как проект eclipse. При этом библиотеки никуда не копируются как при классическом подходе, а остаются в репозитории и Eclipse делает на них ссылку через свои переменные.

Единого списка всех плагинов естественно не существует, на официальном сайте только есть поддерживаемые плагины непосредственно разработчиками Maven. Однако хотелось бы отметить, что названия плагинов довольно прямолинейны и сделав поиск по ключевым словам «maven tomcat plugin» вы скорее всего обнаружите первой ссылкой плагин для деплоймента проекта в Tomcat.

К сожалению сам не имею большого опыта настройки репозитория, но могу посоветовать как наиболее простой и распространенный Nexus. За дополнительной информацией следует обратиться на сайт данного проекта.

Однако нельзя оставить без внимания и достойных конкурентов в лице Artifactory и Archiva.

Очень надеюсь, что цель данной статьи достигнута – минимальных знаний по Maven должно хватить на работу с не очень большими проектами. Для более серьезных целей очень советую детально изучить maven-compiler-plugin и maven-resource-plugin – они напрямую отвечают за конечную компоновку проекта. Я считаю, что самым главным моментом в обучении Maven является понимание идеологии – Maven описывает конечную структуру проекта, а не пути к ее достижению, в отличие от Ant.

Полезные ссылки
Официальная страница Maven
Документация
Центральный репозиторий
Репозиторий iBiblio
Поиск артефактов по названию
Неплохой форум по Maven
Maven: The Definitive Guide — хорошая книга по Maven

http — Зачем мне нужен Apache HTTPD?

Переполнение стека

Около
Продукты
Для команд

Переполнение стека
Общественные вопросы и ответы
Переполнение стека для команд
Где разработчики и технологи делятся частными знаниями с коллегами
Вакансии
Программирование и связанные с ним технические возможности карьерного роста
Талант
Нанимайте технических специалистов и создавайте свой бренд работодателя
Реклама
Обратитесь к разработчикам и технологам со всего мира
О компании

javascript — Apache нужен для NodeJs?

Переполнение стека

Около
Продукты
Для команд

Переполнение стека
Общественные вопросы и ответы
Переполнение стека для команд
Где разработчики и технологи делятся частными знаниями с коллегами
Вакансии
Программирование и связанные с ним технические возможности карьерного роста
Талант
Нанимайте технических специалистов и создавайте свой бренд работодателя
Реклама
Обратитесь к разработчикам и технологам со всего мира
О компании

Загрузка…

nginx + uWSGI vs Apache — почему мы перешли.

Любимые пользователи, и все, кому это может быть интересно,

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

Мы перешли, потому что:

нам нужно динамически настраивать новые виртуальные хосты для наших пользователей
Apache не будет загружать конфигурацию динамически, ему нужно выполнить плавный перезапуск , который
все еще слишком разрушительный
единая общая конфигурация Apache, которая обрабатывает всех пользователей, становится неудобной
nginx + uwsgi значительно упростит нам создание статических файлов.
и индивидуальные настройки конфигурации
, мы также надеемся на улучшение производительности

Наш опыт был:

конечно, nginx + uwsgi намного проще настроить и многое другое
гибкий.но: —

Модель

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

К деталям!

Для тех, кто не знает, PythonAnywhere позволяет пользователям разрабатывать, а также размещать
Приложения Python, либо в нашем домене через имя пользователя.субдомен pythonanywhere.com,
или со своих собственных доменных имен. Итак, нам нужно иметь возможность динамически добавлять,
удалить и обновить конфигурации виртуального хоста. Так или иначе, наши веб-серверы
нужно посмотреть входящий запрос и, исходя из доменного имени, перенаправить
их в соответствующее приложение Python WSGI.

В Apache есть два способа сделать это: вы можете написать конфигурацию
файл для каждого пользователя и домена, или вы можете попробовать написать единую глобальную конфигурацию
файл, который может обрабатывать любой домен и указывать его на правильное приложение WSGI.В
проблема в том, что первый подход требует от вас отказываться от Apache для каждого
изменение конфигурации — нехорошо: даже если перезапуск изящно не отключает рабочих до тех пор, пока они не завершат существующие запросы, это все равно означает, что новые запросы должны ждать, пока сервер снова не запустится — мы не хотим отключать один из наших веб-серверов, даже всего на несколько секунд, каждый раз, когда регистрируется новый пользователь!

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

Конфигурация Yucky Apache

Давайте взглянем на некоторые изгибы, которые мы себе внесли
через старые времена:

  LogFormat "% {cased_username} e |% h% l% u% t \"% r \ "%> s% b \"% {Referer} i \ "\"% {User-agent} i \ "" комбинированный-vhost

LoadModule vhost_dbd_module /usr/lib/apache2/modules/mod_vhost_dbd.so
DBDExptime 5


    ServerAlias *

    FcgidMaxRequestLen 2097152

    DBDriver MySQL
    DBDParams host = mysql.server, user = django_anywhere, pass = MYSQL_PASSWORD, dbname = где угодно
    DBDocRoot "SELECT concat ('/ mnt / user_storage / webapps /', lower (имя пользователя), '/ escalate_privileges.py '), имя пользователя как cased_username из auth_user, webapps_userdomain, где auth_user.id = webapps_userdomain.user_id и webapps_userdomain.domain_name =% s "HOSTNAME

    CustomLog "| / usr / bin / python -u /home/anywhere/user_logs/splitter.py" комбинированный-vhost

    
        Заказать разрешить, запретить
        Разрешить от всех
        Параметры + ExecCGI
        AddHandler fcgid-скрипт .py

Вы видите, что там происходит?

Что ж, вы могли заметить, что мы по глупости разрешили вводить имена пользователей в смешанном регистре, и что
это доставляет массу неприятностей.К сожалению, нам просто придется отсосать
up — nginx + uwsgi нам не упростит

Далее вы можете увидеть, что нам пришлось вручную запускать скрипт под названием splitter.py , который
передает журналы доступа пользователей в их собственные файлы вместо файлов Apache по умолчанию.
Возможно, не идеально, но это работает.

Настоящая боль начинается с этих параметров DBDocRoot : мы используем mod_vhost_dbd
чтобы Apache проверял базу данных для каждого запроса , чтобы вычислить
узнать, в какой файл Python WSGI его отправить.ай.

Но это еще не все — escalate_privileges.py намекает на новый мир
некрасиво.

Танец escalate_privileges

  #! / Usr / bin / python
# Copyright (c) 2012 Resolver Systems Ltd.
# Все права защищены
#

импорт ОС
импорт pwd
импортный сигнал
подпроцесс импорта
import sys

fromwhere.jails.spawn импорт spawn_unpiped_chrooted_process


def get_username_from_filename ():
    lowercase_username = os.path.basename (os.path.dirname (__ file__))
    для pwd_rec в pwd.getpwall ():
        если pwd_rec.pw_name.lower () == lowercase_username:
            вернуть pwd_rec.pw_name
    поднять исключение ("Нет такого пользователя% r"% (lowercase_username,))


def get_signal_handler (pid):
    обработчик def (signum, _):
        subprocess.call (['/ usr / bin / sudo', '/ bin / kill', str (pid)])
    обработчик возврата


def main ():
    имя пользователя = получить_имя_пользователя_from_filename ()
    process = spawn_unpiped_chrooted_process (
        '/ usr / bin / python /bin/serve_wsgi.py% s% s'% (имя пользователя, "" .join (sys.argv [1:])),
        имя пользователя
    )

    handler = get_signal_handler (process.pid)
    signal.signal (signal.SIGUSR1, обработчик)
    signal.signal (signal.SIGTERM, обработчик)
    process.wait ()


если __name__ == '__main__':
    главный()

Да, цель этого скрипта — запустить процесс, который подключается к пользовательскому
домашний каталог (и обратите внимание, что единственный способ получить имя пользователя — это прочитать
имя текущего каталога — Apache в упор отказывается делать что-либо полезное
например, установить для нас переменную окружения). Я избавлю вас от лишнего веселья
serve_wsgi.py , который предназначен только для регистрации (аналог splitter.py
из ранее). Затем мы переходим к пользовательскому приложению WSGI.

Apache нас сдерживает

Наша установка Apache работает (если она не сломалась …) на данный момент, даже если она включает
попадание в базу данных для каждого запроса, два взлома для доступа и журналов ошибок и
странный танец, связанный с передачей параметров в виде имен каталогов в
кастомный скрипт chrooting… Но даже если не брать в расчет все это, он все еще ограничивает нас
с точки зрения того, что мы можем сделать в будущем./(.*) / mnt / user_storage / homedirs /% {ENV: subdomain} / var / www / static / $ 1 [L]

Заказать разрешить, запретить
Разрешить от всех
Параметры SymLinksIfOWnerMatch

<Каталог / mnt / user_storage / homedirs>
Параметры SymLinksIfOWnerMatch

Это указывает Apache проверять каждый запрос по папке в пользовательском
личное пространство и использует mod_rewrite для возврата статических файлов из этой папки
если они существуют.Мы даже можем заставить работать символические ссылки, в крайнем случае.

Но мы не можем поддерживать настраиваемое расположение статических файлов для каждого пользователя.

Более того, mod_vhost_dbd сильно ограничивает наши возможности. Ты можешь иметь
заметил эти две строки, которые, кажется, показывают нам использование произвольной информации
извлечено из базы данных для обработки запросов:

  LogFormat "% {cased_username} e |% h% l% u% t \"% r \ "%> s% b \"% {Referer} i \ "\"% {User-agent} i \ "" комбинированный-vhost

DBDocRoot "SELECT concat ('/ mnt / user_storage / webapps /', lower (имя пользователя), '/ escalate_privileges.py '), имя пользователя как cased_username из auth_user, webapps_userdomain, где auth_user.id = webapps_userdomain.user_id и webapps_userdomain.domain_name =% s "HOSTNAME

За исключением того, что переменная % {cased_username} фактически не доступна примерно до середины выполнения запроса … к этому времени уже слишком поздно использовать ее, например, для указания настраиваемого каталога для сценария WSGI, или статические файлы…

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

Ночь живых рабочих Apache

Вот еще немного веселья. Apache часто оставлял зомби-процессы лежать
вокруг, что начнёт съедать ресурсы на сервере. Итак, у нас был
ежедневная «уборка», которая выглядела так:

  # Убить все процессы, принадлежащие пользователю, которые являются дочерними по отношению к init (т.е. не дочерними по отношению к apache или его рабочим)
python -c "import psutil; [p.kill () for p in psutil.process_iter () if p.gids.real == 60000 and p.parent.pid == 1]"
# Убить serve_wsgis, которые принадлежат пользователю root и не являются дочерними элементами apache
python -c "import psutil; [стр.kill () для p в psutil.process_iter (), если 'serve_wsgi' в '' .join (p.cmdline) и p.parent.pid == 1] "

Прекрасно.

Итак, наша конфигурация Apache мучительна и трудна для понимания. Ему нужен
попадание в базу данных для каждого запроса. Вокруг остается много зомби. А также
это мешает нам делать то, что мы хотим делать. Итак, что такое новый блестящий
что решит ВСЕ НАШИ ПРОБЛЕМЫ?

Конфигурация намного проще

Помните конфигурационный файл Apache ранее? Вот эквивалент для
nginx + uwsgi:

Конфигурация Nginx:

  сервер {
    слушать 80;
    имя_сервера ~ (? <домен>.+) $;
    место расположения / {
        корень / var / log / nginx / user_logs;
        access_log /var/log/nginx/user_logs/$domain/$domain.access.log;
        включить uwsgi_params;
        uwsgi_pass unix: / var / www / socket / $ domain / socket;
    }
}

Конфигурация uWSGI:

  [uwsgi]
uid = {{uid}}
gid = {{gid}}
chroot = / mnt / chroots / {{user.username}}

touch-reload = /var/www/wsgi.py
сокет = / var / www / socket / {{host}} / socket
chdir = / var / www

файл = /bin/user_wsgi_wrapper.py

Чуть проще, я уверен, вы согласны?

Индивидуальная конфигурация и плавные перезагрузки

Настройка uWSGI emperor + vassals означает, что любые файлы конфигурации в указанном
каталог загружается динамически без необходимости перезапуска .Добавление нового
site так же просто, как добавить новый файл и изменить существующую конфигурацию
вступает в силу, как только файл обновляется.

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

И все это без базы данных —

Статические файлы

В Apache, если нам нужны статические файлы, нам нужно будет посмотреть что-то вроде
это:

  RewriteCond / mnt / user_storage / homedirs /% {ENV: subdomain} / var / www / static% {REQUEST_URI} -f
RewriteRule ^ / (.*) / mnt / user_storage / homedirs /% {ENV: subdomain} / var / www / static / $ 1 [L]

    Заказать разрешить, запретить
    Разрешить от всех
    Параметры SymLinksIfOWnerMatch

<Каталог / mnt / user_storage / homedirs>
    Параметры SymLinksIfOWnerMatch

В нашей новой настройке это однострочное дополнение к конфигурации вассала uwsgi:

  check-static = / var / www / static

Мир боли, который я пропустил

Если все это казалось правдой, значит, так оно и есть.Помни, что я
сказал о динамической загрузке рабочих Apache, и uwsgi хочет загрузить их
все заранее? Для нас это было большим запретом, поскольку каждый веб-сервер может иметь
сотни пользователей на нем, и загрузка воркера или нескольких воркеров для каждого
сделал бы время раскрутки uwsgi и слишком медленным. Итак, вот хитрость:

  сервер {

    слушать 80;
    имя_сервера ~ (? <домен>. +) $;
    место расположения / {
        корень / var / log / nginx / user_logs;
        access_log / var / log / nginx / user_logs / $ domain / $ domain.access.log;
        error_page 502 = @fallback;
        включить uwsgi_params;
        uwsgi_pass unix: / var / www / socket / $ domain / socket;

    }
    location @fallback {
        proxy_pass https://www.pythonanywhere.com/initialize_webapp/$scheme/$domain/$uri?$query_string;
    }
}

По сути, если для определенного домена нет uwsgi worker, nginx будет
считают, что это ошибка «502 плохой шлюз», но наш запасной вариант говорит ему
вызвать API инициализации на нашем веб-сервере.

Обработчик вызова initialize_webapp выглядит примерно так (в псевдокоде):

  найти пользователя из домена
если домен не распознан: вернуть 404
построить chroot для пользователя, включая личное файловое хранилище
записать файл вассала пользователя в / etc / uwsgi / vassals
подождите, пока вассальный рабочий раскрутится
перенаправить обратно в веб-приложение пользователя

Кроме того, ведение журнала по-прежнему является проблемой, но примерно вдвое меньше
боль как было под апачем. Nginx предоставляет нам журналы доступа в виде однострочной конфигурации,
что однозначно победа (избавляемся от плевательницы .py ), но журналы ошибок все еще
нужна специальная оболочка WSGI, но это не сложнее старой
serve_wsgi.py . Для любопытных вы можете найти его в своем PythonAnywhere
песочница по адресу /bin/user_wsgi_wrapper.py

Предварительные результаты сравнительного анализа

На apache мы смотрели среднее время (в миллисекундах):

pythonanywhere.com

  Подключение: 391
Обработка: 139
Ожидание: 136
Общий: 542

пользователь webapp:

  Подключение: 365
Обработка: 532
Ожидание: 427
Общий: 921

Для стандартного статического сайта, размещенного в той же зоне Amazon, вы ожидаете около 100/100/100 в течение всего времени 200.

С nginx + uwsgi мы получили

pythonanywhere.com

  Подключение: 346
Обработка: 227
Ожидание: 226
Общий: 580

пользователь webapp:

  Подключение: 366
Обработка: 809
Ожидание: 684
Общий: 1175

Так что никаких замечательных новостей нет — фактически, это ухудшение на 10% для основного сайта и на 20% для веб-приложений пользователей. НО — это для «медианного» запроса. Что мы действительно обнаружили, так это то, что он действительно улучшил работу с более медленными запросами — другими словами, он действительно улучшил согласованность производительности:

Apache — пользовательские тесты веб-приложений:

  Время на пробы: 191.538 секунд
Процент запросов, обслуженных за определенное время (мс)
  50% 921
  66% 1799
  75% 1918
  80% 2746
  90% 3853
  95% 5950
  98% 9989
  99% 11979
 100% 17177 (самый длинный запрос)

Nginx / uWSGI —

  Время, затраченное на тесты: 61,882 секунды
Процент запросов, обслуженных за определенное время (мс)
  50% 580
  66% 602
  75% 618
  80% 630
  90% 712
  95% 908
  98% 1067
  99% 1151
 100% 2473 (самый длинный запрос)

Итак, под Apache самые медленные 20% запросов занимали от 3 до 10 раз больше, чем средний запрос.В nginx самые медленные 20% запросов не намного медленнее медианы. Так что это определенно победа — сайт и веб-приложения наших пользователей должны быть более надежными и последовательными.

Итак, вот история nginx + uwsgi vs apache. Есть мысли, поделились опытом? Вы знаете все об Apache и хотите рассказать нам, почему мы должны были придерживаться этого? Вы большой поклонник nginx или uWSGI и хотите получить удовольствие от всех других интересных вещей, которые мы могли бы делать? Дайте нам знать!

Апрель 2024
Пн	Вт	Ср	Чт	Пт	Сб	Вс
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

Apache зачем нужен: Apache — ? Apache. FreeHost

Что такое веб-сервер Apache и как им пользоваться 🍂

Что это такое

История создания

Достоинства и недостатки Apache

Плюсы

Минусы

Как устроен Apache

Архитектура

Ядро

Модульная система

Конфигурация

Виртуальные хосты

Альтернативы Apache

NGINX

Lighttpd

Microsoft IIS

Tomcat

Заключение

Apache vs Nginx: практический взгляд / Хабр

Введение

Общий обзор

Apache

Nginx

Архитектура обработки соединений

Apache

Nginx

Статический и динамический контент

Apache

Nginx

Распределенная конфигурация против централизованной

Apache

Nginx

Интерпретация базирующаяся на файлах и URI

Apache

Nginx

Модули

Apache

Nginx

Поддержка, совместимость, экосистема и документация

Apache

Nginx

Совместное использование Apache и Nginx

Заключение

Веб сервер Apache (Web Апач) ➡ что это, как работает и какие у него преимущества

Веб-сервер Apache – что это?

Преимущества веб-сервера Апач

Недостатки сервера Апач

Ядро веб-сервера Апач

Конфигурация web-сервера Apache

Доступные варианты многопроцессорных моделей (MPM)

Модули

Виртуальный хосты для серверов Апач

Локальный сервер Apache

Работа с разными языками программирования

Безопасность сервера Apache

Региональные настройки для Apache

Вывод

что это, как работает и почему лучше других брокеров сообщений

Нервная система бэкенда: зачем нужен Apache Kafka

Почему установка Apache Kafka — лучший выбор

Описание Apache Kafka

Apache Kafka: обзор возможностей

Зачем разработчикам нужен Apache Spark

Apache Kafka и миллионы сообщений в секунду / Блог компании Tinkoff / Хабр

Зачем нам это?

Как все устроено

Нет потребителей — скорость падает

Чем больше размер сообщения, тем выше пропускная способность

Новые производители/потребители почти линейно увеличивают производительность

Асинхронное реплицирование может потерять ваши данные

Про параметры производителей

Как выжать максимум

Заключение

Список использованной литературы

Apache Maven — основы / Хабр

http — Зачем мне нужен Apache HTTPD?

javascript — Apache нужен для NodeJs?

nginx + uWSGI vs Apache — почему мы перешли.

Конфигурация Yucky Apache