Рубрика «высокая производительность» - 68

Zabbix Moscow Meetup 2018 в Badoo: обзор и материалы - 1

Привет!

Меня зовут Илья Аблеев, я работаю в отделе мониторинга компании Badoo. 23 июня мы с коллегами провели очередной Zabbix Moscow Meetup.

В роли спикеров митап посетили представители компаний Zabbix, Badoo, QIWI и Grafana Labs. Мы уделили особенно много времени общению участников и сессии вопросов и ответов с представителями компании Zabbix.

Эта встреча сообщества стала четвёртой по счёту. Когда кто-то говорит о порядковом номере события, обычно выделяют те, которые делятся на пять или десять. Но в нашем случае я бы выделил именно четвёртый митап. Чем он так примечателен? Смотрите и читайте сами — добро пожаловать под кат.
Читать полностью »

PHP 8: чего ждать. Письмо Зеева Сураски - 1

Привет, меня зовут Николай Крапивный, я руковожу отделом server-side разработки в Badoo. В Badoo PHP —  один из основных языков, на нем написана бóльшая часть бизнес-логики нашей системы. Поэтому мы следим за новостями из мира PHP, активно участвуем в развитии языка и стараемся развивать сообщество вокруг PHP.

Сегодня я бы хотел поделиться переводом письма Zeev Suraski, одного из основателей Zend Technologies, которое обрисовывает дальнейшее развитие PHP и проливает свет на то, чего нам ждать в PHP 8.
Читать полностью »

Производительность в iOS или как разгрузить main thread. Часть 1 - 1

Есть разные приёмы и хитрости, которые помогают оптимизировать работу iOS-приложений, когда одна задача должна выполняться за 16,67 миллисекунд. Рассказываем, как разгрузить main thread и какие инструменты лучше подходят для отслеживания стека вызовов в нём.

«Ребята, давайте представим, что вы сможете сократить время запуска на 10 секунд. Умножив это на 5 миллионов пользователей, ежедневно у нас будет 50 миллионов секунд. За год это составит порядка десяти человеческих жизней. Поэтому, если вы сделаете первичную загрузку на 10 секунд быстрее, вы спасёте несколько десятков жизней. Это действительно стоит того, не правда ли?»

Стив Джобс о производительности (времени запуска компьютера Apple II).

Статья основана на докладе iOS-разрабочика из Fyusion Люка Пархема, с которым он выступил на Международной конференции мобильных разработчиков MBLT DEV в прошлом году. Читать полностью »

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

Что нас ждет на Highload++ Siberia, кроме рисованных мишек - 1

Highload++ Siberia хоть и форк уже ставшего традиционным Highload++, но, как и в случае некоторых известных технологий, пойдет своим путем и будет развивать свои собственные традиции. Начнем с достаточно камерного мероприятия — всего два потока, но все доклады отменного качества. Судите сами.
Читать полностью »

Рассказывать, какие есть кэши, что такое Result Cache, как он сделан в Oracle и в других базах данных не очень интересно и довольно шаблонно. Но все приобретает совершенно другие краски, когда речь идет о конкретных примерах. Александр Токарев (shtock) построил свой доклад на Highload++ 2017 исходя из кейсов. И именно опираясь на кейсы, рассказал, когда может быть удобен самодельный кэш, в чем боль server-side Result Cache и как заменить его клиентским, и вообще вывел ряд полезных советов по настройке Result Cache в Oracle.

О спикере: Александр Токарев работает в компании DataArt и занимается вопросами, связанными с базами данных как в части построения систем «с нуля», так и оптимизации имеющихся.

Начнем с нескольких риторических вопросов. Вы работали с Oracle Result Cache? Вы верите, что Oracle — это база данных, удобная на все случаи? По опыту Александра большинство людей на последний вопрос отвечает отрицательно, на сто суровых прагматиков приходится один мечтатель. Но благодаря его вере двигается прогресс.

Кстати, у Oracle уже 14 баз данных — пока 14 — что будет в будущем, неизвестно.

Как уже говорилось, все проблемы и решения будут проиллюстрированы конкретным кейсами. Это будет два кейса из проектов DataArt, и один сторонний пример.
Читать полностью »

Потоковая репликация, которая появилась в 2010 году, стала одной из прорывных фич PostgreSQL и в настоящее время практически ни одна инсталляция не обходится без использования потоковой репликации. Она надежна, легка в настройке, нетребовательна к ресурсам. Однако при всех своих положительных качествах, при её эксплуатации могут возникать различные проблемы и неприятные ситуации.

Алексей Лесовский (@lesovsky) на Highload++ 2017 рассказал, как с помощью встроенных и сторонних инструментов, диагностировать различные типы проблем и как устранять их. Под катом расшифровка этого доклада, построенного по спиральному принципу: сначала мы перечислим все возможные средства диагностики, потом перейдем к перечислению типовых проблем и их диагностике, далее посмотрим, какие экстренные меры можно принять, и наконец как радикально справиться с задачей.

О спикере: Алексей Лесовский администратор баз данных в компании Data Egret. Одной из любимых тем Алексея в PostgreSQL является потоковая репликация и работа со статистикой, поэтому доклад на Highload++ 2017 был посвящен тому, как помощью статистики искать проблемы, и какие использовать методы для их устранения.

План

  1. Немного теории, или как работает репликация в PostgreSQL
  2. Troubleshooting tools или что есть у PostgreSQL и сообщества
  3. Troubleshooting cases:
    • проблемы: их симптомы и диагностика
    • решения
    • меры, которые нужно принимать, чтобы этих проблем не возникало.

Зачем всё это? Эта статья поможет вам лучше разбираться в потоковой репликации, научиться быстро находить и устранять проблемы, чтобы сократить время реакции на неприятные инциденты.
Читать полностью »

Прямой репортаж с рождения крупного игрока в аппаратном AI, который ускоряет TensorFlow и конкурирует с NVidia - 1

Завтра будут официальные пресс-релизы о слиянии старожила Silicon Valley, компании MIPS, с молодой AI компанией Wave Technology. Информация об этом событии просочилась в СМИ вчера, и вскоре CNet, Forbes, EE Times и куча хайтек-сайтов вышла со статьями об этом событии. Поэтому сегодня Derek Meyer, президент объединенной компании (на фото снизу справа), сказал «ладно, распостраняйте инфо среди друзей» и я решил написать пару слов о технологиях и людях, связанных с этим событием.

Главный инвестор в MIPS и Wave — миллиардер Dado Banatao (на фото снизу в центре слева), который еще в 1980-х основал компанию Chips & Technoilogies, которая делала чипсеты для ранних персоналок. В Wave+MIPS есть и другие знаменитости, например Стивен Джонсон (на фото справа вверху), автор самого популярного C-компилятора начала 1980-х годов. MIPS хорошо известен и в России. В руках дизайнерши Смрити (на фото слева) плата из Зеленограда, где находятся лицензиаты MIPS Элвис-НеоТек и Байкал Электроникс.

Wave уже выпустила чип, который состоит из тысяч вычислительных блоков, по сути упрощенных процессоров. Эта конструкция оптимизирована для очень быстрых вычислений нейронных сетей. У Wave есть компилятор, который превращает dataflow граф в файл конфигурации для этой структуры.

Объединенная компания создаст чип, который состоит из смеси таких вычислительных блоков и многопоточных ядер MIPS. Сейчас Wave продает свою технологию в виде ящика для дата-центров, для вычислений нейронных сетей в облаке. Следующие чипы будут использоваться во встроенных устройствах.
Читать полностью »

Летний митап Apache Ignite в Петербурге - 1

Друзья, приглашаем вас на летний митап, посвящённый Apache Ignite. Присоединяйтесь к нашей неформальной встрече пользователей и разработчиков. Будут новые докладчики, новые темы и мороженое. С собой приносите интересные вопросы и летнее настроение.

20 июня, Cанкт-Петербург

Читать полностью »

В первой части своей статьи я рассказал о том, как мы в Badoo создали первую версию системы патчей. Если коротко, то нам нужно было найти способ исправления серьёзных ошибок прямо на production, доступный всем разработчикам. Однако первая версия была не без недостатков: мы использовали своеобразный способ раскладки, который не позволял гарантировать атомарность выкладок патчей и консистентность кода.

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

Patch me if you can: как мы отлаживаемся на production. Часть 2 - 1

Изображение: источник
Читать полностью »

Конкурентная сосиска

Аннотация

Обработка данных в реальном времени ровно один раз (exactly-once) — задача крайне нетривиальная и требующая серьезного и вдумчивого подхода на всей цепочке вычислений. Некоторые даже считают, что такая задача невыполнима. В реальности хочется иметь подход, обеспечивающий отказоустойчивую обработку вообще без каких-либо задержек и использование различных хранилищ данных, что выдвигает новые еще более жесткие требования, предъявляемые к системе: concurrent exactly-once и гетерогенность персистентного слоя. На сегодняшний день такое требование не поддерживает ни одна из существующих систем.

Предложенный подход последовательно раскроет секретные ингредиенты и необходимые понятия, позволяющие относительно просто реализовать гетерогенную обработку concurrent exactly-once буквально из двух компонент.

Введение

Разработчик распределенных систем проходит несколько стадий:

Стадия 1: Алгоритмы. Здесь происходит изучение основных алгоритмов, структур данных, подходов к программированию типа ООП и т.д. Код исключительно однопоточный. Начальная фаза вхождения в профессию. Тем не менее, достаточно непростая и может длиться годами.

Стадия 2: Многопоточность. Далее возникают вопросы извлечения максимальной эффективности из железа, возникает многопоточность, асинхронность, гонки, дебагинг, strace, бессонные ночи… Многие застревают на этом этапе и даже начинают с какого-то момента ловить ничем не объяснимый кайф. Но лишь единицы доходят до понимания архитектуры виртуальной памяти и моделей памяти, lock-free/wait-free алгоритмах, различных асинхронных моделях. И почти никто и никогда — верификации многопоточного кода.

Стадия 3: Распределенность. Тут такой треш творится, что ни в сказке сказать, ни пером описать.

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js