Интерпретированные и скомпилированные языки для веб-сайтов (PHP, ASP, Perl, Python и т. Д.) - PullRequest
7 голосов
/ 07 октября 2009

Я строю веб-сайты на основе базы данных. Ранее я использовал Perl или PHP с MySQL.

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

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

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

Возможно ли это даже в веб-контексте? Если да, то какой разумный выбор языка был бы?

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

Ответы [ 7 ]

7 голосов
/ 07 октября 2009

То, что вы можете сделать, - это то, что делают несколько сайтов с большим трафиком (например, Facebook или Twitter), то есть записать свой алгоритм «потребления процессора» в C-плагине.

Например, вы можете написать расширение PHP , если вы планируете использовать PHP, или расширение Ruby , если вы планируете использовать Ruby / Ruby on Rails и т. Д.

Таким образом, вы можете сделать свой упорядоченный код простым и легким в обслуживании (это может быть намного сложнее обрабатывать запросы из C, а не из PHP), при этом имея сильное и твердое фоновое ядро ​​(потому что он компилируется, и компилятор говорит о проблемах во время компиляции)

4 голосов
/ 07 октября 2009

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

Почему? * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *}} * * * * * * *} * * * * * * * * * *} * * * * * * *} * * * *} * * * * * * * * * * * * * * * * То, что переводит , интерпретируя *1006*, интерпретируя *1006*, (т.е. переводчик), когда пользователь фактически использует ваш сайт.

Сказав это ... это не обязательно означает, что ваш сайт будет работать на 100% быстрее на скомпилированном языке по сравнению с интерпретируемым языком. Существуют интерпретаторы, которые в настоящее время работают очень быстро для различных языков (например, PHP), и есть даже оптимизаторы для интерпретируемых языков, которые делают их еще быстрее.

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

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

0 голосов
/ 03 апреля 2010

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

0 голосов
/ 07 октября 2009

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

Кроме того, хотя интерпретируемые части PHP могут быть несколько медленными, это лишь малая часть того, что происходит при выполнении сценария PHP. Все функции, которые предоставляются как часть языка, реализованы в собственном коде. Например, когда вы вызываете функцию, подобную preg_match, она вызывает библиотеку собственного кода и позволяет ей выполнять свою работу. Это означает, что происходит меньше фактической интерпретации, чем вы думаете.

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

0 голосов
/ 07 октября 2009

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

  1. Сетевые задержки
  2. Статические носители, особенно изображения
  3. Запросы к базе данных
  4. Код обработки на стороне сервера
  5. Код обработки на стороне клиента

1 и 5 на самом деле не имеют ничего общего с этим вопросом.

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

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

Люди могут спросить "Зачем оптимизировать php?" потому что 2 и 3 часто более важны в любом случае. Часто хорошая структура кэширования базы данных будет лучшей (и более простой) оптимизацией.

0 голосов
/ 07 октября 2009

Perl не является интерпретируемым языком: он компилируется в байт-код, поэтому вы платите за интерпретацию только при запуске исполняемого файла perl.Поэтому при использовании его с Apache не используйте CGI, а mod_perl.

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

0 голосов
/ 07 октября 2009

ИМХО, совершенно бессмысленно писать сложные веб-приложения на скомпилированном языке, поскольку это не дает преимуществ против ряда проблем управляемости.

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

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

...