Привет, Хабр! Я работаю старшим Go-разработчиком в «Лаборатории Касперского». Сегодня хочу поговорить о том, как искать узкие места и оптимизировать код на Go. Разберу процесс профилирования и оптимизации на примере простого веб-сервиса — покажу, с помощью каких встроенных инструментов искать функции, активнее всего использующие CPU и память. Расскажу, какие можно применять подходы, чтобы повысить производительность. Хотя речь пойдет о микрооптимизации, в моем примере шаг за шагом производительность удалось поднять в 5 раз!

Приехала я год назад к друзьям играть в настолки. А они ссорятся. Из-за того, что Маша сказала Саше вынести мусор / убрать носки / погулять с хомяком, а он не сделал, потому что тупо забыл. Рассказала я Саше и Маше про ToDoList и таск-трекеры и нарисовала им на холодильнике импровизированную асану. Маша наклеила стикеры с задачами и сроками, Саша терпеливо кивнул. Настолки состоялись.

Недавно я снова заглянула в гости. Стикеры на холодильнике висят, а Маша и Саша опять ссорятся. Точнее, громко выясняют, кто хотел починить стол / вывести холодильник / искупать кота, кто по-факту должен был это делать, и почему до сих пор ничего не сделано. Я промолчала, т.к. в чужие семейные разборки со своим PMBOK-ом не лезут.

Но потом решила, что всё нормально, лезут, т.к. вспомнила, что видела RACI-матрицу для распределения ответственности с шуточным объяснением через поездку семьи на дачу. Полезла искать эту картинку для Саши с Машей, нашла, а в ней куча ошибок:



Простите. Не могу промолчать. Не надо так.

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

Даниил Подольский, хоть и евангелист Go, тоже встречает в нем много странного. Все странное и, главное, интересное, собирает и тестирует, а потом рассказывает об этом на HighLoad++. В расшифровке доклада будут цифры, графики, примеры кода, результаты работы профайлера, сравнение производительности одних и тех же алгоритмов на разных языках — и все остальное, за что мы так ненавидим слово «оптимизация». В расшифровке не будет откровений — откуда же они в таком простом языке, — и всего, о чем можно прочесть в газетах.

В прошлой части мы разобрали основные принципы работы с протоколом MAVLink и научились обмениваться сообщениями типа HEARTBEAT. В этой части мы рассмотрим некоторые другие типы сообщений, которые отвечают за полётные данные и попробуем эти данные визуализировать при помощи Qt.

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

TL;DR

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

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

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

Введение

Прежде всего определимся с терминами. Есть много разных представлений о том, кто же такой full stack разработчик, кто-то даже вполне обоснованно считает, что такие разработчики — это миф, но в этой статье будет иметься в виду разработчик, который обладает знаниями и умениями, позволяющими с нуля написать некий софт и вывести его в продакшн. При этом софт может быть рассчитан на web платформу, мобильные приложения или десктопные. Идеальный full stack разработчик — это тот, кто владеет в какой-то мере всеми платформами и может разработать и установить на них свой софт. Но это действительно скорее миф.

Возможно, по заголовку кому-то покажется, что это жалобный пост, который говорит о том, как плохо живётся неквалифицированному школьнику, который похватал всего из разных статей в интернете. Нет, пост не жалобный, мы говорим про full stack, а не full slack, и в конце будет так же рассмотрен список плюсов. И мы будем рассматривать не школьника, а разработчика с опытом работы в пять и более лет. Просто посмотрим, какие минусы есть в таком развитии.

Зачем?

Вопрос “Зачем?” — самый главный при принятии любого решения. В нашем случае причин было несколько.

Во-первых, люди. Текущий шаблонизатор обрабатывался Си. Все вопросы о его изменениях решались не быстро. А самое главное, что писали шаблонизатор одни люди, а использовали совсем другие.

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

Но в Mail.Ru Group есть целая команда высококвалифицированных людей, знающих JS, способных самостоятельно написать инструмент, а самое главное — они же им и будут пользоваться.

Во-вторых, задачи. Возьмем проект Почта@Mail.ru. Мы не можем отказаться от шаблонизации на сервере – нам нужна быстрая загрузка при первом входе. Мы не можем отказаться от шаблонизации на клиенте – люди должны видеть высокую скорость реакции на их действия, а значит, обязателен AJAX и шаблонизация на клиенте.

Проблема очевидна: два набора совершенно разных шаблонов на сервере и на клиенте. А самое обидное, что решают они одну и ту же задачу. Дублирование логики нас просто измотало.

v8 — это интерпретатор JavaScript, а значит, мы можем получить один шаблон, который работает как на сервере, так и на клиенте.

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

Привет, Хабр! Мы продолжаем делиться технологической кухней Retail Rocket. В сегодняшней статье мы разберем вопрос выбора БД для хранения больших и часто обновляемых данных.

На самом начальном этапе разработки платформы перед нами возникли следующие задачи:

• Хранить у себя товарные базы магазинов (т.е. сведения о каждом товаре всех подключенных в нашу платформу магазинов с полным обновлением 25 млн. товарных позиций каждые 3 часа).
• Хранить рекомендации для каждого товара (около 100 млн. товаров содержит от 20 и более рекомендуемых товаров для каждого ключа).
• Обеспечение стабильно быстрой выдачи таких данных по запросу.

В ноябре мы запускаем онлайн-курс «Алгоритмы: теория и практика. Методы» от Computer Science центра. Курс бесплатный, приглашаются все желающие. В курсе будут подробно разобраны базовые алгоритмические методы: жадные алгоритмы, метод «разделяй и властвуй», динамическое программирование. Для всех алгоритмов будут математически строго доказаны корректность и оценки на время работы. Мы постарались изложить материал так, чтобы были понятны и сами алгоритмы, и то, как можно было бы догадаться до их основных идей. Помимо теоретических основ, будут рассказаны тонкости реализации алгоритмов на языках программирования C++, Java и Python. В частности, будет рассказано, какие есть общие практики написания кода, позволяющие минимизировать вероятность ошибки, как писать и тестировать код, где стоит использовать стандартные методы, а не изобретать колесо.

Мы тщательно подобрали задачи для закрепления материала. Большинство алгоритмов, которые вы узнаете, вам нужно будет запрограммировать. Это лучший способ убедиться, что вы разобрались во всех деталях. Решая такие задачи, вы получите ценный опыт написания и отладки эффективных и надёжных программ. Задачи на программирование помогут вам почувствовать разницу между плохим (медленным) и хорошим (быстрым) алгоритмом. Вас также ждут тесты (где нужно выбрать правильные ответы из предложенных) и теоретические задачи (в них нужно доказать математическое утверждение). Наконец, в курсе есть также задачи повышенной сложности — менее стандартные задачи, которые не являются обязательными для прохождения курса. Получить удовольствие от решения этих задач смогут и те, кто уже знаком с базовыми алгоритмами.

В настоящее время, благодаря таким инструментам как NodeJS, создание веб-приложения — сущий пустяк. Скачал бинарник, сваял js в 5 строчек кода и можно хвастаться. А если подключить express и добавить ещё 5 строчек, то получим полноценное веб-приложение с роутингом, шаблонами, сессиями и другими прелестями. Так просто, что даже скучно. И стало мне интересно: как обстоят дела у моего старого знакомого С++, с которым уже 5 лет не виделся. В своё время прельстил меня ActionScript и прочий JavaScript, а о добром друге, который не раз выручал, совсем позабыл. В свете недавних статей о Configurable Omnipotent Custom Applications Integrated Network Engine (сокращено Cocaine), попался мне на глаза проект под названием Fastcgi Daemon, на основе которого функционирует HTTP-интерфейс Cocaine. И так, знакомьтесь

Недавно Владимир Подольский vpodolskiy, аналитик в департаменте по работе с образованием IBS, закончил обучение по специализации Data Science на Coursera. Это набор из 9 курсеровских курсов от Университета Джонса Хопкинса + дипломная работа, успешное завершение которых дает право на сертификат. Для нашего блога на Хабре он написал подробный пост о своей учебе. Для удобства мы разбили его на 2 части. Добавим, что Владимир  стал еще и редактором проекта по переводу специализации Data Science на русский язык, который весной запустили IBS и ABBYY LS.

Часть 1. О специальности Data Science в общих чертах. Курсы: Инструменты анализа данных (программирование на R); Предварительная обработка данных; Документирование процесса обработки данных.

Привет, Хабр!

Не так давно закончился мой 7-месячный марафон по освоению специализации «Наука о данных» (Data Science) на Coursera. Организационные стороны освоения специальности очень точно описаны тут. В своём посте я поделюсь впечатлениями от контента курсов. Надеюсь, после прочтения этой заметки каждый сможет сделать для себя выводы о том, стоит ли тратить время на получение знаний по аналитике данных или нет.

Надеюсь, что данный материал будет кому-нибудь полезен.

Siege – это утилита для нагрузочного тестирования веб-серверов. Она была создана для того чтоб дать разработчикам возможность проверить ресурсоёмкость своего кода в условиях, максимально приближенных к реальным. Так же Siege может имитировать обращения к сайту сразу нескольких пользователей. Это позволяет держать сервер как бы «под осадой» долгое время. Количество запросов, произведённых при «осаде», рассчитывается из общего количества пользователей и количества их обращений к серверу. Например 20 пользователей, обратившись по 50 раз, создают в общей сложности 1000 запросов. Результат, выводимый программой после тестирования, включает в себя время затраченное на проверку, общее количество переданной информации ( включая заголовки ), среднее время ответа сервера, его пропускную способность и число запросов на которые пришёл ответ с кодом 200. Эти данные формируются и выдаются при каждой проверке. Подробно они описываются ниже. Siege имеет 3 основных модели работы – режим регрессионного тестирования, режим имитации Интернета и режим грубой силы. Программа считывает порцию ссылок из конфигурационного файла и обращается к ним по очереди ( режим регрессионного тестирования ) или случайно ( имитация интернета ). Или же пользователь может указать один единственный адрес к которому будут производиться все обращения – режим грубой силы.

UPD: спасибо за плюсы, перенес в тематический блог.

Обзор практически всех *top утилит под linux (atop, iotop, htop, foobartop и т.д.).

top

Все мы знаем top — самую простую и самую распространённую утилиту из этого списка. Показывает примерно то же, что утилита vmstat, плюс рейтинг процессов по потреблению памяти или процессора. Совсем ничего не знает про загрузку сети или дисков. Позволяет минимальный набор операций с процессом: renice, kill (в смысле отправки сигнала, убийство — частный случай). По имени top суффикс "-top" получили и все остальные подобные утилиты в этом обзоре.

atop

Atop имеет два режима работы — сбор статистики и наблюдение за системой в реальном времени. В режиме сбора статистики atop запускается как демон и раз в N времени (обычно 10 мин) скидывает состояние в двоичный журнал. Потом по этому журналу atop'ом же (ключ -r и имя лог-файла) можно бегать вперёд-назад кнопками T и t, наблюдая показания atop'а с усреднением за 10 минут в любой интересный момент времени.

В отличие от top отлично знает про существование блочных устройств и сетевых интерфейса, способен показывать их загрузку в процентах (на 10G, правда, процентов не получается, но хотя бы показывается количество мегабит).

Незаменимое средство для поиска источников лагов на сервере, так как сохраняет не только статистику загрузки системы, но и показатели каждого процесса — то есть «долистав» до нужного момента времени можно увидеть, кто этот счастливый момент с LA > 30 создал. И что именно было причиной — IO программ, своп (нехватка памяти), процесор или что-то ещё. Помимо большего количества информации ещё способен двумя цветами подсказывать, какие параметры выходят за разумные пределы.

Для организации работы веб-карт по технологии Slippy Map требуется организовать тайловое хранилище, в котором могут предварительно рендериться (генерироваться) тайлы в заранее заданном контексте карты, либо использоваться набор сервисов для генерации тайлов по запросу, либо некий симбиоз из первых двух подходов.
Первый подход имеет недостаток — требуется слишком большое хранилище для тайлов. Так, по данным OpenstreetMap по состоянию на март 2011 года требовалось 54ТБ места для хранения тайлов. По моим подсчетам для актуальных данных на июнь 2015 года эта цифра уже составляет около 100ТБ (это только оценка, на реальный эксперимент я не решился) для хранения тайлов масштабов 0...17. Такой «прирост» оценок вызван тем, что за прошедшее время данные OpenStreetMap существенно пополнились, детализировались районы, которые в марте 2011 года были пустыми. Нельзя также списывать со счетов неоптимальность сжатия (в моем случае по сравнению с OpenStreetMap) формата PNG (у меня средний размер тайла составляет 4.63КБ против 633 байт OpenStreetMap'а в марте 2011 года), сложность стиля рисования карты mapnik'ом и прочие мои нюансы. В любом случае требуется ОЧЕНЬ много места для тайлового хранилища, что может себе позволить далеко не каждый сервер. Ситуация усугубляется еще и тем, что для блочных файловых систем маленькие по размеру тайлы расходуют целый блок (тайл размером 103 байта может занимать целый блок, например, 4КБ), что приводит к неэффективному расходованию физического пространства жесткого диска. Для большого количества тайлов (для крупных масштабов карт) в рамках одной директории может еще наблюдаться проблема невозможности хранения требуемого количества файлов либо директорий больше, чем позволяет файловая система. Но при всем при этом данный поход обеспечивает комфортное время выполнения запроса на отдачу тайла.
Второй подход хоть и не требователен к емкости тайлового сервера, но требует организовать и поддерживать несколько сервисов (PostgreSQL, Postgis, HStore, mapnik, renderd, mod_tile, apache), которые бы надежно генерировали и отдавали тайл запрашиваему клиентскому сервису. Также требуется периодически подчищать кэш тайлов. Иными словами платой за небольшую емкость жесткого диска тайлового сервера является сложность архитектуры и значительное время выполнения запроса на отдачу каждого конкретного тайла (по моим подсчетам до 500мс только для 1 клиента, для высоконагруженного сервиса это время может вырасти до неприемлемых величин).

Цены на жильё формируются из многочисленных факторов, основные из которых — это близость к центру города и наличие рядом различной инфраструктуры. Но реальные цены только в бумажных газетах и риэлторских сайтах. Мы будем строить свою карту с ценами на недвижимость в Москве при помощи python, яндекс API и matplotlib, специальный репортаж с места событий под катом.

Рост аудитории интернет-пользователей и интернет-проектов выводит геосервисы на новый уровень.
Если раньше большинство проектов с использованием «карт» оперировали с десятками и сотнями точек, то сейчас уже речь идет о сотнях тысяч точек.
В статье будут рассмотрены несколько юзкейсов для геосервисов и способы их реализации для google API 3 и нового yandex API 2.

Занимаясь разработкой веб-карт, использующих данные OpenStreetMap, часто возникает вопрос о том, как показывать карты с корректными русскими названиями. Этой проблемы не возникает, если ваши карты показывают исключительно Россию. Однако, если вы посмотрите, например, карту Китая, то вам вряд ли понравится такое обилие иероглифов, а тщетные попытки найти Пекин на такой карте, скорее всего, не увенчаются успехом.



Известно, что свободолюбивый проект OpenStreetMap позволяет сохранять названия географических объектов на разных языках. Для этого используются специальные теги, типа name:ru, name:en или name:es, и что самое главное, они заполняются участниками OpenStreetMap. Конечно, наиболее подробные надписи создают пользователи на том языке, на котором они говорят: в России — на русском, в Китае — на китайском, в африканских странах — на местных языках. Шансов, что какая-то улочка в Нигерии будет иметь русский перевод, мало, но все же основные географические объекты (страны, города, реки и т.п.) имеют переводы. Этой небольшой картографической информации бывает вполне достаточно, чтобы русскоязычный пользователь открыл, например, карту Китая и нашел на ней основные названия. Таким образом, ваш ресурс станет чуть более дружелюбным для пользователя.