Каковы взлеты и падения использования FastCGI С++ vs. PHP/Python/Perl для выполнения той же работы.
Любые ошибки производительности или дизайна или использование одного над другим? Даже ваши мнения приветствуются. (Скажи мне, почему одни или другие камни, или то, и другое отстой).
Несколько лет назад я более или менее изучал программирование веб-приложений на работе. C был основным языком, который я знал, поэтому я написал (довольно масштабное) веб-приложение в C. Плохая ошибка. Обработка строк в C и управление памятью являются утомительными, и вместе с моим отсутствием опыта работы в веб-приложениях он быстро стал труднодоступным проектом.
С++ будет значительно лучше, главным образом потому, что std::string намного приятнее, чем char*.
Однако теперь я буду использовать Python каждый раз (хотя PHP не является страшным выбором и, возможно, проще начать работу). Обработка строк Python является удивительной, и она без проблем обрабатывает Unicode. Python имеет гораздо лучшие веб-инструменты и фреймворки, чем С++, и его обработка регулярных выражений и стандартные библиотеки (urllib, электронная почта и т.д.) Работают очень хорошо. И вам не нужно беспокоиться об управлении памятью.
Я бы, вероятно, использовал только C или С++ для веб-приложения, если был сильно ограничен RAM (например, встроенный микро), или если я работал в Google и кодировал поисковую систему, которая должна была отвечать на тысячи запросов в секунду.
языки сценариев могут быть медленнее, чем C, но это проблема? Больше никогда. и если производительность становится проблемой, вы начинаете переводить только критические части.
twitter/ruby - хороший пример; Рубин медленный. некоторые из особенностей языка (которые делают рубин приятным в первую очередь) просто предотвращают различные виды оптимизации (есть замечательная статья jruby парня об этом... было ли это ola bini? не помню).
твиттер работает от рубина, потому что рубин достаточно быстр. недавно "блоги" сообщили, что твиттер переходит на scala по соображениям производительности... правда в том, что только очередь сообщений (и другие части бэкэнд) переместилась на scala. yahoo работает на смеси языков; php для интерфейса, другие, более быстрые языки используются там, где критическая производительность.
Итак, почему производительность не так важна? существует несколько причин:
еще одна точка про-скриптинга: многие языки сценариев поддерживают вложение или включение быстрого кода (C):
Я думаю, особенно в веб-разработке плюсы высокоуровневых сценариев далеки от лишнего веса.
Использование С++, скорее всего, приведет к значительно более быстрому применению, чем PHP, Perl или Python и несколько быстрее, чем С# или Java - если только он не тратит большую часть своего времени на ожидание БД, в этом случае разницы не будет, Это на самом деле самый распространенный случай.
С другой стороны, из-за причин, о которых говорилось в benhoyt, разработка веб-приложения на С++ займет больше времени и будет сложнее поддерживать. Более того, он с большей вероятностью будет содержать серьезные дыры в безопасности (в настоящее время все больше беспокоятся о SQL-инъекции и XSS), но если они пишут свои webapps в С++, это будет переполнение буфера, и все их сети будут получать pwned, а не только данные).
И поэтому почти никто не пишет веб-приложения на С++ в наши дни.
Я думаю, что кто-то должен стать пионером в теме Webapp/С++, чтобы протестировать землю и предоставить доказательства концептуальных решений.
С появлением STL и развитием синтаксического анализа Boost с С++ было очень легко. Два года назад, если бы мне пришлось разбирать CSV-данные, я бы использовал Python или PHP. Теперь я использую С++ с STL/Boost. Чтение CSV файла в векторы? Нет проблем, простой getline + boost:: split + lexical_cast. Вычисление суммы данных в вектор пар? Нет проблем:
pair<int, double> sum_int_double(pair<int,double> & total, pair<struct in_addr, pair<int,double> > & a) {
total.first += a.second.first;
total.second += a.second.second;
return total;
}
pair<int,double> mixedSum = accumulate(mixedVec.begin(), mixedVec.end(), emptyPair, sum_int_double);
Перенос данных из карты в вектор пар? Нет проблем:
mixedVec.assign(amap.begin(), amap.end());
Все хорошо определено и четкое. Строковые операции, регулярные выражения, алгоритмы, ООП и т.д. Все хорошо определено и зрело на С++. Если ваше приложение будет реальным приложением, а не анализирует текстовые, тогда С++ также будет хорошим выбором с его функциями OOP.
Вопрос: "Где создано значение?"
Если вы считаете, что значение создано в управлении памятью, тщательный дизайн класса и получение ночной сборки для работы, используйте С++. Вы потратите много времени на создание большого количества кода, чтобы делать важные вещи, такие как удаление объектов, на которые больше не ссылаются.
Если вы считаете, что значение заключается в развертывании приложений, которые могут использовать пользователи, используйте Python с картой Django. Учебник Django показывает вам, что через 20 минут вы можете запустить приложение и запустить его. Это готово к производству, и вы можете сосредоточиться на важных вещах:
Модель. Просто напишите модель в Python, и слой ORM обрабатывает все взаимодействие с базой данных для вас. Нет SQL. Нет ручного сопоставления.
Презентация. Просто создайте свои страницы в HTML с несколькими {{}} "заполните здесь значение" и несколькими конструкциями {% for thing in object_list %}, и ваши страницы готовы к работе. Нет строковых манипуляций.
Функции просмотра. Напишите простые функции Python, чтобы инкапсулировать часть обработки вашего сайта. Не проверка (те, которые находятся в формах), а не презентация (которая была в шаблонах), а не базовая модель (которая была в классах моделей), но немного проверка полномочий, обработка запросов и формулировка ответов. Поскольку Python имеет богатый набор классов коллекций, этот код заканчивается очень коротким и точным.
Другие вещи. Отображения URL - это регулярные выражения Python. Формы соответствуют вашей модели; вы можете подклассифицировать значения по умолчанию для добавления настраиваемой проверки ввода и обработки.
Замечательная модульная система тестирования для низкоуровневых функций модели, а также сквозных операций.
Отсутствует управление памятью, нет скрупулезного дизайна класса с рефератами и интерфейсами. Не волнуйтесь о том, как оптимизировать манипуляции с строкой. Нет ночной сборки. Просто создайте материал реальной ценности.
Если вы хотите иметь возможность реализовывать веб-службы в существующем запущенном процессе (например, daemon), который написан на C/С++. Имеет смысл заставить этот процесс реализовать протокол FastCGI для этого интерфейса. Получите Apache для работы с HTTP (2-сторонним SSL и т.д.) Во внешний мир и запросы полей через FastCGI через сокет. Если вы сделаете это на PHP, вам нужно заставить PHP поговорить с вашим процессом, что означает поддержание PHP-кода, а также вашего процесса.
Наличие веб-приложения FastCGI (независимо от того, С++, PHP, Perl, Python, Ruby и т.д.) дает вам лучшее начальное время запуска, чем приложение CGI. Посредством первоначального времени запуска я подразумеваю время, прошедшее между тем, как веб-сервер получает запрос, и время, в течение которого выполняется первая строка кода, поэтому начальное время запуска - это минимальное время, которое посетители вашего веб-приложения должны ждать для каждого запроса. Нет ничего необычного в том, что начальное время запуска составляет 1 секунду, особенно если ваше приложение велико или вы используете большую инфраструктуру (например, Ruby on Rails). FastCGI поддерживает работу ваших приложений после того, как он ответил на первый запрос, поэтому FastCGI уменьшает начальное время запуска всех последующих запросов (за исключением самого первого), обычно до нескольких миллисекунд.
Если вы используете PHP, обычно его конфигурация по умолчанию обеспечивает достаточно хорошее начальное время отклика (даже без FastCGI), но, пожалуйста, убедитесь, что вы используете ускоритель PHP на своем производственном сервере (см. http://en.wikipedia.org/wiki/PHP_accelerator), чтобы получить лучшую производительность.
Большинство языков программирования и фреймворков позволяют запускать одно и то же приложение в разных режимах сервера (например, CGI, FastCGI, встроенный веб-сервер, модуль Apache), изменяя конфигурации приложений без изменения кода. FastCGI, как правило, не самый лучший выбор при написании приложения, потому что после изменения кода вам может потребоваться перезапустить приложение, чтобы оно забирало ваши изменения, но, как правило, громоздко перезапускать приложение FastCGI. Перезапуск CGI или встроенного веб-сервера намного проще. Вы должны настроить FastCGI только в производственной конфигурации.
Есть люди, которые задавали это раньше: http://cppcms.sourceforge.net/wikipp/en/page/main
Проект CppCMS предоставляет платформу для веб-разработки с использованием С++.
Вы можете взглянуть на следующие эталонные тесты, чтобы понять, в чем разница: http://cppcms.sourceforge.net/wikipp/en/page/benchmarks - примерно на два порядка.
Проблема PHP/Python в том, что они очень медленные, в кэшировании много проблем данные в процессе FastCGI PHP.
Самая большая проблема С++ - это небольшое количество ресурсов разработки для Web в С++. Однако использование такой структуры, как CppCMS, делает жизнь намного проще.
Здесь есть место. Python (и я верю, что Perl и Ruby) позволяют вам вызывать функции из C. 99 раз из 100, вам не нужно. Но приятно знать, что опция есть, если вам это нужно.
Обычно для webapps скорость языка программирования просто не является проблемой. В то время, когда требуется выполнить один запрос базы данных, процессор может выполнять несколько миллиардов инструкций. Это примерно то же самое для отправки и получения http-данных.
Вы можете использовать FastCGI с PHP/Python/Ruby/Perl, чтобы получить производительность во время исполнения, которой должно быть достаточно, пока ваш сайт не станет действительно большим. И даже тогда вы можете сделать архитектурные улучшения (настройка базы данных, кэширование и т.д.), Чтобы масштабировать еще больше, не отказываясь от языков сценариев. Некоторые довольно крупные сайты выполняются в PHP/Python/Ruby/Perl.
Большой выигрыш, получаемый с использованием языков высокого уровня, - это производительность программиста. И это то, о чем вы должны сначала беспокоиться. Будет более важно быстро реагировать на запросы пользователей, а не нарезать несколько миллисекунд за время отклика страницы.
Ну... Вы сохраните память и мощность процессора с помощью C/С++ vs Python/Perl/Ruby/Java/.NET. Если ресурсы, сэкономленные с использованием C/С++, представляют значительную часть общих доступных ресурсов (FastCGI работает на встроенной плате робота), то да, C/С++. Иначе, зачем беспокоиться?
Возможно, кто-то из вас может быть интересен в Wt [1], веб-инструментарий, полностью написанный на С++. Это может быть альтернативой cppCMS. Я стараюсь оба в эти рождественские каникулы.
Слишком плохо нет тестов C/С++ и Perl CGI.
Без FastCGI я думаю, что C/С++ будет намного быстрее, а FastCGI, возможно, будет быстрее (но, может быть, немного меньше - вся часть инициализации выполняется один раз).
Опять же, это очень зависит от приложения, поэтому должны быть предоставлены некоторые ориентиры для различных динамических веб-страниц.
Лично я считаю, что если у вашей компании есть ресурсы, она должна/могла бы инвестировать в C/С++ (учитывая, что они должны найти правильные...), в противном случае лучше придерживаться языка сценариев.
Естественно, если вы хотите развернуть быстрые приложения, вы должны использовать C/С++.
В конце дня скомпилированный язык быстрее. Но, вероятно, найти хороших разработчиков C/С++ сейчас сложно?
Приветствия,
С++ - строго типизированный язык... т.е. вы можете объявлять ints, floats и т.д.... как правило, вы можете программировать более эффективно, чем вы можете, используя слабо типизированные языки. Facebook сообщил о 50% -ном улучшении при переключении с PHP на С++. Я бы подумал, что языки сценариев должны быть прототипическими языками... когда вы хотите, чтобы уровень эффективности на уровне производительности скомпилировал язык.
Мой поиск через Google показывает, что C/С++ дает лучшую производительность для веб-приложений, которым нужны такие функции, как поиск информации на веб-страницах или получение информации из базы данных.
Для этого есть несколько новых ответов.
Mojolicious или Dancer, а затем с помощью контроллера PSGI/Plack он может работать на CGI, FastCGI, mod_perl, собственные серверы (например, Hypnotoad от Mojolicious) или облачное развертывание, без изменений. Подобные концепции существуют и для других языков сценариев.