Введение

В этой статье я расскажу, как профилировать и оптимизировать приложения на языке Go с использованием встроенных и общих инструментов, доступных в ОС Linux.

Что такое профайлинг и оптимизация? Если ваша программа работает недостаточно быстро, использует слишком много памяти, неоптимально использует процессор, вы хотите понять, в чем дело, и исправить — это и есть профайлинг и оптимизация.

Я привел такое определение, чтобы сразу отсечь вопросы некорректной работы приложения. В этой статье мы не будем говорить о проблемах мультитредового программирования, о дата-рейсах (англ. data race), о поиске ошибок (англ. debugging). Для всего этого в Go есть свои утилиты и подходы, но оставим эту тему на будущее.

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



Нередко многие программисты появляются в комментариях к публикациям с «разоблачениями» жутких сммщиков, которые берут баснословные деньги за настройку рекламы, не давая при этом никаких гарантий. Например, в этой публикации, которая стала основным посылом к написанию данного цикла, уважаемый Drizzly утверждает, что:

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

Будучи человеком, который продает настройки таргетинга и услуги по продвижению как во Вконтакте, Фейсбуке, Инстаграмме, Youtube и немножечко SEO, я с ним полностью согласен. Более того, уверен, что это занятие доступно абсолютно любому человеку, имеющему хоть небольшие аналитические способности. И если у вас они есть (раз уж читаете Хабр, то с большой вероятностью есть), добро пожаловать под кат. Возможно, однажды вам придется самостоятельно разместить рекламу в соц сетях, или, как минимум, оценить адекватность работы того, кто попросит у вас за эту настройку деньги. И я искренне надеюсь, что вам пригодится эта серия публикаций. Итак, поехали!

Эта статья основана на материалах презентации, которую я представил в этом году на конференции OSCON. Я отредактировал текст, чтобы он был более лаконичным, а заодно учёл ту обратную связь, что я получил после своего выступления.

Про Go часто говорят, что он хорош для серверов: здесь есть статические бинарники (static binaries), развитый concurrency, высокая производительность. В этой статье мы поговорим о двух последних пунктах: о том, как язык и среда выполнения (runtime) ненавязчиво позволяют Go-программистам создавать легко масштабируемые серверы и не беспокоиться из-за управления потоками (thread) или блокирующих операций ввода/вывода.

В стандартной библиотеке Python 3.4 в своё время появился модуль asyncio, позволивший удобно и быстро писать асинхронный код. А уже к Python 3.5 в синтаксис были добавлены конструкции async/await, окончательно оформившие асинхронность «из коробки» как красивую и гармоничную часть языка.



Хотя asyncio сам по себе и позволяет писать высоконагруженные веб-приложения, оптимизация производительности не была приоритетом при создании модуля.

Один из авторов упомянутого PEP-492 (async/await) Юрий Селиванов (на Хабре — 1st1, его твиттер) взялся за разработку альтернативной реализации цикла событий для asyncio — uvloop. Вчера вышла первая альфа-версия модуля, о чём автор написал развёрнутый пост.

Если вкратце, то uvloop работает примерно в 2 раза быстрее Node.js и практически не уступает программам на Go.

Ниже будет приведен список инструментов мониторинга. Есть как минимум 80 способов, с помощью которых ваша машинка будет под контролем.



1. первый инструмент — top

Консольная команда top- удобный системный монитор, простой в использовании, с помощью которой выводится список работающих в системе процессов, информации о этих процессах. Данная команда в реальном времени сортирует их по нагрузке на процессор, инструмент предустановлен во многих системах UNIX.

Зачитался я последнее время про Tarantool, интересно стало. Идея хорошая — код рядом с базой данных, хранимка в такой быстрой Redis-подобной среде.

И что-то задумался — мы вот сейчас используем активно на работе Golang, собственно, мысль пришла что на Go написано много всего, в т.ч. и встраиваемых баз. А что если сравнить, например, Go+LevelDB (собственно, можно было бы и любую другую) против Tarantool. Тестировал еще Go+RocksDB, но там оказалось все немного сложнее, а результат примерно тот же на небольших данных.

Тестировал простую задачу — HTTP сервер, при запросе — записать ключик в базу, достать его же по имени (без всяких проверок на race), отправить назад простенький JSON из этого value.

Сравнил: go+leveldb, tarantool, go+go-tarantool, nginx upstream tnt_pass

Эта статья рассказывает о времени выполнения и о расходе памяти большинства алгоритмов используемых в информатике. В прошлом, когда я готовился к прохождению собеседования я потратил много времени исследуя интернет для поиска информации о лучшем, среднем и худшем случае работы алгоритмов поиска и сортировки, чтобы заданный вопрос на собеседовании не поставил меня в тупик. За последние несколько лет я проходил интервью в нескольких стартапах из Силиконовой долины, а также в некоторых крупных компаниях таких как Yahoo, eBay, LinkedIn и Google и каждый раз, когда я готовился к интервью, я подумал: «Почему никто не создал хорошую шпаргалку по асимптотической сложности алгоритмов? ». Чтобы сохранить ваше время я создал такую шпаргалку. Наслаждайтесь!

TL;DR: Mandrill захотел поднять цены в 4 раза. Они нашли способ через интеграцию с MailChimp.

В феврале этого года, как гром среди ясного неба, пришло письмо от Mandrill о том, что с 27го апреля он перестаёт существовать как независимый сервис и теперь чтобы им пользоваться нужно будет интегрировать свой Mandrill аккаунт в платный аккаунт MailChimp. Именно платный, пусть даже и самый дешевый. Вот как выглядит ценник MailChimp:



Напомню, что раньше Mandrill был бесплатным для небольших проектов до 12.000 писем в месяц (около 400 в день). Сейчас же как минимум $20 + сколько напосылаешь писем.

Постановка задачи

На днях я увидел на просторах интернета крайне любопытную вещь: мендосинский двигатель. Ротор на подшипниках крайне низкого трения: оригинальный имел стеклянный цилиндр, подвешенный на двух иголках, современные имеют магнитный подвес оси. Двигатель бесколлекторный, на роторе подвешены солнечные батареи, которые выдают напряжение на катушки, намотанные на роторе. Ротор проворачивается в фиксированном магнитном поле статора, солнечная батарея уходит от направленного света, на её место приходит другая. Крайне элегантное решение, которое вполне под силу сделать дома каждому.

Вот на этом видео крайне подробно описан (на русском языке) принцип работы:



Но ещё больше самого двигателя мне показалась любопытной следующая вещь. В описании этого видео Дмитрий Коржевский написал следующую вещь: «Боковую опору заменить магнитом НЕВОЗМОЖНО!!! Не задавайте больше этот вопрос!»

Когда у меня встала необходимость разобраться, как сделать failover или load balancing, имея два и более каналов в мир, я нашел множество статей и инструкций, в которых описывались рабочие конфигурации. Но почти нигде не нашел разъяснения, как все работает, и описания отличий разных вариантов. Хочу исправить эту несправедливость и собрать простейшие варианты построения failover и load balancing конфигураций в одной статье.

Итак, у нас есть роутер, который соединяет нашу локальную сеть и два канала в интернет (основной ISP1 и резервный ISP2).

Давайте рассмотрим что же мы можем сделать:

Сразу предупрежу: несмотря на то, что в этой статье буду все описывать для mikrotik, не буду касаться темы скриптов

(у учебника по Основам React вышло второе издание, Redux-учебник в процессе обновления)

Закончил работу над парой подробных текстовых туториалов на русском. Постарался уделить как можно больше времени практике. По ходу повествования есть вопросы, задачи и решения.

Курс про Redux попал в официальную документацию.

Оба руководства бесплатны и выложены на gitbook (можно скачать PDF, ePub, mobi).

В текстах нарочно участвуют термины переведенные на русский (например, состояние), английские (state), либо английский термин написанный по-русски — стейт. Считаю это допустимым, и даже более того, удобным для читателя.

В своей предыдущей статье по оптимизации сайта на WordPress я рассказал об очень эффективном подходе к оптимизации за счёт кэширования страниц. В результате чего для незалогиненных пользователей время ожидания страницы клиентом (исключая время на установление TLS-сессии) сократилось с 820 мс до 30 мс (этот и все последующие замеры проводились с сервера, расположенного в том же городе, что и мой VDS), что, согласитесь, является отличным показателем. Однако, для залогиненных пользователей генерация страницы происходила по-прежнему долго — в среднем 770 мс на сервере. В этой части я расскажу о том, как я сократил это время до 65 мс, при этом полностью сохранив работоспособность пользовательского функционала.

Целью этой и предыдущей статей является моё желание показать возможность оптимизации сайтов не только на WordPress, а вообще любого веб-приложения. Поэтому я использую такое количество инструментов, и так детально разбираю их конфигурацию. Если же Вам просто нужно ускорить WordPress — установите плагин WP Super Cache. Если Вас, как и меня, интересуют технологии, позволяющие оптимизировать любой сайт, а также Вам интересно, что стоит учитывать при разработке веб-приложений, рассчитанных на высокие нагрузки — прошу под кат, но только после прочтения первой части — дорабатывать я буду ту же систему.

Примечание переводчика: визит под кат этого поста означает большие объёмы потреблённого трафика. И это иронично, если учесть поднятую тему. Но всё сразу встаёт на свои места, если помнить, что в оригинале это было выступление в прошлом ноябре в Сиднее длиной почти в час. Чтение поста занимает куда меньше времени. В форме видеозаписи (1280×720) речь занимает два гигабайта. Пост же занимает всего лишь 12 МиБ. Рекомендуется просмотр на широких мониторах.



Перед началом тирады я хотел бы обратить внимание на то, что прекрасные сайты бывают любых форм и размеров. И я здесь не собираюсь кого-то пристыживать за количество использованных бит, объём использованных ресурсов и так далее. Я люблю большие сочные галереи изображений, мне нравятся огромные эксперименты на JavaScript, я смотрю онлайн-видео в высоком разрешении, как и все вы. Я считаю, что подобное замечательно.

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

Часть 2: Отправка и получение сообщений

В этой серии статей мы рассматриваем процесс создания масштабируемого сервера для чата в реальном времени, во всех деталях. Цель статьи — показать пример практического применения языка Rust на фоне изучения концепций системного программирования и системных API, шаг за шагом.

Вторая часть является прямым продолжением первой, поэтому если вы ее пропустили (или забыли контекст), то рекомендую сначала ознакомиться с ней. В этой части мы продолжаем реализацию протокола WebSocket.

Часть 1: Реализуем WebSocket. Введение.

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

В первой части мы рассмотрим начальную настройку окружения и реализацию простейшего WebSocket-сервера. Чтобы понять технические детали статьи вам не потребуется опыта работы с языком Rust, хотя знание основ системных API (POSIX) и C/C++ лишним не будет. Прежде чем начинать чтение, заготовьте немного времени (и кофе) — статья описывает все максимально подробно и поэтому довольно длинная.

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

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

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

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

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

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

В данной статье я расскажу о том, как я заставил свой блог на WordPress летать за счёт грамотного кэширования, сжатия и другой оптимизации серверной и клиентской сторон. На момент написания статьи характеристики VDS следующие:

CPU: 1 x 2GHz
HDD: 10Gb
RAM: 512Mb
OS: Debian 8 x64

Схема работы системы выглядит следующим образом:

В последнее время всё чаще и чаще слышишь мнение, что сейчас происходит технологическая революция. Бытует мнение, что мир стремительно меняется.



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

Я работаю в области связанной с анализом изображений. Это одна из областей которую новые идеи затронули сильнее всего. Одна из таких идей — свёрточные нейронные сети. Четыре года назад с их помощью впервые начали выигрывать конкурсы по обработке изображений. Победы не остались незамеченными. Нейронными сетями, до тех пор стоящими на вторых ролях, стали заниматься и пользоваться десятки тысяч последователей. В результате, полтора-два года назад начался бум, породивший множество идей, алгоритмов, статей.

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

Кто лишится в ближайшие лет десять работы, а у кого будут новые перспективные вакансии.

Уважаемые хабравчане.

Поскольку дискуссия вокруг статьи идет весьма активно, Жан-Жак Дюбре (он читает комментарии) решил организовать чаты в gitter.

Вы можете пообщаться с ним лично в следующих чатах:
https://gitter.im/jdubray/sam
https://gitter.im/jdubray/sam-examples
https://gitter.im/jdubray/sam-architecture

Также автор статьи разместил примеры кода здесь: https://bitbucket.org/snippets/jdubray/

По поводу кода он оставил следующий комментарий:

I don't code for a living, so I am not the best developer, but people can get a sense of how the pattern works and that you can do the exact same thing as React + Redux + Relay with plain JavaScript functions, no need for all these bloated library (and of course you don't need GraphQL).

Одной из самых сильных сторон языка программирования Go является встроенная поддержка concurrency, основанная на труде Тони Хоара «Communicating Sequential Processes». Go создан для удобной работы с многопоточным программированием и позволяет очень легко строить довольно сложные concurrent-программы. Но задумывались ли вы когда-нибудь, как выглядят различные паттерны concurrency визуально?

Конечно, задумывались. Все мы, так или иначе, мыслим визуальными образами. Если я попрошу вас о чём-то, что включает числа «от 1 до 100», вы мгновенно их «увидите» в своей голове в той или иной форме, вероятно даже не отдавая себе в этом отчёт. Я, к примеру, ряд от 1 до 100 вижу как линия с числами уходящая от меня, поворачивающая на 90 градусов вправо на числе 20 и продолжающая до 1000+. И, покопавшись в памяти, я вспоминаю, что в самом первом детском саду в раздевалке вдоль стены были написаны номерки, и число 20 было как-раз в углу. У вас же, вероятно, какое-то свое представление. Или вот, другой частый пример — представьте круглый год и 4 сезона года — кто-то их видит как квадрат, каждая грань которого принадлежит сезону, кто-то — как круг, кто-то ещё как-то.

Так или иначе, позвольте мне показать мою попытку визуализировать основные паттерны concurrency с помощью Go и WebGL. Эти интерактивные визуализации более-менее отражают то, как я вижу это в своей голове. Интересно будет услышать, насколько это отличается от визуализаций читателей.