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

В 2017 году во время Черной Пятницы нагрузки выросли почти в полтора раза, и наши сервера находились на пределе возможностей. За год количество клиентов значительно выросло, и стало понятно, что без тщательной предварительной подготовки платформа может просто не выдержать нагрузок 2018 года.

Цель поставили самую амбициозную из возможных: мы хотели быть полностью готовыми к любым, даже самым мощным, всплескам активности и начали заранее выводить новые мощности в течение года.

Наш CTO Андрей Чиж (chizh_andrey) рассказывает, как мы готовились к Черной Пятнице 2018, какие меры предприняли, чтобы избежать падений, и, конечно, же о результатах такой тщательной подготовки.

Есть много способов повышения веб-производительности. Один из них — предзагрузка контента, который понадобится позже. Префетчинг CSS, предварительный рендеринг полной страницы или резолвинг доменного имени. Делаем всё заранее, а потом мгновенно отображаем результат! Звучит круто.

Ещё круче, что это очень просто реализовано. Пять тегов <link rel> дают браузеру команду на предварительные действия:

<link rel="prefetch" href="/style.css" as="style" />
<link rel="preload" href="/style.css" as="style" />

<link rel="preconnect" href="https://example.com" />
<link rel="dns-prefetch" href="https://example.com" />

<link rel="prerender" href="https://example.com/about.html" />

Как вы думаете, эквиваленты ли по производительности эти два варианта проверки условий внутри цикла?

		
if a > b && c*2 > d {
	....
}
// и
if a <= b  { 
  continue;
}
if c*2 > d {
 ....
}

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



Автор материала, перевод которого мы публикуем, решил добраться до сути средств выделения памяти в Go и рассказать об этом.

На прошлой неделе компания ARM Holdings объявила, что разрабатывает новую микро-архитектуру для серверных процессоров. Вычислительное ядро, которое будет в ней использоваться, носит кодовое имя Ares, и по обещаниям должно дать 60% прирост по сравнению с текущей платформой. С каждым следующим поколением производительность должна расти еще на 30%.

Серверный рынок — пока не самый большой для ARM. Сейчас процессоры на ее архитектуре используются в мобильных и встраиваемых устройствах. Скачок производительности, который компания обещает производителям серверов, будет выше чем Intel и IBM проделали за последние несколько лет.

Тем не менее, создатель Linux Линус Торвальдс скептично прокомментировал анонс. Он считает, что будущее новой архитектуры не так радужно.

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

Когда мы запустили в 2013 году Discourse, наши требования к серверу были высокими:

• 1 ГБ ОЗУ
• быстрый двухядерный ЦП
• быстрый твердотельный накопитель от 20 ГБ

Я имею в виду не дешёвый общий cpanel-сервер, а выделенный виртуальный частный сервер с такими характеристиками.

Нам этого было достаточно, потому что в течение следующего десятилетия Интернета мы писали на Ruby. Я сразу предсказывал, что цена аренды VPS с такими характеристиками упадёт до 5 долларов в месяц, и благодаря Digital Ocean это действительно случилось в январе 2018 года.

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


Но постойте… а что если вы сможете засунуть «в облако» свой компьютер?

Приветствую, друзья!

В предыдущих двух статьях (раз, два) мы погружались в сложность выбора между технологиями и искали оптимальные настройки для нашего решения в Ostrovok.ru. Какую тему поднимем сегодня?

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

Примечание переводчика

Большинство современных программных продуктов не являются монолитными, а состоят из множества частей, которые взаимодействуют друг с другом. При таком положении дел необходимо, чтобы общение взаимодействующих частей системы происходило на одном языке (притом что сами эти части могут быть написаны на разных языках программирования и выполняться на разных машинах). Упростить решение этой задачи помогает gRPC — open-source-фреймворк от Google, выпущенный в 2015 году. Он решает сразу ряд проблем, позволяя:

• использовать язык Protocol Buffers для описания взаимодействия сервисов;
  
• генерировать программный код на основании описанного протокола для 11 разных языков как для клиентской части, так и для серверной;
  
• реализовать авторизацию между взаимодействующими компонентами;
  
• использовать как синхронное, так и асинхронное взаимодействие.
  

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

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

Компания Check Point довольно резво начала 2019 год сделав сразу несколько анонсов. Рассказать обо всем в одной статье не получится, поэтому начнем с самого главного — Check Point Maestro Hyperscale Network Security. Maestro это новая масштабируемая платформа, которая позволяет наращивать «мощность» шлюза безопасности до «неприличных» цифр и практически линейно. Достигается это естественно за счет балансировки нагрузки между отдельными шлюзами, которые работают в кластере, как единая сущность. Кто-то может сказать — "Было! Уже есть блейд-платформы 44000/64000". Однако Maestro это совсем другое дело. В рамках этой статьи я вкратце постараюсь объяснить что это, как это работает и как эта технология поможет сэкономить на защите периметра сети.

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

Такую программу для своего SQL Server разработал Microsoft — SQL Server Fast Track (DWFT). По ней сертифицируются конфигурации хранилищ данных — те, которые соответствуют требованиям рабочей нагрузки и могут быть внедрены с меньшим риском, стоимостью и сложностью. Звучит прекрасно, но интересно все-таки оценить эти критерии на практике. Для этого мы подробно разберем одну из конфигураций, имеющих сертификацию SQL Server Data Warehouse Fast Track.

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

Обычно мы рассматриваем производительность в единицах пропускной способности. Например в Гигафлопах. Задача оптимизации в таких случаях сводится к выполнению максимального количества вычислений за единицу времени или решение задачи за минимальное время. Дизайн процессора рассчитан в первую очередь на достижение максимального количества вычислений за единицу времени и стандартные техники оптимизации на то же самое.

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

Здравствуйте! Меня зовут Иван Давыдов, я занимаюсь исследованиями производительности в Яндекс.Деньгах.

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

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

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

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

Даже те, кто пока только мечтают о тысячах пользователей на своём сайте, наверняка задавались вопросом: “А сколько же пользователей мой сайт выдержит, если они зайдут одновременно?” Сразу вспоминается известное выражение “Хабраэффект” – явление отказа сайта, который оказался не готов к многочисленным переходам на него после появления в интернете ссылки.

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

Недавно мы рассказали, как мы оптимизировали PHP-код нашего приложения. Теперь же пришёл черёд статьи про то, как мы полностью изменили внутреннюю структуру самой нагруженной и важной базы данных в Badoo, не потеряв при этом ни одного запроса.

Если вы занимаетесь выращиванием больших баз данных и вдруг упираетесь в потолок производительности — пришло время расширяться. Со scale-out расширением понятно: серверы добавляете и горя не знаете. Со scale-up все не так весело. Согласно стандартной glueless-архитектуре, мы берем два процессора, потом добавляем к ним еще два… так доходим до восьми и все. Больше Intel не предусмотрел, копите на новый сервер.



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

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

Я как разработчик вступил в проект в 2015-2016 точно не помню, но он работал 2-3 года ранее. Проект был очень популярен в своей сфере, а именно игровых серверов. Как странно не звучало, но проекты по игровым серверам ведутся и по сей день, недавно вакансии видел и чуток поработал в одной команде. Поскольку игровые сервера строятся на уже созданной игре, следовательно для разработки используется скриптовый язык который встроен в движок игры.

Мы разрабатываем почти с нуля проект на Garry’s Mod (Gmod), важно подметить, что на момент написания статьи Гарри создает уже новый проект S&Box на движке Unreal Engine. Мы же до сих пор сидим на Source.

Который вообще не подходит для нашей тематики сервера.

Эта история — об одном из проектов внедрения ИТ-решений, а именно — о развертывании системы виртуальных рабочих мест сотрудников компании «Гражданские самолеты «Сухого». И выбрали мы ее не случайно! Ведь от современной ИТ-инфраструктуры сегодня зависит успешная работа многих предприятий и организаций, особенно таких высокотехнологичных, как предприятия авиапрома.

Для сотрудников данной компании системный интегратор IBS Platformix развернул инфраструктуру виртуальных рабочих мест (Virtual Desktop Infrastructure, VDI). Ее основой стало стало аппаратное обеспечение от нескольких производителей, в том числе серверы и тонкие клиенты Lenovo.