Интерпретированный противСкомпилированные языки для веб-сайтов (PHP, ASP, Perl, Python и т.д.)

Question

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

1 и 5 на самом деле не имеют большого отношения к этому вопросу.

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

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

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

Answer 6

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

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

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

Answer 7

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