Тоже давно смотрю в сторону ухода написания сайтов целиком на C++. Сейчас использую гибридный вариант c PHP-CPP.
В качестве плюсов использования C++ в веб разработке (в качестве дополнения к посту) я бы назвал:
1) Итоговое приложение работает молниеносно.
2) Никаких архитектурных компромиссов. В том же PHP всегда стоит выбор либо быстро работает, либо красивая архитектура.
3) На самом деле, если разработчик уже знает C++, то разработка на C++ не занимает больше времени чем на динамических языках. Особенно в двух последних стандартах.
4) Статическая типизация, статический анализ кода из коробки.
5) Огромное количество готовых библиотек на все случаи жизни.
и т.д.
Из минусов, на мой взгляд, только отладка.
Если говорить о реализации веб фреймворка на С++. То что хотелось бы видеть в первую очередь:
1) Разбор заголовков (работа с данными POST, GET, Cookies) (можно взять http-parser).
2) Шаблонизатор (можно взять SMART-TPL)
Ну конкретно в данном случае речь о создании чего то вроде фреймворка для написания сайтов на C++. Тот же libevent.a имеет размер 2.5Мб — даже на микроконтроллер засунуть можно, при определенных обстоятельствах.
Статику отдавать такой сервер вообще не должен, по-моему. Для этого есть специально разработанные для этого решения вроде Nginx'а.
Вы же не на каких то абстрактных системах будите запускать? А на таких, которые для этого предназначены. Так что, то что на некоторых системах все равно будет использоваться select не должно вас смущать.
Я думаю, потому что на самом деле свой вебсервер писать не нужно, а нужно использовать в качестве базы готовые библиотеки (LibEvent, boost::asio, etc). А сервер в любом случае будет работать быстрее т.к. не тратится время на инициализацию. Nginx'у без разницы на что проксировать cgi или другой сервер.
Кроме того сервер даёт много дополнительных плюшек в виде понятного интерфейса, маршрутизации и т.п.
Пользуясь случаем хочу поблагодарить Яндекс за то что выкладываете в открыты доступ свои внутренние конференции. Всегда с огромным интересом смотрю записи. Особенно C++ секцию.
Я тоже вчера в их блоге это увидел. Это очень важный эпизод т.к. до этого момента связываться с hhvm было просто опасно — можно было остаться один на один с недодерживаемой версией.
Если кратко, то этот шаг частично нивелирует риски (с которыми я согласен), описанные здесь: blog.ircmaxell.com/2014/03/an-opinion-on-future-of-php.html
Да вы правы. В текущем виде Memcache протокол смотрелся бы там очень логично. Я даже подумаю над тем, что бы добавить еще один уровень абстракции и сделать протокол заменяемым.
Поясню, почему я изначально не остановился на Memcache протоколе. RocksDB предоставляет бо`льшие возможности нежели Memcached и в дальнейшем я планирую расширять функциональные возможности. соответственно на каком то этапе Memcache протокол будет исчерпан.
Но, безусловно, никто не обязан использовать все возможности сервера. И вполне можно обойтись только базовыми. Так что ваше замечание очень полезно. Спасибо.
Не уверен что верно понял ваш вопрос, но попробую ответить как понял.
Году где-то в 2012 я переписывал один довольно посещаемый проект (в то время посещаемость была ~50 000 хостов/сутки ). Сервер справлялся с нагрузкой но время отклика оставляло желать лучшего. Оптимизация MySQL кардинально ситуацию не улучшила. В итоге было решено добавить кэширующий слой. В качестве бекенда для кэширующий библиотеки были поставлены Redis и Memcached. В итоге время отклика стало экстремально низким: 2-6 мс, но поддержка проекта стала вызывать боль. Появилась сильная связанность. Вот собственно тогда размышляя над тем как такое получилось пришло понимание, что кэширования должно быть ровно столько, что бы оно не увеличивало связанность компонентов внутри проекта.
Теперь что меня привело к написанию RocksServer'a. Сейчас у меня наконец то представилась возможность поучаствовать в написании большого интересного проекта. Я не знаю заранее какой будет посещаемость но изначально время отклика должно быть экстремально низким. Собственно, обоснование того, почему какой бы эффективный алгоритм не использовало хранилище данных, все упирается в носитель (HDD) я описал в статье. Поэтому изначально рассматривал хранилища оптимизированные под SSD.
Инфраструктура. Планируется использовать Debian сервер (может быть будет Ubuntu). Структуру каталогов я планирую хранить в Resdis. Под него будет отведено 2-3 Гб. Все остальные данные пойдут в RocksServer. Под данные ожидается выделить 100-300 Гб. Мне уже писали в личку, что такой объем данных вполне можно засунуть в ОЗУ, но это существенно увеличит стоимость архитектуры. Поэтому из практических соображений SSD является для меня оптимальным компромиссом.
Что касается тонкой настройки самого RocksDB, то, как я уже говорил, в боевых условиях я его еще не испытывал, поэтому ничего полезного по этому поводу пока сказать не могу.
Да Страуструп написал свой первый «компилятор» как раз в виде транслятора тогдашнего C++ в С. Сейчас C++ полностью в C не конвертируется. На сколько я знаю (ни разу не пробовал) LLVM умеет конвертировать C++ в С. Но там есть ограничения. Точно знаю что код должен быть без использования исключений. Может быть еще какие то ограничения есть.
Спасибо за отзыв.
Никогда не сталкивался с HyperLevelDB. Если честно, я досконально не разбирался с API LevelDB. И сейчас мне трудно сказать в какой части они перестают быть совместимыми. Знаю точно, что то что я сейчас использую от RocksDB есть и в LevelDB. С другой стороны различные итераторы появившиеся в поздних версях RocksDB или семейства столбцов, скорее всего, в LevelDB отсутствую.
Вообще планы развивать RocksServer и добавлять бэкенды есть. Но сначала я хотел перейти к его практическому использованию. В текущем виде он решает те задачи которые есть у меня в настоящий момент и сама архитектура предполагает не сложное его расширение.
На счет стенда согласен. У Фэйсбука действительно уникальные условия использования.
Тут важно два момента: LevelDB изначально не проектировалась для больших объемов данных, RocksDB наоборот; LevelDB не проектировалась для работы на SSD накопителях. Как следствие LevelDB на SSD потенциально может обернуться проблемами преждевременного износа SSD диска.
В качестве плюсов использования C++ в веб разработке (в качестве дополнения к посту) я бы назвал:
1) Итоговое приложение работает молниеносно.
2) Никаких архитектурных компромиссов. В том же PHP всегда стоит выбор либо быстро работает, либо красивая архитектура.
3) На самом деле, если разработчик уже знает C++, то разработка на C++ не занимает больше времени чем на динамических языках. Особенно в двух последних стандартах.
4) Статическая типизация, статический анализ кода из коробки.
5) Огромное количество готовых библиотек на все случаи жизни.
и т.д.
Из минусов, на мой взгляд, только отладка.
Если говорить о реализации веб фреймворка на С++. То что хотелось бы видеть в первую очередь:
1) Разбор заголовков (работа с данными POST, GET, Cookies) (можно взять http-parser).
2) Шаблонизатор (можно взять SMART-TPL)
libevent.aимеет размер 2.5Мб — даже на микроконтроллер засунуть можно, при определенных обстоятельствах.Статику отдавать такой сервер вообще не должен, по-моему. Для этого есть специально разработанные для этого решения вроде Nginx'а.
selectне должно вас смущать.#elif POSIXлогичнее было бы увидетьepoolКроме того сервер даёт много дополнительных плюшек в виде понятного интерфейса, маршрутизации и т.п.
Если кратко, то этот шаг частично нивелирует риски (с которыми я согласен), описанные здесь: blog.ircmaxell.com/2014/03/an-opinion-on-future-of-php.html
Поясню, почему я изначально не остановился на Memcache протоколе. RocksDB предоставляет бо`льшие возможности нежели Memcached и в дальнейшем я планирую расширять функциональные возможности. соответственно на каком то этапе Memcache протокол будет исчерпан.
Но, безусловно, никто не обязан использовать все возможности сервера. И вполне можно обойтись только базовыми. Так что ваше замечание очень полезно. Спасибо.
Году где-то в 2012 я переписывал один довольно посещаемый проект (в то время посещаемость была ~50 000 хостов/сутки ). Сервер справлялся с нагрузкой но время отклика оставляло желать лучшего. Оптимизация MySQL кардинально ситуацию не улучшила. В итоге было решено добавить кэширующий слой. В качестве бекенда для кэширующий библиотеки были поставлены Redis и Memcached. В итоге время отклика стало экстремально низким: 2-6 мс, но поддержка проекта стала вызывать боль. Появилась сильная связанность. Вот собственно тогда размышляя над тем как такое получилось пришло понимание, что кэширования должно быть ровно столько, что бы оно не увеличивало связанность компонентов внутри проекта.
Теперь что меня привело к написанию RocksServer'a. Сейчас у меня наконец то представилась возможность поучаствовать в написании большого интересного проекта. Я не знаю заранее какой будет посещаемость но изначально время отклика должно быть экстремально низким. Собственно, обоснование того, почему какой бы эффективный алгоритм не использовало хранилище данных, все упирается в носитель (HDD) я описал в статье. Поэтому изначально рассматривал хранилища оптимизированные под SSD.
Инфраструктура. Планируется использовать Debian сервер (может быть будет Ubuntu). Структуру каталогов я планирую хранить в Resdis. Под него будет отведено 2-3 Гб. Все остальные данные пойдут в RocksServer. Под данные ожидается выделить 100-300 Гб. Мне уже писали в личку, что такой объем данных вполне можно засунуть в ОЗУ, но это существенно увеличит стоимость архитектуры. Поэтому из практических соображений SSD является для меня оптимальным компромиссом.
Что касается тонкой настройки самого RocksDB, то, как я уже говорил, в боевых условиях я его еще не испытывал, поэтому ничего полезного по этому поводу пока сказать не могу.
Никогда не сталкивался с HyperLevelDB. Если честно, я досконально не разбирался с API LevelDB. И сейчас мне трудно сказать в какой части они перестают быть совместимыми. Знаю точно, что то что я сейчас использую от RocksDB есть и в LevelDB. С другой стороны различные итераторы появившиеся в поздних версях RocksDB или семейства столбцов, скорее всего, в LevelDB отсутствую.
Вообще планы развивать RocksServer и добавлять бэкенды есть. Но сначала я хотел перейти к его практическому использованию. В текущем виде он решает те задачи которые есть у меня в настоящий момент и сама архитектура предполагает не сложное его расширение.
Тут важно два момента: LevelDB изначально не проектировалась для больших объемов данных, RocksDB наоборот; LevelDB не проектировалась для работы на SSD накопителях. Как следствие LevelDB на SSD потенциально может обернуться проблемами преждевременного износа SSD диска.