И снова в нашей ленте «Календарь тестировщика». В этом месяце Марина Третьякова, тестировщик проекта Контур.Поставки, расскажет об оптимизации тестов. Марина разберет конкретные проблемы и способы их решения, а также посоветует, как оптимизировать свои тесты и сократить время на тестирование.

Ключевой задачей высоконагруженных WEB-систем является способность обработать большое число запросов. Решить эту проблему можно по-разному. В этой статье я предлагаю рассмотреть необычный метод оптимизации запросов к backend через технологию content-range (range). А именно — сократить их количество без потери качества системы путем эффективного кеширования.

[Прим. переводчика. Материал статьи относится к Windows Server 2003/2003R2/2008/2008R2, но большинство из описанного справедливо и для более поздних версий ОС]

Всем привет! Уоррен снова здесь, и этот пост в блоге представляет собой подборку наиболее распространенных проблем DFSR, с которыми я столкнулся за последние несколько лет. Цель этого поста — перечислить распространенные ошибки в конфигурации DFSR, из-за которых возникают эти проблемы, и уберечь вас от совершения аналогичных ошибок. Знать, чего делать не следует, так же важно, как знать, что нужно делать. Многие из описанных пунктов связаны с другими темами, поэтому для углубленного изучения вопроса предоставлены соответствующие ссылки.

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

Тем, кто пропустил первую часть или хочет вспомнить первую часть можно пройти сюда.

Для тех кто понимает, что такое автомат и УЗО, для чего они необходимы, что и от чего защищают – переходите к разделу Нужны ли УЗО для IT-оборудования, серверной, ЦОДа?.

Часть вторая

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

Добрый день, друзья! Сегодня у нас будет статья, цель которой — поделиться опытом и показать ключевые особенности и частые ошибки возникающие при проектировании и организации подсистем электроснабжения ИТ-инфраструктуры и ЦОД в целом. Но хотелось бы немного расширить аудиторию и посвятить несколько разделов базовым элементам обеспечения электробезопасности и защиты оборудования и людей. Для тех кто понимает, что такое автомат и УЗО, для чего они необходимы, что и от чего защищают – переходите к разделу Нужны ли УЗО для IT-оборудования, серверной, ЦОДа? кроме того, мы разберемся в вопросе- в каких случаях перебоев в сети питания операционная система гарантированно должна работать без сбоев. Итак…

Часть первая

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

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

1. REST-интерфес;
2. WEBSocket broadcast subscription.

Метод REST зачастую используется для получения исторических данных, в то время, как по WEBSocket рассылается актуальная информация в режиме online. В некоторых случаях WEBSocket вообще не используется, а обновление происходит регулярными запросами через REST.

И вроде все довольны. Но, при более детальном рассмотрении, становится очевидными огромные накладные расходы на такую концепцию. Их основная масса ложится на REST. Для обеспечения функционирования REST-интерфейса мы должны создать backend отвечающий требованиям высоконагруженных систем. Естественно, тут можно выбирать различные варианты решения от PHP до нынче модного Golang.

Также требуется создать высокодоступную инфраструктуру, реализовать такие мелочи как CI/CD для сервисов, обеспечить все это нужными спецами по разработке, сопровождению, и т.д., и т.п.

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

Мы начали обновлять в нашем сервисе мониторинг для PgBouncer и решили все немного причесать. Чтобы сделать всё годно, мы притянули самые известные методологии перформанс мониторинга: USE (Utilization, Saturation, Errors) Брендана Грегга и RED (Requests, Errors, Durations) от Тома Уилки.

Под катом рассказ с графиками про то, как устроен pgbouncer, какие у него есть конфигурационные ручки и как используя USE/RED выбрать правильные метрики для его мониторинга.

Автор электронной книги — Эдди Османи, один из руководителей разработки Google Chrome

tl;dr

Cжатие изображений всегда должно быть автоматизировано

Оптимизацию графики обязательно надо автоматизировать. О ней легко забыть, рекомендации меняются, да и сам контент может легко проскользнуть мимо конвейера сборки. Для автоматизации при сборке используйте imagemin или libvips. Есть и много других.

Большинство CDN (например, Akamai) и сторонних решений вроде Cloudinary, imgix, Fastly Image Optimizer, Instart Logic SmartVision и ImageOptim API предлагают комплексные автоматизированные решения для оптимизации изображений.

На чтение статей и настройку конфигурации вы потратите время, которое дороже оплаты их услуг (у Cloudinary есть бесплатный тариф). Но если всё-таки не хотите отдавать работу на аутсорсинг по соображениям стоимости или из-за дополнительной latency, то выбирайте приведённые выше варианты с открытым исходным кодом. Проекты Imageflow или Thumbor предлагают альтернативу на собственном хостинге.

До сих пор проблема накопления (аккумулирования) электроэнергии существовала без каких-либо глобальных изменений, технологического прорыва в данной области никто предложить не мог. Это был тот самый аккумулятор Гастона Планте 1859 года, доработанный различными вспомогательными технологиями и оснащенный усовершенствованиями в области электрохимических процессов, борьбы с выделением водорода, другими материалами корпуса и пр. На рубеже начала 2000 годов появились различного вида литиевые аккумуляторы, которые уверенно вытесняют во всех областях стандартные щелочные, кальциевые, AGM и гелевые аккумуляторы. В данный момент литий-ионные и литий-полимерные аккумуляторы уже завоевали рынок бытовых устройств, технология отработана и позволяет делать АКБ любой формы, ёмкости и размеров. Пришло время отработанных промышленных решений на базе литиевых аккумуляторов. Предлагаю разобраться, почему в серверных и ЦОДах за этой технологией будущее…

На заре карьеры я работал в компании, которая выпускала систему управления контентом. Эта CMS помогала отделам маркетинга самостоятельно управлять сайтами, а не полагаться на разработчиков при каждом изменении. Система помогла клиентам сократить операционные расходы, а мне — научиться создавать веб-приложения.

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

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

Если вы начали работу в таком окружении, а затем приступили к созданию и развёртыванию веб-приложения с нуля, то очень быстро узнаете, что такое «до опасного поверхностные знания».

Сайты по-прежнему загружаются слишком медленно. В самый критический момент процесса загрузки канал зачастую практически полностью простаивает. Новая технология, предложенная инженером Кадзухо Оку из Fastly, поможет лучше использовать эту критическую первую пару секунд.

Вы когда-нибудь загружали сайт на телефоне — и смотрели в течение 10 секунд на страницу без текста? Никто не любит сидеть и глядеть на пустой экран, пока загружается какой-то необычный шрифт. Поэтому есть смысл перенести загрузку таких важных вещей на максимально раннее время. Предзагрузка Link rel=preload должна была частично решить проблему. Первым делом браузер парсит HTTP-заголовки, так что это идеальное место, чтобы указать на предварительную загрузку ресурса, который точно понадобится позже.

Несколько месяцев назад в ходе работы над очередным проектом, ребята из нашей исследовательской лаборатории проводили исследование NVMe-дисков и софтверных решений, с целью найти оптимальный вариант для сборки программного массива.

Результаты тестов тогда были удивительно обескураживающими — огромный потенциал скорости NVMe-дисков совершенно не соотносился с демонстрируемой производительностью имеющихся программных продуктов.

Мы давно стремимся быть максимально открытыми и делиться опытом, пусть и не всегда идеальным. Это помогает не только находить узкие места у себя в разработке, но и пробовать что-то новое.

И если в текстовом формате мы не первый раз рассказываем истории из разработки, то теперь решили организовать митап в сентябре вместе с друзьями из DevGAMM, где будем на реальных кейсах разбирать архитектуру в глобальном понимании — от системных решений и приложений до архитектурных паттернов и стилей. И в этот раз мы решили уйти от традиционного стиля «митапов», поэтому — всего 222 отобранных приглашенных, актуальные темы и крутой нетворкинг на митапе (А|а)рхитектура.

А для тех, кто заинтересовался — под катом FAQ и подробности.

Решения для работы с RAID-массивами из жестких дисков используются уже очень давно. В целом они продолжают оставаться популярными во многих областях, когда требуется относительно недорогой отказоустойчивый массив большого объема. Учитывая размеры современных винчестеров, их скорость, а также и другие причины, наибольший практический интерес вызывают массивы RAID6 (или RAID60, если дисков много). Но этот тип массивов имеет невысокую производительность на операциях случайной записи и сделать что-либо с этим непросто.

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

«Команда @Cloudflare только что внесла изменения, которые значительно улучшили производительность нашей сети, особенно для самых медленных запросов. Насколько стало быстрее? Мы оцениваем, что экономим интернету примерно 54 года времени в день, которое иначе было бы потрачено на ожидание загрузки сайтов». — твит Мэтью Принса, 28 июня 2018 года

10 миллионов сайтов, приложений и API используют Cloudflare, чтобы ускорить загрузку контента для пользователей. В пике мы обрабатываем более 10 миллионов запросов в секунду в 151 дата-центре. За годы мы внесли много изменений в нашу версию Nginx, чтобы справиться с ростом. Эта статья об одном из таких изменений.

Файловая система proc (в дальнейшем просто procfs) является виртуальной файловой системой, которая предоставляет информацию о процессах. Она — “прекрасный” пример интерфейсов следующих парадигме “все является файлом”. Procfs была разработана очень давно: во времена, когда серверы в среднем обслуживали несколько десятков процессов, когда открыть файл и вычитать информацию о процессе не было проблемой. Однако время не стоит на месте, и сейчас серверы обслуживают сотни тысяч, а то и больше процессов одновременно. В таком контексте идея “открыть файл для каждого процесса, чтобы вычитать интересующие данные” уже не выглядит такой привлекательной, и первое что приходит на ум чтобы ускорить чтение — это получение информации о группе процессов за одну итерацию. В этой статье мы попробуем найти элементы procfs которые можно оптимизировать.

Материал, перевод которого мы публикуем сегодня, посвящён рассказу о том, как в Airbnb оптимизируют серверные части веб-приложений с прицелом на всё более широкое использование технологий серверного рендеринга. В течение нескольких лет компания постепенно переводила весь свой фронтенд на единообразную архитектуру, в соответствии с которой веб-страницы представляют собой иерархические структуры React-компонентов, наполняемые данными из их API. В частности, в ходе этого процесса шёл планомерный отказ от Ruby on Rails. На самом деле, Airbnb планирует переход на новый сервис, основанный исключительно на Node.js, благодаря которому в браузеры пользователей будут попадать полностью готовые страницы, отрендеренные на сервере. Этот сервис будет формировать большую часть HTML-кода для всех продуктов Airbnb. Движок рендеринга, о котором идёт речь, отличается от большинства используемых компанией бэкенд-сервисов в силу того, что он не написан на Ruby или Java. Однако отличается он и от традиционных высоконагруженных Node.js-сервисов, вокруг которых построены ментальные модели и вспомогательные инструменты, используемые в Airbnb.

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

До того как встретиться с Big Data и Spark, в частности, мне довелось много и часто оптимизировать SQL запросы, сначала для MSSQL, потом для Oracle, и вот теперь я столкнулся со SparkSQL.

И если для СУБД уже существует множество хороших книг, описывающих методологию и «ручки», которые можно покрутить для получения оптимального плана запроса, то для Spark такого рода книг я не встречал. На глаза попадались больше статьи и наборы практик, причем больше относящиеся к работе через RDD/Dataset API, а не чистому SQL. Для меня одной из эталонных книг на тему оптимизации SQL является книга Дж. Льюис «Oracle. Основы стоимостной оптимизации». Что-то подобное по глубине проработки я и искал. Почему предметом исследования стал именно SparkSQL, а не API, лежащий в основе? Тут интерес был вызван особенностями проекта, над которым я работаю.

Какое-то время назад один мой коллега рассказал, что место в ДЦ кончается, сервера ставить больше некуда, а нагрузка растет и непонятно, что делать, и наверно придется все имеющиеся сервера поменять на более мощные.

Я в это время занимался задачей составления оптимальных расписаний, и подумал — а что, если применить оптимизационные алгоритмы для повышения утилизации серверов в ДЦ? Отсюда и родился проект, про который я хочу написать.

Для продвинутых сразу скажу, что в этой статье речь пойдет про bin packing, а остальным, кто хочет узнать, как с помощью относительно несложных расчетов сэкономить до 30% серверных ресурсов, добро пожаловать под кат.