Некоторые фундаментальные, но важные вопросы о веб-разработке?

Update, Spring 2018:

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

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

1. Зависит от веб-сервера (а иногда и от его конфигурации). Описание различных моделей:

• Apache с mpm_prefork (по умолчанию на unix): Обработка каждого запроса. Чтобы свести к минимуму время запуска, Apache держит пул простаивающих процессов, ожидающих обработку новых запросов (размер которых вы настраиваете). При поступлении нового запроса главный процесс делегирует его доступному рабочему, в противном случае порождает новый. Если поступит 100 запросов, если только у вас не будет 100 незанятых рабочих, то для обработки нагрузки потребуется некоторое раздвоение. Если количество незадействованных процессов превысит значение MaxSpare, то некоторые из них после завершения запросов будут возвращены до тех пор, пока не появится только столько незадействованных процессов.

• Apache с mpm_event, mpm_worker, mpm_winnt: Поток на запрос. Аналогично, в большинстве ситуаций apache держит пул простаивающих потоков, также настраиваемых. (Небольшая деталь, но функционально та же: mpm_worker запускает несколько процессов, каждый из которых многопоточный).

• Nginx/Lighttpd: Это легковесные серверы, основанные на событиях, которые используют select()/epoll()/poll() для мультиплексирования нескольких сокетов без необходимости использования нескольких потоков или процессов. Благодаря очень тщательному кодированию и использованию неблокирующих API, они могут масштабироваться до тысяч одновременных запросов на товарном оборудовании, обеспечивая доступную полосу пропускания и правильно сконфигурированные ограничения файлово-скрипторов. Предупреждение заключается в том, что реализация традиционных встроенных языков сценариев практически невозможна в контексте сервера, это сведет на нет большинство преимуществ. Оба языка поддерживают FastCGI, однако, для внешних языков сценариев.

2. Зависит от языка, или на некоторых языках, на которых вы используете модель развертывания. Некоторые серверные конфигурации допускают только определенные модели развертывания.

• Apache mod_php, mod_perl, mod_python: Эти модули запускают отдельный интерпретатор для каждого работника apache. Большинство из них не могут очень хорошо работать с mpm_worker (из-за различных проблем с безопасностью потоков в клиентском коде), поэтому они в основном ограничиваются форкингом моделей. Это означает, что для каждого процесса apache у вас внутри запущен интерпретатор php/perl/python. Это сильно увеличивает объем памяти: если заданный работник apache обычно занимает около 4 Мб памяти на вашей системе, то один с PHP может занять 15 Мб, а другой с Python может занять 20-40 Мб для среднего приложения. Частично это будет разделяемая память между процессами, но в целом эти модели очень трудно масштабировать очень большие.

• Apache (поддерживаемые конфигурации), Lighttpd, CGI: Это, в основном, метод вымирания хостинга. Проблема с CGI в том, что вы не только форкируете новый процесс для обработки запросов, но и делаете это для -всегда-запроса, а не только тогда, когда нужно увеличить нагрузку. С динамическими языками сегодня, имеющими достаточно большое время запуска, это создает не только много работы для вашего веб-сервера, но и значительно увеличивает время загрузки страницы. Небольшой perl скрипт может быть хорош для запуска в качестве CGI, но большой питон, рубин, или java приложение является довольно громоздким. В случае с Java, вы можете ждать секунду или больше только для запуска приложения, только для того, чтобы сделать все это снова при следующем запросе.

• Все веб-серверы, FastCGI/SCGI/AJP: Это "внешняя" хостинговая модель работающего динамического языка. Есть целый список интересных вариаций, но суть в том, что ваше приложение прослушивает какой-то сокет, а веб-сервер обрабатывает HTTP-запрос, затем посылает его по другому протоколу в сокет, только для динамических страниц (статические страницы обычно обрабатываются непосредственно веб-сервером).

  Это дает много преимуществ, потому что вам понадобится меньше динамических работников, чем вам нужна возможность обрабатывать соединения. Если на каждые 100 запросов половина приходится на статические файлы, такие как образы, CSS и т.д., и более того, если большинство динамических запросов короткие, то вы сможете справиться с 20 динамическими работниками, обрабатывающими 100 одновременных клиентов. То есть, так как обычное использование данного веб-сервера поддерживает соединение на 80% в режиме ожидания, ваши динамические переводчики могут обрабатывать запросы от других клиентов. Это намного лучше, чем подход mod_php/python/perl, когда, когда ваш пользователь загружает CSS файл или вообще ничего не загружает, ваш интерпретатор сидит там, используя память и не выполняя никакой работы.

• Apache mod_wsgi: Особенно это относится к хостингу python, но использует некоторые преимущества хостинга приложений на веб-сервере (простая настройка) и внешнего хостинга (процесс мультиплексирования). Когда вы запускаете его в демоническом режиме, mod_wsgi только делегирует запросы рабочим демона, когда это необходимо, и, таким образом, 4 демона могут справиться со 100 одновременными пользователями (зависит от вашего сайта и его загрузки)

• Phusion Passenger: Пассажир - это система хостинга apache, которая в основном предназначена для хостинга рубиновых приложений, и подобно mod_wsgi предоставляет преимущества как внешнего хостинга, так и хостинга, управляемого веб-сервером.

3. Опять же, я разобью вопрос на модели хостинга, для которых это применимо.

• mod_phpp, mod_python, mod_perl: Обычно только C-библиотеки вашего приложения будут разделены между работниками apache. Это связано с тем, что apache сначала вилки, а затем загружает ваш динамический код (который из-за тонкостей, в основном, не может использовать разделяемые страницы). Интерпретаторы не общаются друг с другом в рамках этой модели. Глобальные переменные обычно не являются общими. В случае с mod_python, между запросами внутри процесса могут оставаться глобулы, но не между процессами. Это может привести к очень странному поведению (браузеры редко поддерживают одно и то же соединение навсегда, а большинство из них открыты для определенного сайта), поэтому будьте очень осторожны с тем, как вы используете глобулы. Используйте что-нибудь вроде memcached или базы данных или файлов для хранения сеансов и других битов кэша, которые необходимо совместно использовать.

• FastCGI/SCGI/AJP/Proxied HTTP: Так как ваше приложение по сути является сервером само по себе, это зависит от языка, на котором написан сервер (обычно это тот же язык, на котором написан ваш код, но не всегда) и от различных факторов. Например, большинство Java-приложений используют thread-per-request. Python и его "flup" библиотека FastCGI могут работать как в префорковом, так и в потоковом режиме, но так как Python и его GIL ограничены, вы, скорее всего, получите наилучшую производительность от префорковки.

• mod_wsgi/passenger: mod_wsgi в серверном режиме может быть настроен на то, как он работает, но я бы порекомендовал дать ему исправленное количество процессов. Вы хотите сохранить свой питоновый код в памяти, запустить его и быть готовым к работе. Это лучший подход к поддержанию латентности предсказуемой и низкой.

Почти во всех моделях, упомянутых выше, время жизни процесса/потока больше, чем один запрос. Большинство установок следуют некоторым вариациям в модели apache: Держите вокруг себя запасных рабочих, при необходимости порождайте больше, пожинайте, когда их слишком много, основываясь на нескольких настраиваемых ограничениях. Большинство из этих установок -do not - уничтожают процесс после запроса, хотя некоторые из них могут очистить код приложения (например, в случае PHP fastcgi).

4. Если вы говорите "веб-сервер может обрабатывать только 100 запросов", то это зависит от того, имеете ли вы в виду сам веб-сервер или динамическую часть веб-сервера. Существует также разница между фактическими и функциональными ограничениями.

В случае с Apache, например, Вы сконфигурируете максимальное количество рабочих мест (соединений). Если это количество соединений было 100 и было достигнуто, то никакие соединения не будут приниматься apache'ом до тех пор, пока кто-нибудь не отключится. При включенной функции keep-alive эти 100 соединений могут оставаться открытыми долгое время, гораздо дольше, чем один запрос, а те 900 человек, которые ожидают запросы, скорее всего, перестанут работать.

Если у вас есть достаточно высокие ограничения, вы можете принять всех этих пользователей. Однако, даже при самом легком apache, его стоимость составляет около 2-3мб на одного работника, так что при использовании только apache вы можете говорить о 3gb+ памяти только для обработки соединений, не говоря уже о других, возможно, ограниченных ресурсах операционной системы, таких как идентификаторы процессов, файловые дескрипторы и буферы, и это до того, как рассматривать код вашего приложения.

Для Lighttpd/Nginx они могут обрабатывать большое количество соединений (тысячи) в крошечной области памяти, часто всего несколько мега на тысячу соединений (зависит от таких факторов, как буферы и то, как асинхронизируется IO apis). Если мы будем исходить из того, что большинство ваших соединений работают в режиме keep-alive и 80% (или более) простаивают, это очень хорошо, так как вы не тратите впустую время динамического процесса или много памяти.

В любой модели внешнего хоста (mod_wsgi/fastcgi/ajp/proxied http), скажем, что у вас всего 10 рабочих и 1000 пользователей делают запрос, ваш веб-сервер будет ставить запросы в очередь к вашим динамическим рабочим. Это идеальный вариант: если ваши запросы вернутся быстро, вы сможете продолжать обрабатывать гораздо большую пользовательскую нагрузку без необходимости в большем количестве рабочих. Обычно премией являются соединения с памятью или БД, и ставя в очередь, Вы можете обслуживать гораздо больше пользователей с теми же самыми ресурсами, а не отказывать некоторым пользователям.

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

5. Большинство людей, использующих apache, которым приходится работать с большим количеством одновременных пользователей, по причине большой занимаемой памяти, отключают keep-alive. Или Apache с включённым keep-alive, с коротким ограничением по времени keep-alive, скажем, 10 секунд (так что вы можете получить вашу первую страницу и изображения/CSS за одну загрузку страницы). Если вам действительно нужно масштабироваться до 1000 соединений и более и вы хотите использовать keep-alive, то вы захотите посмотреть на Nginx/lighttpd и другие легковесные серверы, основанные на событиях.

Можно заметить, что если вам все же нужен apache (для простоты использования конфигурации или для хостинга определенных настроек), то вы можете поставить Nginx перед apache, используя HTTP прокси-сервер. Это позволит Nginx обрабатывать keep-alive соединения (и, желательно, статические файлы), а apache - обрабатывать только хрюнтовую работу. Интересно, что Nginx также лучше, чем apache, при написании лог-файлов. Для производственного развертывания мы были очень довольны nginx перед apache (в данном случае с mod_wsgi). apache не ведёт логов доступа и не обрабатывает статические файлы, что позволяет нам отключать большое количество модулей внутри apache, чтобы сохранить его небольшую площадь.

Я в основном уже ответил на этот вопрос, но нет, если у вас длинное соединение, то это не имеет никакого отношения к тому, как долго работает интерпретатор (до тех пор, пока вы используете внешнее хостинговое приложение, которое к настоящему моменту должно быть понятно, значительно превосходит его). Так что, если вы хотите использовать комету и долгое соединение (что обычно хорошо, если вы можете с этим справиться), рассмотрите nginx.

Bonus FastCGI Question Вы упоминаете, что fastcgi может мультиплексироваться в пределах одного соединения. Это действительно поддерживается протоколом (по-моему, это понятие известно как "каналы"), так что теоретически один сокет может обрабатывать множество соединений. Однако, это не является обязательной функцией реализующих fastcgi, и на самом деле я не верю, что есть один сервер, который использует это. Большинство fastcgi-ответчиков также не используют эту возможность, потому что реализовать ее очень сложно. Большинство веб-серверов делают только один запрос через заданный сокет fastcgi за раз, затем следующий запрос через этот сокет. Так что вы часто имеете только один fastcgi-сокет на каждый процесс/поток

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

Что касается общего состояния, я рекомендую вам притвориться, что никаких традиционных способов использования внутрипроцессного общего состояния не существует: даже если они могут работать сейчас, вам, возможно, придется позже разделить ваших динамических работников на несколько машин. Для состояния вроде тележки и т.п.; db может быть лучшим вариантом, информация о сессии и входе в систему может храниться в securecookies, а для временного состояния что-то похожее на memcached довольно аккуратно. Чем меньше вы зависите от функций, которые совместно используют данные ("shared-nothing" подход), тем больше вы сможете масштабировать в будущем.

Postscript: Я написал и разместил множество динамических приложений во всем диапазоне настроек, описанном выше: все вебсерверы, перечисленные выше, и все в диапазоне PHP/Python/Ruby/Java. Я тщательно тестировал (используя как бенчмаркинг, так и наблюдение в реальном мире) эти методы, и результаты иногда удивляют: реже - больше. После того, как вы перестали размещать свой код на веб-сервере, вы часто можете уйти с очень небольшим количеством сотрудников FastCGI/Mongrel/mod_wsgi/etc. Это зависит от того, сколько времени ваше приложение остается в БД, но очень часто случается так, что большее количество процессов, чем 2*номер процессора, на самом деле ничего вам не даст.