А потом начальство почесало репу, и вместо MCU со 128 байтами RAM / 8Kb Program ROM или FLASH или что там у них было, вздохнуло, и разрешило поставить такой же по футпринту микроконтроллер, но 512/16Kb, который обошелся на десять центов дороже.
Трудно судить как это работает без VMWare на данной платформе.
Могу сказать, что в yaws/mochiweb которые мы используем — RPS где-то 4500, количество одновременных коннектов — 10000 и выше. В happstack — RPS 7000, количество коннектов еще выше, так как памяти потребляет меньше.
К сожалению, не смог собрать этот тулкит, что бы сравнить. Но 550 клиентов — не особо впечатляет, ну и это примерно то, что и должно получаться при создании треда на коннект. Пул тредов в обычном виде проблему не решит.
В общем-то, я могу сказать, что результат 500 коннектов / 1500 — 2000 RPS — примерно тоже самое, что у нас получалось при использовании питона (при условии, что запросы к базе кэшированы), от которого в итоге отказались.
Т.е. по моему очевидно, что наивно реализованный HTTP сервер не дает выигрыша только от того, что написан на C++. Не надо, по моему, тянуть С++ в эту нишу.
Я в самом первом сообщении написал, что «с другой — при наличии инфраструктуры и отлаженных средств управления ей — уже все равно на чем писать бекенды». Я не сомневаюсь, что на PHP можно написать нагруженный проект. Про MySQL я вообще ни слова не сказал — это вы с самим собой спорите, что ли?
Но языки, инструменты, все разные. На одних проще сделать качественный и расширяемый продукт, на других это менее просто.
И на последок таки донесу свою точку зрения — разница на чем писать есть. И разница в результате в зависимости от выбора инструментария — тоже есть. И от умения это, зачастую, никак не зависит, если, конечно, вы в необходимые умения не зачисляете исправление и переписывание выбранной платформы.
Разница между языками есть. В трудоемкости разработки. В выразительности. В количестве в дефектов (статическая типизация — меньше, динамическая — больше). В производительности (таки да). В наличии и количестве необходимых библиотек. В качестве этих библиотек. В легкости разрабатывать масштабируемые решения. В стоимости и наличии необходимых специалистов для разработки и поддержки.
Если бы разницы не было — то все бы так и писали на С, и всех бы все устраивало.
Обидеть язык программирования невозможно, он не человек. А уж если человек действительно пишет на многих языках, то врядли его может задеть упоминание, что какой-то язык — так себе язык. Тем более, что если человек на всех этих языках пишет, то не может не видеть, что они ВСЕ — так себе, в том или ином. Ну, правда есть языки от которых пованивает, но замечаешь это не сразу, а есть такие, от которых просто смердит.
Да, все так. Да, на php мало, потому что в здравом уме на нем врядли кто писать будет, так как язык мерзкий, а технической стороной в яндексе заправляют технические специалисты. Но количество проектов на питоне там немногим превышает количество проектов на PHP, с одной стороны, а с другой — при наличии инфраструктуры и отлаженных средств управления ей — уже все равно на чем писать бекенды. Есть проекты на перле, например. Никто же не говорит, что «яндекс написан на перле».
1000 RPS это не так много (если речь о dedicated сервере), и легко достигается, например, на питоне.
Проблема — в базе, обращение к базе просаживает производительность сразу на порядок, а для тяжелых
запросов — на два и более. Как понимаете, эта константа от языка не зависит, и потому, делать приложение на
C++ нет никакого смысла вообще. Если посмотреть на тесты, то:
Ocsigen — 4500 — 5800 RPS (core duo что-то там)
YAWS на таком железе будет где-то 2500 — 2800 RPS
Python (мерял на нашем фреймворке) — 480 (без memcached) — 1700 (c memcached)
При том, что правильно написанные http приложения могут естественным образом масштабироваться —
то еще раз, писать на C++ не имеет смысла.
В яндексе Не пишут сначала тестовый вариант на питон. В яндексе много проектов. Одни на одном, другие — на другом. Мой круг вот вообще на PHP написан. Но это не повод говорить, что в Яндексе пишут приложения на PHP.
Взяли питонового человека — стали писать «сначала» тестовый вариант на питоне. То, что его в итоге перепишут на C/C++ это еще не факт.
По большому счету, вообще все равно на чем писать бекенд, так как 20000000 хитов в сутки разделить на 86400 — это получается всего-навсего 231. Даже если считать, что у нас в сутках 10 часов (часы пик и тп) — то это 500 RPS.
500 RPS с сервера достигается на чем угодно, если руки растут из плеч, даже на PHP, не к ночи будь помянут.
Летайте — на чем? система с такими характеристиками была бы интересна на платформах типа ARM9 — можно было бы (гипотетически) строить дешевые, но полноценные системы с очень хорошими показателями по энергопотреблению.
Но, ввиду асма, систему туда не портировать. Использовать асм большая ошибка, даже при разработке для микроконтроллеров — сам недавно столкнулся с портированием системы на TI — и система, написанная на асме пошла в топку целиком. Системное зачастую ПО стоит дороже и служит дольше, чем аппаратные платформы, для которых оно разрабатывается.
Могу сказать, что в yaws/mochiweb которые мы используем — RPS где-то 4500, количество одновременных коннектов — 10000 и выше. В happstack — RPS 7000, количество коннектов еще выше, так как памяти потребляет меньше.
К сожалению, не смог собрать этот тулкит, что бы сравнить. Но 550 клиентов — не особо впечатляет, ну и это примерно то, что и должно получаться при создании треда на коннект. Пул тредов в обычном виде проблему не решит.
В общем-то, я могу сказать, что результат 500 коннектов / 1500 — 2000 RPS — примерно тоже самое, что у нас получалось при использовании питона (при условии, что запросы к базе кэшированы), от которого в итоге отказались.
Т.е. по моему очевидно, что наивно реализованный HTTP сервер не дает выигрыша только от того, что написан на C++. Не надо, по моему, тянуть С++ в эту нишу.
Но языки, инструменты, все разные. На одних проще сделать качественный и расширяемый продукт, на других это менее просто.
И на последок таки донесу свою точку зрения — разница на чем писать есть. И разница в результате в зависимости от выбора инструментария — тоже есть. И от умения это, зачастую, никак не зависит, если, конечно, вы в необходимые умения не зачисляете исправление и переписывание выбранной платформы.
Если бы разницы не было — то все бы так и писали на С, и всех бы все устраивало.
Обидеть язык программирования невозможно, он не человек. А уж если человек действительно пишет на многих языках, то врядли его может задеть упоминание, что какой-то язык — так себе язык. Тем более, что если человек на всех этих языках пишет, то не может не видеть, что они ВСЕ — так себе, в том или ином. Ну, правда есть языки от которых пованивает, но замечаешь это не сразу, а есть такие, от которых просто смердит.
Проблема — в базе, обращение к базе просаживает производительность сразу на порядок, а для тяжелых
запросов — на два и более. Как понимаете, эта константа от языка не зависит, и потому, делать приложение на
C++ нет никакого смысла вообще. Если посмотреть на тесты, то:
Ocsigen — 4500 — 5800 RPS (core duo что-то там)
YAWS на таком железе будет где-то 2500 — 2800 RPS
Python (мерял на нашем фреймворке) — 480 (без memcached) — 1700 (c memcached)
При том, что правильно написанные http приложения могут естественным образом масштабироваться —
то еще раз, писать на C++ не имеет смысла.
Взяли питонового человека — стали писать «сначала» тестовый вариант на питоне. То, что его в итоге перепишут на C/C++ это еще не факт.
По большому счету, вообще все равно на чем писать бекенд, так как 20000000 хитов в сутки разделить на 86400 — это получается всего-навсего 231. Даже если считать, что у нас в сутках 10 часов (часы пик и тп) — то это 500 RPS.
500 RPS с сервера достигается на чем угодно, если руки растут из плеч, даже на PHP, не к ночи будь помянут.
Но, ввиду асма, систему туда не портировать. Использовать асм большая ошибка, даже при разработке для микроконтроллеров — сам недавно столкнулся с портированием системы на TI — и система, написанная на асме пошла в топку целиком. Системное зачастую ПО стоит дороже и служит дольше, чем аппаратные платформы, для которых оно разрабатывается.