All streams
Search
Write a publication
Pull to refresh
19
0
Send message
Реално был хорошый год для GO рост и развитие на лицо
Согласен полностью. Динамические языки это классно когда маленькие вещи пишешь а потом просто АД. Согласен что не просто так много новых языков они статические потому что есть спрос и понимание. Я нашол себе GO для этих вещей. Стаческий, быстры и код одинако похож у разных людей.
Если надо много и часто сериализовать советую смотреть на ffjson или messagepack и кода генерация для этого. Можно получить очень большой прирост в скорости. стандартная сериализации получает interface поэтому должна искать что как сериализовать. Кода генерация даёт методы заточеные для страктов и поэтому очень быстро работает
redigo все проще
data, err := c.Do(command, args...)

Я использую а продакшине Redigo. Доволен очень. Удобный api даже смог красиво прикрутить newrelic на запросы в редис. Одно плохо есть проблема писать struct которые не только string а потом их читать надо их переводит в json а потом обратно. Немножко накдладно было. заменил json на messagepack с статической серилизацией получилось очень быстрая вещь
Дохожу сам то такой архитектуры только тяжелым путем :(
Надо больше читать…
прекрасно. Много че нового и полезного
простой пример а не готовый код в продакшин
А я не думаю что GO идеальный язык я просто его использую для подходящих задач. А то что GO спроектирован профессионалами тут спора нет
я пишу на GO и мне нравится. да есть некоторые вредные моменты в языке, но и что? кто тут знает идеальный язык? Можно взять любой язык программирование и сказать что он ужасный потому что в нем…
я вам могу написать на каждые язык программирование статью
«Почему %язык X% плохо продуманный язык программирования». Может хватит тратить килобайты сети на лишним срачку про GO. Язык как язык. Он родился и вырос себя показал и останется. Как и других языков у него будет своя ниша и свой процент кода в мире.
вот тесты с оптимизацией машины с GC и без всяких извращений
gist.github.com/hgfischer/7965620#go-standalone-1
Половина оптимизаций не имеет отношение к Netty. Все оптимизация ядра помогут любой платформы. Работать без GC продакшине не hello world как то не очень.
мне тоже интересно как получить 200K на ядро с 2-3ms. Как машина справляется с таким количеством сокетов?
Цифры с в студию тесты и так далее а то я тоже могу писать 200K
Netty смотрится хорошо на тестах. Мне не приходилось с ней работать но как я понел вам было не совсем просто написать на этом проложения которое берет сообщения с одного сокета и ложет в другой. Есть другие асинхроные более простые решения. Это и Node.js не очень быстрый но дешевый в плане разработки. Есть GO у которого все IO асинхроные и код простой синхронный. Язык быстрый и нет всяких заморочек. Я сам переписывал решение одно с Node.js на GO. Там логики по больше и редис и монго но сейчас это обрабытывает 1350 HTTP в секунду 3 сервера(меньше двух не ставим и так) по 4 ядра. Думаю с TCP это бы работало не хужею чем Netty. Вопрос стоило ли заморачиватся с Netty?
это. все разговоры… вот тесты с цифрами.http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=hipe
ну руби как бы не самое быстрая вещь. Если ерланг по скорости похож на руби то это явно медленнее ГО.
ок
а какая проблема с мобилными клиентами? они могут обращатся по http polling
просто нет готового решения? надо каждому самому писать?
а это работает например если у тебя 5 таких машин? например поставили редис общий, каждая машины получает пачку клиентов на websocket. Кидаю сообщение в очередь в редисе, откуда мне знать что это сообщение возьмет из редиса имена та машина на которой подлючин этот клиент? а как быть если это xhr-poll?
можешь обьяснить как это может работать кластером?
Если я правильно понел это когда подключать надо несколько packages "Multiples copies of a Go package"
а вам не как не мешает что есть несколько серверов и очередь с пушами у всех своя. Если один такой взял себе 3K пуши у тут же умер то пуши пропали. И там всякий расекондишен. Например пуш номер один не ждёт в одной очереди длиной на одной машине а второй пуш тому же клиенту послался сразу, так они придут не том порядке. Может лудше было сделать внешнию общию очередь которая раскидывается разными машинами?

Information

Rating
Does not participate
Location
Мерказ, Израиль
Registered
Activity