Perl - самый быстрый способ написать страницу с высокой производительностью?

Question

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

Мне интересно, лучше ли Perl писать высокопроизводительную веб-страницу?Я знаю, что при использовании Apache или IIS будет много накладных расходов?

Есть идеи, книги, статьи, учебные пособия?

Answer 1

Я собираюсь предположить, что под «высокой производительностью» вы подразумеваете как реальное время, затрачиваемое на создание страницы, так и количество, которое она может обслуживать одновременно.

Язык программирования не так важенкак ваши серверы и алгоритмы.Возможно, вы захотите взглянуть на Проблема C10k , которая представляет собой серию новых технологий и усовершенствованных методов с целью позволить одному веб-серверу одновременно обрабатывать более 10 000 одновременных подключений.Такие вещи, как Nginx и lighttpd веб-серверы и лак кэш-память вышли из этого проекта.

Большие победы происходят от использования очень легкого,очень быстрый, очень модульный веб-сервер (Apache и IIS не так) с очень легким, очень быстрым кешем перед ним, чтобы избежать необходимости обрабатывать одно и то же дважды.Для сервера с высоким уровнем параллелизма даже кэширование на несколько секунд может сэкономить сотни или тысячи процессов.Разбивая статическую страницу на последовательность запросов AJAX, вы можете кэшировать больше статических битов и кусочков независимо от часто меняющихся битов.

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

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

Answer 2

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

Answer 3

Пока вы не используете интерфейс CGI [1] для общения с веб-сервером, язык не окажет заметного влияния на производительность в 99% случаев.Исключения составляют те, в которых вы выполняете тяжелую внутреннюю обработку, а не просто извлекаете что-то из базы данных, слегка массируете это и отправляете это пользователю - и, если вы делаете такие вещи, вы 'Вероятно, лучше делать это асинхронно, если это возможно, и помещать результаты в базу данных для легкого массажа и последующего просмотра.

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

[1] Обратите внимание, что я говорю здесь о ванильной CGI "запускай новый процесс для обслуживания каждого входящего запроса", не модуль Perl CGI (CGI.pm / use CGI).Существуют способы use CGI, в которых также используется долгоживущий процесс, который обрабатывает несколько запросов в течение всего времени его жизни.

Answer 4

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

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

Предположим, что каждая порция была максимально быстрой. Это уж точно фантастика, но все равно подумай. Теперь, когда все максимально быстро, оцените каждую часть в соответствии с тем, насколько они быстры. Какая самая медленная часть? Это доступ к диску? Сетевой ввод-вывод? Наличие розетки?

Если вы не в той точке, где уже думаете об этом, язык, вероятно, не так важен, как ваш навык.

Есть много книг по веб-производительности. :)

Answer 5

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

Но выбор языка - это не первое, что вы должны сделать, если только вы не планируете писать все с нуля.

Вам следует выбрать набор инструментов.

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

Если вы не можете найти хорошее соответствие в существующих приложениях, посмотрите на различные фреймворки: Catalyst, Rails, Squatting, Camping, Jifty, Django, хороший список из них в Википедии .

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

Answer 6

Я не верю, что это будет быстрее, чем другие распространенные варианты, такие как PHP, Python, Ruby, Java или C #.

Answer 7

Этот пост о сбое сервера предполагает, что вы можете написать модуль расширения в nginx для обслуживания динамического контента.

Такие модули должны быть скомпилированы с собственным машинным кодом, поэтому, скорее всего, они быстрее, чем работают на Perl.