Тут слегка другой случай. Статистика по репозиториям довольно красноречива конкретно для D, особенно по сравнению с другими языками, в некоторой степени являющимися для D альтернативой к изучению.
Мне это помогло выбрать язык для изучения, вот и делюсь статистикой.
В большинстве случаев сервер Go ставится за nginx и занимается явно не простой отдачей файлов или статичной строчки, ну и я полностью согласен с тем, что если встроенный файловый сервер Go догоняет Nginx, то тут действительно что-то не так.
В любом случае, http стек в Go достаточно быстр, но если нужно лишь отдавать статику, либо проксировать запросы по статичным конфигам — выбор явно в пользу nginx.
Я вообще считаю, что тема производительности go vs nginx как минимум слегка оффтопик, а как максимум — не имеет смысла :)
В том же реддите
«91255.00 req/s for Golang» vs «NGINX scales at 142618.31 req/s»
И
«Tried it with wrk and not ab now, and with nginx echo. Go does ~140-150k rps, nginx does ~160-180k rps»
Сейчас я и думаю, как бы это сделать.
На reddit уже делали сравнение производительности Go и Nginx, примерные результаты — Go ~140-150k rps, против nginx ~160-180k.
Nginx быстрее, но не так уж сильно.
Сейчас я пытаюсь разобраться в предметной области и написать простенький демон на Go, который делает то, что описано в статье.
Перечитал статью, на Go эта задача решается элементарно и код был бы чище (т.к. есть возможность писать синхронный код), меньше, это все было бы намного проще деплоить и кушало бы меньше ресурсов.
Та же асинхронность, перспективность, очень простой синтаксис и простота написания кода для конкретно этой задачи еще выше.
Мне стало интересно, я бы не отказался написать аналогичный сервис на Go и сравнить ключевые для вас показатели.
Уверен, что это было бы даже проще, чем чтение логов nginx-а, которое предлагается в комментариях.
Как нибудь посмотрите в сторону Go и/или InfluxDB.
Имею очень положительный опыт с Go + MongoDB, а InfluxDB может лучше подойти для данных, с которыми вы работаете.
Также, Go идеально подходит для описанной задачи и требований.
Средствами youtube api можно получить несколько кадров из видео для анализа, если таких хитрых агентов будет достаточно много, довольно легко проверять и видео.
К сожалению, пока что нельзя запустить golang в Chrome.
«They cannot be run directly in Google Chrome. As such, the NaCl support in Go 1.3 is useful only for running sandboxed environments like the Go Playground»
Сам когда-то изучал этот вопрос, очень жаль, что они еще не добавили такую возможность.
А выложите на гитхаб проект на Go? Очень интересно было бы посмотреть, может даже законтрибутить.
Кстати, посмотрите в сторону WebRTC, возможно что-то пригодится для плагина — кажется, на его основе можно сделать так, что на бекенде у вас останется лишь signaling-составляющая, а все остальное можно сделать полностью распределенным.
В такой ситуации лучше использовать какой-нибудь оркестратор и service-discovery. А еще лучше — software defined network типа flannel или Kubernetes, который позволит все эти контейнеры разнести по разным хостам.
Ну или посмотреть в сторону CoreOS (с тем же flannel).
Сейчас у меня на продекшене это делается через skydock/skydns (т.е. service discovery), но никому не советую так делать.
В таком случае лучше использовать какую-то утилиту для шаблонов, которая будет генерировать Dockerfile в зависимости от окружения.
Т.е. будет Dockerfile.template
{% if proxy %}
RUN pip --proxy http://1.1.1.1:80/ install uwsgi
{% else %}
RUN pip install uwsgi
{% endif %}
И на этапе сборки сначала генерируется Dockerfile, а затем уже выполняется сборка образа.
Почти такой подход у меня применяется для того, чтобы обновлять образы при деплое — подставляется хеш коммита в определенную строчку.
Иметь один Dockerfile не получится из-за того, что он должен не зависить от окружения by design.
Логичнее всего было бы сделать базовый образ для uwsgi, запушить в registry и использовать уже его.
Согласен, устройств там не густо.
По поводу формата в браузере — по-моему в андроиде как раз webm поддерживается почти во всех (если не во всех) браузерах.
Мне это помогло выбрать язык для изучения, вот и делюсь статистикой.
В любом случае, http стек в Go достаточно быстр, но если нужно лишь отдавать статику, либо проксировать запросы по статичным конфигам — выбор явно в пользу nginx.
Я вообще считаю, что тема производительности go vs nginx как минимум слегка оффтопик, а как максимум — не имеет смысла :)
В том же реддите
«91255.00 req/s for Golang» vs «NGINX scales at 142618.31 req/s»
И
«Tried it with wrk and not ab now, and with nginx echo. Go does ~140-150k rps, nginx does ~160-180k rps»
И при дальнейших оптимизациях конкретно отдачи статики:
www.reddit.com/r/golang/comments/28so0e/go_networking_performance_vs_nginx/cif19e1
Если вы используете ее лишь из javascript, то достаточно любого ответа 2xx с image/gif, разве нет?
Ну и я достаточно мало работал с nodejs, так что вряд ли смогу написать адекватный тест.
Может, поможете с этим?
Время на отдачу одной картинки, количество занятой памяти в зависимости от размера кеша, скорость вставки в монгу?
На reddit уже делали сравнение производительности Go и Nginx, примерные результаты — Go ~140-150k rps, против nginx ~160-180k.
Nginx быстрее, но не так уж сильно.
Сейчас я пытаюсь разобраться в предметной области и написать простенький демон на Go, который делает то, что описано в статье.
Та же асинхронность, перспективность, очень простой синтаксис и простота написания кода для конкретно этой задачи еще выше.
Мне стало интересно, я бы не отказался написать аналогичный сервис на Go и сравнить ключевые для вас показатели.
Уверен, что это было бы даже проще, чем чтение логов nginx-а, которое предлагается в комментариях.
Имею очень положительный опыт с Go + MongoDB, а InfluxDB может лучше подойти для данных, с которыми вы работаете.
Также, Go идеально подходит для описанной задачи и требований.
«They cannot be run directly in Google Chrome. As such, the NaCl support in Go 1.3 is useful only for running sandboxed environments like the Go Playground»
Сам когда-то изучал этот вопрос, очень жаль, что они еще не добавили такую возможность.
Кстати, посмотрите в сторону WebRTC, возможно что-то пригодится для плагина — кажется, на его основе можно сделать так, что на бекенде у вас останется лишь signaling-составляющая, а все остальное можно сделать полностью распределенным.
Ну или посмотреть в сторону CoreOS (с тем же flannel).
Сейчас у меня на продекшене это делается через skydock/skydns (т.е. service discovery), но никому не советую так делать.
Т.е. будет Dockerfile.template
И на этапе сборки сначала генерируется Dockerfile, а затем уже выполняется сборка образа.
Почти такой подход у меня применяется для того, чтобы обновлять образы при деплое — подставляется хеш коммита в определенную строчку.
Иметь один Dockerfile не получится из-за того, что он должен не зависить от окружения by design.
Логичнее всего было бы сделать базовый образ для uwsgi, запушить в registry и использовать уже его.
По поводу формата в браузере — по-моему в андроиде как раз webm поддерживается почти во всех (если не во всех) браузерах.
Я не шибко разбираюсь в SoC, но там же есть список
wiki.webmproject.org/hardware/socs
Возможно это то, о чем вы говорили?
Так же есть вероятность того, что поддержку аппаратного ускорения не добавляют по тем же политическим причинам.
wiki.webmproject.org/hardware/devices
WebP не поддерживается Firefox по политическим причинам.