Видео докладов с 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,5k
    • 7
    Avito 251,76
    У нас живут ваши объявления
    Поделиться публикацией
    Похожие публикации
    Комментарии 7
      +2
      В докладе «Миллион открытых каналов с данными по сети», автор упоминает о проблеме Head-of-Line Blocking в разрезе блокировок при последовательном чтении TCP пакетов, JRPC и д.р.
      К счастью избежать данную проблему легко:
      • сначала читаем данные, потом параллельно обрабатываем
      • читаем доступные данные и асинхронно обрабатываем

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

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

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