Серверная оптимизация

Что быстрее — ASP.NET Core-приложение, развёрнутое в Docker-контейнере на Linux, или такая же программа, но запущенная на Windows-сервере, учитывая то, что всё это работает в службе приложений Azure? Какая из этих конфигураций предлагает более высокий уровень производительности, и о каком «уровне производительности» можно говорить?

В предыдущей публикации рассматривались преимущества использование ARM серверов для хостинг провайдеров. В этом посте рассмотрим практические варианты создания кластерного сервера на ARM процессоре и протестируем инстанс Amazon EC2 T4g работающий на процессоре ARM AWS Graviton2, посмотрим на что он способен.

Неважно, каких размеров ваше приложение на Node.js. Неважно, как хорошо вы написали код. Вам просто необходимо знать, как он работает в продакшене. Разработчик интерфейсов в поисковом портале Яндекса Алексей Попков сделал доклад о том, как выяснить, что происходит внутри запущенного процесса.

Что нужно, чтобы заглянуть в этот чёрный ящик? Ответ — опенсорс, все бесплатно, бери и внедряй.

— Всем привет. Немножко про то, кто я такой. Меня зовут Лёша, я разрабатываю внутренние сервисы Яндекса. Уже третий год делаю всякие Node.js-приложения, менторю разработчиков в Яндекс.Практикуме и измеряю все, до чего дотягиваются руки, потому что это весело.

Если вам нужна была высокая производительность, то вам нужно было выбирать процессор на x86 для своих решений. В последнее время, все больше и больше говорят о закате архитектуры x86 и переходе на ARM. В прошлом году компания Apple впервые представила Mac на процессорах ARM. Но подойдет ли процессор ARM для дата-центров, сможет ли ARM навсегда отправить x86 на скамью запасных?

Полтора года назад я выступил на FrontendConf и посвятил 40 минут профилированию. Перечисленные приемы и инструменты по-прежнему актуальны — сегодня публикую видео с подробным конспектом. Доклад расскажет, что такое профилирование, научит локализовывать потенциальные утечки памяти, а также немного углубит ваше понимание инструмента DevTools.

— Всем привет. Меня зовут Артём Несмиянов, я fullstack-разработчик Яндекс.Практикума. И, как видите, сегодня я хочу рассказать о профилировании Node.js, хотя это не совсем фронтендерская тема. Но сейчас очень много приложений используют фронтбэк, где есть свой server-side rendering, где нужно это все отдавать клиенту, и фронтендеру часто приходится взаимодействовать с Node.js. Иногда происходят вещи, которые могут повлиять на ваш сервер, положить его, перегрузить и так далее. С этим надо бороться. Я хочу показать, какие методы использовали мы. Это скорее введение в профилирование Node.js.

Где поместить свой сервер, чтобы обеспечить максимальную скорость? Помимо времени, необходимого серверам для ответа на запросы, требуется время просто для доставки пакета из пункта А в пункт Б.

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

Определение TTL для некоторых кэшированных данных («time to live» — время существования или длительность хранения) может стать своего рода шарлатанской нумерологией для программистов. Кеширование по TTL даёт корректность в пользу увеличения скорости. Но до какой степени можно отказаться от корректности? Как долго можно показывать где-то неправильное значение, прежде чем пользователь будет сбит с толку? Как скоро такие пользователи заподозрят наличие у себя проблемы и лягут бременем на службы поддержки клиентов? Давайте разбираться.

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

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

Хотелось бы поделиться опытом оптимизации данных с целью уменьшения расходов на ресурсы.

В системе рано или поздно встает вопрос об оптимизации хранимых данных, особенно если данные хранятся в оперативной памяти, как это БД Redis.

Как временное решение, можно увеличить RAM тем самым можно выиграть время.

Redis это no-sql база данных, профилировать ее можно с помощью встроенной команды redis-cli --bigkeys, которая покажет кол-во ключей и сколько в среднем занимает каждый ключ.

Объемными данными оказались исторические данные типо sorted sets. У них была ротация 10 дней из приложения.

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

Данные из себя представляли события измененияцены / даты доставки у оффера. Офферов было очень много – порядка 15000 в каждом фиде (прайслисте).

Рассмотрим следующий пример данных события по офферу:

Использование journald как замена syslog'у для приложений с большим числом логов.Давным-давно, когда были дебаты о том, стоит ли принимать в качестве init-системы systemd (с одной стороны удобно, с другой стороны, довольно токсичный автор...), вместе с systemd приехал и journald. В целом, он ощущался как аппендикс к systemd, и вместе с ForwardToSyslog, он мирно жил на серверах. Дефолтная конфигурация в целом устраивала, а всё нужное можно было по-старинке накрутить в syslog'е.

В одном из проектов у нас образовалась потребность в обработке большого числа логов, и мы решили попробовать journald вместо (r)syslog(d|-ng). Оказалось, что:

journald решает все наши проблемы

документации по нему подозрительно мало (особенно, в сравнении с systemd)

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

Всем привет! Хочу поделиться с общественностью фреймворком, на основе которого в данный момент множество серверов, обслуживают тысячи клиентов в различных серверных системах (по условиям контракта, продукты основанные на данном фреймворке не разглашаются). EXtensible Server Core (exsc) — это фреймворк, написанный на языке C и позволяет в рамках одного приложения, иметь один или несколько серверных потоков. Каждый серверный поток способен обслужить большое количество клиентов. Хотя фреймворк можно использовать в модели типа запрос-ответ, в первую очередь он был рассчитан на поддержание постоянного соединения с большим количеством клиентов и обменом сообщений в реальном времени. Поскольку я и сам люблю взять готовый hello_world проект, скомпилировать его и посмотреть как всё работает, то в конце статьи будет выложена ссылка на такой проект.

Многим, кто работает с MySQL, известно, что команда EXPLAIN используется для оптимизации запросов, получения информации об использованных и возможных индексах. Большинство разработчиков и администраторов СУБД этой информацией и ограничивается. Я же предлагаю изучить команду EXPLAIN максимально подробно.

KubeHelper - это продукт, который упрощает решение многих ежедневных задач связанных с управлением Kubernetes через веб интерфейс. Поиск, анализ, запуск команд, “cron jobs”, репорты, фильтры, git синхронизация и многое другое. 

KubeHelper это не ещё одна попытка отобразить Kubernetes API в графическом интерфейсе. Не попытка заменить Lens, официальный Dashboard или другие продукты. Это мой скромный вклад в Kubernetes Open Source сообщество. Проект не имеет какого-то узко специализированного направления и содержит довольно много различных функций которые будут полезны в ежедневной работе с Kubernetes.

Помните, как во второй половине 90-х один известный тогда профессор хрипло пел “Бегут года, и грусть, печаль в твоих глазах, а я не знаю что тебе сказать”. Так вот, года действительно бегут, а грусть-печаль в глазах из-за того, что гонка технологий уже достигла таких скоростей, что успеть за ними не может даже самый ловкий мангуст. Правда, некоторые вещи категорически отказываются меняться, и раз уж эта статья из блога компании, занимающейся бекапами, видимо, что-то не меняется в бекапах. А проблема, о которой хочется поговорить сегодня - это выбор сервера, который эти бекапы и будет делать. Все как-то привыкли думать только о размере стораджа, куда их предстоит складывать, а то, что процесс бекапа - это типичная задача обработки большого массива данных, которая жрёт RAM и CPU как не в себя, многие то ли забывают учесть, то ли по неопытности упускают этот момент. Так что сегодня учимся подбирать сервера для бекапов не только по размеру дисков. Или, как говорят зарубежные коллеги: backup server sizing best practices.

И да, в посте будет математика. Целых две формулы. Я предупредил.

Понимание концепций рендера веб-страниц и измерение производительности рендера с помощью Chrome DevTools

Не важно, насколько хорош ваш сайт; если его загрузка занимает слишком много времени, никто не будет ждать, чтобы его увидеть. Если ваш сайт загружается более 3 секунд, есть большая вероятность, что вы потеряете часть посетителей. Но знаете ли вы, что можно значительно улучшить время загрузки своего веб-приложения, используя прогрессивный рендеринг? Прогрессивный рендеринг не только увеличивает скорость загрузки, но и решает некоторые серьёзные проблемы в методах рендеринга на стороне клиента и на стороне сервера. Чтобы лучше понять прогрессивный рендеринг, давайте посмотрим, как работает рендеринг на стороне клиента и на стороне сервера.

Привет, меня зовут Павел. Я работаю ведущим системным инженером группы внедрения в департаменте вычислительных систем компании STEP LOGIC. В этом посте я поделюсь своими наблюдениями о флеш-системе хранения данных Huawei OceanStor Dorado V6, которую мы тестировали в «полях» в инфраструктуре заказчика.

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

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

Сегодня мы расскажем вам о процессоре компании Церебро под названием Cerebras CS-1. И он действительно огромный!


Например, GPU, который считался самым большим раньше — это процессор Nvidia V100, а вот новый процессор Церебро. Он почти в 57 раз больше! Площадь самого чипа — 462 квадратных сантиметра — это почти столько же сколько площадь всей Nvidia 3090, вместе с системой охлаждения и разъемами.

Что связывает языки Python и C++? Как извлечь из этого выгоду лично для себя? На большой конференции Pytup Александр Букин показал способы, благодаря которым можно оптимизировать свой код, а также выбирать и эффективно использовать сторонние библиотеки.

— Всем привет, меня зовут Александр Букин, я разрабатываю Яндекс.Погоду. Вы еще можете знать меня как сооснователя Pytup. Также я состою в программных комитетах таких классных конференций, как PyCon.ru и YaTalks.

Сегодня мы с вами поговорим о любви Python и C++. А точнее — о том, что же их объединяет, эти два прекрасных языка и, на самом деле, еще C, и что мы можем почерпнуть из этих прекрасных отношений.

Недавно новый сотрудник спросил меня за обедом: «Какой у нас техдолг?»

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

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

Глядя на нового сотрудника, я глубоко вздохнул и начал: «Давай я расскажу о том, как у нас было 15 000 прямых подключений к БД…»

История, которую я рассказал нашему новому сотруднику, – это история крупной технической перестройки DigitalOcean. Работала вся компания, эта работа продолжалась несколько лет и преподала нам много уроков. 

Всем привет. Меня зовут Нещадин Иван, и я расскажу про оптимизацию одного из микросервисов Авито на Go. История построена вокруг различных инструментов, которые доступны в языке, и пойдёт от простых примеров к более сложным.