В этой статье я хотел бы поделиться способом профилирования и трассировки программ на Go. Я расскажу, как можно это делать, сохраняя код гибким и чистым.

TL;DR

Логирование, сбор метрик и все, что не связано с основной функциональностью какого-либо кода, не должно находиться внутри этого кода. Вместо этого нужно определить точки трассировки, которые могут быть использованы для измерения кода пользователем.

Другими словами, логирование и сбор метрик – это подмножества трассировки.

Шаблонный код трассировки может быть сгенерирован с помощью gtrace.

Предлагаю вам перевод статьи Gary Willoughby «Interesting ways of using Go channels».

Статья предназначена для тех, кто уже немного разбирается в Go.

Интересные способы использования Go каналов

Я написал этот пост, чтобы задокументировать доклад про Go каналы Джона Грэм-Камминга на конференции GopherCon 2014. Доклад назывался «Краткое руководство по каналам» и он доступен для просмотра на youtube.com.

На протяжении доклада нам представляют интересные способы использования Go каналов и раскрывают возможности и преимущества конкурентного программирования. Лично мне этот доклад открыл глаза на несколько новых способов структурирования программ и новых техник для синхронизации по нескольким ядрам процессора.

Следующие примеры демонстрируют различные техники, как использовать каналы в Go. Код был специально упрощен для их понимания. Не стоит его использовать для продакшн версий. Например, пропущены все обработки ошибок.

Привет, Хабр! Это второй пост в серии из трех частей, которая даст представление о механике и семантике работы планировщика в Go. Этот пост посвящен планировщику Go.

В первой части этого цикла я объяснил аспекты планировщика операционной системы, которые, на мой взгляд, важны для понимания и оценки семантики планировщика Go. В этом посте я объясню на семантическом уровне, как работает планировщик Go. Планировщик Go — сложная система, и мелкие механические детали не важны. Важно иметь хорошую модель того, как все работает и ведет себя. Это позволит вам принимать лучшие инженерные решения.

При обработке входящего HTTP запроса требуется выполнить большое количество действий, таких как:

• Логирование входящего HTTP запроса
• Проверка на допустимость HTTP метода
• Выполнение аутентификации (basic, MS AD, ...)
• Проверка валидности token (при необходимости)
• Считывание тела (body) входящего запроса
• Считывание заголовка (header) входящего запроса
• Собственно обработка запроса и формирование ответа
• Установка HSTS Strict-Transport-Security
• Установка Content-Type для исходящего ответа (response)
• Логирование исходящего HTTP ответа
• Запись заголовка (header) исходящего ответа
• Запись тела исходящего ответа
• Обработка и логирование ошибок
• Обработка defer recovery для восстановления после возможной panic

Большинство этих действий являются типовыми и не зависят от типа запроса и его обработки.
Для продуктивной эксплуатации на каждое действие необходимо предусмотреть обработку ошибок и логирование.

Повторять все это в каждом HTTP обработчике крайне неэффективно.

Даже если вынести весь код в отдельные подфункции, все равно получается примерно по 80-100 строк кода на каждый HTTP обработчик без учета собственно обработки запроса и формирования ответа.

Ниже описан используемый мной подход, по упрощению написание HTTP обработчиков на Golang без использования кодогенераторов и сторонних библиотек.

Этот подход реализован в шаблоне backend сервера на Golang

В преддверии старта нового потока по курсу «Разработчик Golang» подготовили перевод интересного материала.

---

Наш авторитативный DNS-сервер используют десятки тысяч веб-сайтов. Мы ежедневно отвечаем на миллионы запросов. В наши дни DNS-атаки становятся все более и более распространенными, DNS является важной частью нашей системы, и мы должны убедиться, что мы можем хорошо работать под высокой нагрузкой.

dnsflood — это небольшой инструмент, способный генерировать огромное количество udp запросов.

# timeout 20s ./dnsflood example.com 127.0.0.1 -p 2053

Мониторинг систем показал, что использование памяти нашим сервисом росло так быстро, что нам пришлось остановить его, иначе мы столкнулись бы с OOM ошибками. Это было похоже на проблему утечки памяти; существуют различные причины «похожих на» и «реальных» утечек памяти в go:

В данной статье хочу рассказать о том, как имея уровень английского “после школы и универа” я смог достичь уровня, достаточного для довольно комфортного и успешного прохождения собеседования в иностранную фирму. Полагаю, что российских специалистов с похожим уровнем владения английским достаточно много, как много и тех, кто желает устно общаться с иностранными коллегами. Как мне кажется, методика, к которой я пришел путем проб и ошибок оказалась достаточно простой, чтобы быть эффективной. К тому же, я имею привычку подробно трекать затраченное время. Поэтому, надеюсь, статья также сформирует у вас примерное видение необходимых турдозатрат.