Я создаю веб-сайты, управляемые базами данных. Раньше я использовал Perl или PHP с MySQL.
Теперь я начинаю большой новый проект, и я хочу сделать это таким образом, который приведет к самому быстродействующему возможному сайту .
Я видел несколько страниц здесь, где вопросы о том, как оптимизировать PHP, подвергаются критике с различными версиями «для оптимизации PHP не стоит много работать, поскольку это интерпретируемый язык, и это не будет иметь большого значения».
Я также слышал различные обсуждения (особенно в подкасте SO) о преимуществах скомпилированных или интерпретируемых языков , и кажется, что в моих интересах использовать скомпилированный язык для обслуживания сайта вместо интерпретируемого языка.
Возможно ли это в веб-контексте? Если да, то какой будет разумный выбор языка?
В дополнение к скорости одно преимущество я forsee является возможность поиска ошибок во время компиляции вместо необходимости отладки веб-сайта. Это разумно ожидать?
Что вы можете сделать, так это то, что делают несколько сайтов с большим трафиком (например, Facebook или Twitter), а также записывают ваш «потребляющий процессор» алгоритм в C-плагине.
Например, вы можете написать расширение PHP, если вы планируете использовать PHP или расширение Ruby, если вы планируете использовать Ruby / Ruby on Rails и т. Д.
Таким образом, вы можете упростить и упростить управление своим упрощенным кодом (может быть сложнее обрабатывать запрос с C, а не с PHP), имея сильное и прочное базовое ядро (потому что оно скомпилировано, а компилятор говорит вам, что проблемы находятся во время компиляции)
Если бы вы собирались создать новый язык … и вы придумали все семантику, и все было готово, и у вас было какое-то волшебное поле, в котором есть переключатель между созданием языка, скомпилированным или интерпретированным, скомпилированная версия будет быстрее чем интерпретированная версия.
Зачем? Поскольку компиляция приводит вашу семантику к более низкому уровню на машине, это означает, что она может выполняться намного быстрее, тогда как интерпретация означает, что семантика вашего языка будет переведена какой-то вещью (то есть интерпретатором), когда пользователь фактически использует ваш сайт.
Сказав, что … это не обязательно означает, что ваш сайт будет на 100% быстрее работать на скомпилированном языке и на интерпретируемый язык. Там есть переводчики, которые очень быстрые в настоящее время для разных языков (например, PHP), и есть даже оптимизаторы для интерпретируемых языков, которые делают их еще быстрее.
Есть много других вещей, которые входят в производительность вашего сайта, которые являются агностиками выбранного вами языка. Настройка оборудования, Настройка базы данных, Сетевая топология и т. Д. Эти вещи могут оказать большее влияние на вас. Я бы предложил измерить, чтобы быть уверенным.
Для меня поиск ошибок во время компиляции – это огромная экономия времени, поэтому я предпочитаю скомпилированные языки, которые строго типизированы. Это позволяет мне быстрее выполнять мою работу, но это не делает ее объективно лучшим вариантом. У некоторых людей нет проблем с написанием слабо типизированного кода и запуском наборов тестов для проверки их функциональности, что, я думаю, будет работать так же хорошо.
ИМХО, совершенно бессмысленно писать сложное веб-приложение с использованием скомпилированного языка, поскольку оно не дает преимуществ от ряда проблем с управляемостью.
Там есть много способов повысить производительность и масштабируемость на языке сценариев, как на уровне языка, так и на системном уровне, будучи второстепенными достижениями, которые в конечном итоге доступны с компилируемым языком, полностью влияющим.
С другой стороны, мне очень полезно, когда можно следовать гибкой схеме разработки и поиска ошибок, просто меняя свой код и видя результаты.
Perl не является интерпретированным языком: он скомпилирован в байт-код, поэтому вы платите цену за перевод только тогда, когда запущен исполняемый файл perl. Поэтому, когда вы используете его с Apache, не используйте CGI, а mod_perl.
Что бы вы ни делали, время разработки, вероятно, будет значительно превышать время отклика, если вы выберете язык, который не подходит для веб-программирования, или у вас нет хороших библиотек для поддержки того, что вам нужно делать. Например, я бы никогда не выбрал C или C ++. Вы не хотите, чтобы веб-приложение было быстрым, но глючным и опозданием на 6 месяцев.
Tomcat – это распространенный способ использования скомпилированных языков для развертывания веб-страниц, но прежде чем заходить слишком далеко, серьезно подумайте о том, какими будут ваши узкие места в скорости . Существует несколько основных источников замедления веб-приложений:
1 и 5 действительно не имеют большого отношения к этому вопросу.
2 будет актуальным, если у вас много изображений, которые меняются от страницы к странице. Если это так, клиентские браузеры не будут делать такое хорошее кэширование работы, и каждая загрузка страницы займет некоторое время. В этом случае очень вероятно, что ваш серверный язык не будет замечен, потому что преобладают служебные данные из статических медиа.
3, вероятно, будет большим фактором, чем 4 для многих приложений. Если у вас очень мало данных, но вы выполняете большую обработку, то 4 могут доминировать, но в противном случае 3 будет доминировать, даже если вы используете интерпретируемый язык.
Люди могут спросить: «Зачем оптимизировать php?» потому что 2 и 3 часто более важны. Часто хорошая структура кэширования базы данных будет лучшей (и более простой) оптимизацией.
Есть много частей, которые входят в веб-приложение. Время, затрачиваемое прикладным уровнем, не должно быть большим. Для типичного приложения самые большие свиньи будут на веб-сервере и в базе данных. Замена PHP двоичным cgi не изменит этого.
Кроме того, хотя интерпретируемые части PHP могут быть несколько медленными, это лишь малая часть того, что происходит при выполнении скрипта PHP. Все функции, предоставляемые как часть языка, реализованы в собственном коде. Например, когда вы вызываете функцию, подобную preg_match , она вызывается из библиотеки собственных кодов и позволяет ей выполнять свою работу. Это означает, что существует менее реальная интерпретация, чем вы думаете.
Могут быть случаи, когда использование другого языка, кроме PHP, может оказаться полезным, но это особые случаи. В общем, здесь ничего не получится.
Латентность сети, безусловно, является самым важным определяющим фактором в этом аргументе. На самом деле, латентность сети – это настолько важный фактор, что она не учитывает соображения, связанные с производительностью. Итак … пойдите с тем, что вы знаете. Используйте язык, который вам наиболее удобен и продуктивен, и другие соображения могут быть разработаны по ходу дела. Теперь, сказанное, всегда интересно попробовать новые вещи, и изучение новых вещей может стать одержимостью, поэтому, если проект является личным, что позволяет вам экспериментировать, ну, во что бы то ни стало …..