Рубрика «Серверная оптимизация» - 39

Введение

Приветствую всех читателей в нашем блоге.

Этот цикл статей будет посвящен нашему замечательному решению под названием HP Dynamic VPN (или HP DVPN).

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

Что такое DVPN?

Если кратко, то DVPN – это архитектура, которая позволяет множеству филиалов или региональных офисов (spoke) динамически создавать защищенные IPsec VPN туннели поверх любого IP транспорта для подключения к центральному офису или ЦОД (hub).

Для кого и чем это может быть полезно?

Допустим, есть некая организация, у которой имеется множество филиалов или удаленных офисов, раскиданных по всему городу или даже по всей стране (например, некий банк, или сеть магазинов, примеров таких организаций можно привести очень много). Перед нами стоит задача объединить все эти филиалы между собой с помощью одной транспортной сети, а также обеспечить возможность их подключения к центральному офису или ЦОД, в котором размещаются основные IT-ресурсы этого предприятия.
Читать полностью »

В рамках рабочих задач недавно мною было проведено небольшое исследование на тему целесообразности использования опции prefetchCount при работе с брокером сообщений RabbitMQ.
Хочу поделиться этим материалом в виде слайдов и комментариев к ним.

Тесты проводились на конкретном проекте, но в целом они справедливы для большинства случаев, где обработка сообщений (выполнение задач) занимает хоть сколько-то существенное время (при обработке менее 1000 сообщений в секунду).

* на слайдах вместо слова «подписчик» используется «консумер», в комментариях для единообразия тоже
* рассматривается одна очередь с пятью консумерами (C1..C5)

Идеальные условия

Оптимизация обработки сообщений в RabbitMQ
Читать полностью »

В рамках рабочих задач недавно мною было проведено небольшое исследование на тему целесообразности использования опции prefetchCount при работе с брокером сообщений RabbitMQ.
Хочу поделиться этим материалом в виде слайдов и комментариев к ним.

Тесты проводились на конкретном проекте, но в целом они справедливы для большинства случаев, где обработка сообщений (выполнение задач) занимает хоть сколько-то существенное время (при обработке менее 1000 сообщений в секунду).

* на слайдах вместо слова «подписчик» используется «консумер», в комментариях для единообразия тоже
* рассматривается одна очередь с пятью консумерами (C1..C5)

Идеальные условия

Оптимизация обработки сообщений RabbitMQ
Читать полностью »

Ну пожалуйста, чуть чуть быстрее…Придумать, разработать, запустить и раскрутить проект это, как оказалось, еще не предел мечтаний. Почти год назад я писал о том, как решил сделать новостной проект IT тематики и с какими трудностями столкнулся. Дабы не напрягать тех, кто об этом не знал или об этом забыл, краткое содержание.
Был задуман новостной проект без особых сложностей: новости, статьи, пресс-релизы компаний, комментарии, топы и т.п. Реализация на Bitrix. В течение полугода разработки проект так и не был завершен, сменив 4 разработчика, не смотря на созданные благоприятные условия для работы над проектом. В эпилоге был поставлен вопрос: Почему? Почему при обеспечении требуемой оплаты, без требований делать все к определенному сроку и т.п. проект не может быть доведен до конца.
Читать полностью »

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

После того, как ваши запросы оптимизированы, по идее у вас не должно возникать ситуаций, когда
1. Один запрос блокирует другие
2. Какие-то запросы блокируют друг друга
Мы стремимся к тому, чтобы таких ситуаций не возникало.

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

Этот киллер допускает ситуацию, когда БД выполняет пару тяжелых запросов.
Но когда он видит, что начинает появляться много долгих запросов — то начинает принмать меры
Читать полностью »

Когда компания дорастает до определенного размера и одного ЦОД ей становится мало, сразу возникает масса вопросов, как дальше развивать сетевую инфраструктуру. Действительно, как расширить границы существующего ЦОД, чтобы он прозрачно обеспечивал существующие сервисы на удаленных площадках? Делать большой L2 домен, чтобы не было проблем с виртуализацией или объединять площадки по третьему уровню? Если делать инфраструктуру иерархической, то как обойти ограничения существующих стандартов (802.1q) и что будет в этом случае с безопасностью? А как, при этом, обеспечить надежную передачу конвергентного трафика (e.g. FCoE) между площадками? И всем этим еще необходимо слаженно управлять…

Устойчивый «трэнд» последнего времени на виртуализацию и построение облачных инфраструктур однозначно показывает, что предпочтительнее остальных по многим причинам является вариант с объединением площадок ЦОД по второму (L2) уровню. Однако сразу возникает вопрос, какую технологию для этого использовать? Очевидно, что строить сейчас распределенный L2 домен на основе STP, как минимум, не рационально. Из существующих альтернатив — TRILL, PBB/SPB, FabricPath (proprietary!), MPLS/VPLS, dark fiber – вариант с использованием для DCI технологии VPLS является, с одной стороны, самым зрелым и проверенным на практике, с другой — гибким и богатым по функциональности. Про него дальше и поговорим подробно.
Читать полностью »

Мне по работе часто приходится сталкиваться с высоконагруженными многопоточными или многопроцессными сервисами (application-, web-, index-server).
Достаточно интересная, но иногда неблагодарная работа — оптимизировать все это хозяйство.
Растущие потребности клиентов часто упираются в невозможность просто заменить железную составляющую системы на более современную, т.к. производительность компьютеров, скорость чтения-записи жестких дисков и сети растут много медленнее запросов клиентов.
Редко помогает увеличение количества нодов кластера (система как правило распределенная).
Чаще приходится запустив профайлер, искать узкие места, лезть в source code и править ляпы, которые оставили коллеги, а иногда и сам, чего греха таить, много лет назад.
Некоторые из проблем, связаных с синхронизацией, я попытаюсь изложить здесь. Это не будет вводный курс по многопоточному программированию — предпологается, что читатель знаком с понятием thread и context switch, и знает для чего нужны mutex, semaphore и т.д.
Читать полностью »

В последнее время наблюдается рост платформ, построенных на асинхронной архитектуре. На асинхронной модели построен самый быстрый в мире веб-сервер nginx. Активно развивается шустрый серверный javascript в лице Node.js. Чем же хороша эта архитектура? Чем она отличается от классической многопоточной системы? На эту тему было написано огромное множество статей, но полного понимания предмета они дали далеко не всем. Часто приходится наблюдать споры вокруг Node.js vs PHP+apache. Многие не понимают, почему некоторые вещи можно сделать на Node.js, но нельзя на PHP или наоборот — почему вполне правильный рабочий код на PHP сильно замедлится в Node.js, а то и повесит ее. В данной статье я бы хотел еще раз подробно объяснить разницу в их архитектуре. В качестве примеров двух систем, возьмем вебсервер с PHP и Node.js.

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

В последнее время наблюдается рост платформ, построенных на асинхронной архитектуре. На асинхронной модели построен самый быстрый в мире веб-сервер nginx. Активно развивается шустрый серверный javascript в лице Node.js. Чем же хороша эта архитектура? Чем она отличается от классической многопоточной системы? На эту тему было написано огромное множество статей, но полного понимания предмета они дали далеко не всем. Часто приходится наблюдать споры вокруг Node.js vs PHP+apache. Многие не понимают, почему некоторые вещи можно сделать на Node.js, но нельзя на PHP или наоборот — почему вполне правильный рабочий код на PHP сильно замедлится в Node.js, а то и повесит ее. В данной статье я бы хотел еще раз подробно объяснить разницу в их архитектуре. В качестве примеров двух систем, возьмем вебсервер с PHP и Node.js.
Читать полностью »

Это продолжение серии из двух постов, в которых я рассказываю о построении VDI-решения для крупной российской софтверной компании.

Немного математики

Опираясь на описанную в предыдущем посте теорию, проведем расчеты:

Одновременно от 6 до 9 пользователей VDI могут использовать одно физическое ядро CPU. Для упрощения возьмем среднюю цифру — 7 пользователей.

Согласно требованиям заказчика необходимо обеспечить работу 700 пользователей по VDI с расширением до 1000.
Читать полностью »


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