Видео докладов с Go 1.8 release party Moscow

    image

    16 февраля Golang-сообщество устроило глобальный сбор в честь релиза версии 1.8. На московскую release party в офисе Avito собрались более 150 «гоферов» и сегодня мы публикуем видео-записи докладов.


    «Go 1.8»
    Вячеслав Бахмутов (Dropbox / GolangShow)




    Слайды доклада

    «Golang в Avito»
    Сергей Орлов, Вячеслав Крюков, Андрей Скоморохов (Avito)






    «Как 200 строк на Go помогли нам освободить 15 серверов»
    Паша Мурзаков (Badoo)






    «Миллион открытых каналов с данными по сети»
    Илья Биин (Zenhotels)






    Фото со встречи выложены на нашей странице в FB. За анонсами митапов московского Golang-комьюнити следите на meetup.com. Видео-записи докладов с предыдущих митапов, прошедших в Avito, можно найти на нашем YouTube-канале. До новых встреч!
    • +31
    • 9,2k
    • 7
    Avito 319,91
    Avito – сайт объявлений №1 в России
    Поделиться публикацией
    Похожие публикации
    Комментарии 7
    • +2
      В докладе «Миллион открытых каналов с данными по сети», автор упоминает о проблеме Head-of-Line Blocking в разрезе блокировок при последовательном чтении TCP пакетов, JRPC и д.р.
      К счастью избежать данную проблему легко:
      • сначала читаем данные, потом параллельно обрабатываем
      • читаем доступные данные и асинхронно обрабатываем

      • 0
        Совершенно согласен. Если проблема в неполучении данных из-за сети, то предложенное решение ее все равно не решит. Если же сетевых проблем между серверами нет, то проблема HoLB решается до безобразия просто — сначала прочитай пришедшие к тебе данные и только потом их обрабатывай. И я уверен что многие тысячи подобных кейсов решены именно таким способом без велокрафтинга. Единственный случай, при котором такой подход не будет работать — это когда объем передаваемого сообщения превышает объем оперативной памяти ноды, но что-то мне подсказывает, что у автора доклада, который одной нодой по его словам обрабатывает миллионы одновременных подключений, не этот случай.
        • 0
          Как-раз именно тот случай. Там дикие объёмы данных перегоняются. :)
          • 0
            Если так, тогда да, это смотрится как весьма хитрое инженерное решение =)
            • 0
              К сожалению, доклад из-за временных рамок не мог вместить всякого хитрого, поэтому автор вынужден был скакать по верхам. За подробностями лучше его терроризировать, вона, он ниже отписал, mohtep звать. :)
      • +3
        Увы. Ваше предложение корректно, но только в случае, если память бесконечна. То есть мы должны вычитать объем данных предназначавшихся для неактивного воркера. Если этот объем велик, то мы достаточно агрессивно начнем тратить хип.
        • –1
          Если речь про «неактивных воркеров», тем более не стоит изобретать велосипед. Вариантов реализации механизма отложенных вычислений великое множество.
          Про память, этот вопрос тоже легко решается, даже с велосипедом. Из пула читающих воркеров, данные складываются в буфер нужного бизнес воркера. Буфер может быть локальный (например кольцевой), внешний (например очередь).

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое