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

Несмотря на ударные темпы распространения платформ оркестрации контейнеров, вроде Kubernetes или Red Hat OpenShift, подавляющее большинство Java-нагрузок в мире по-прежнему выполняются на виртуальных машинах или на «голом железе». Однако перенос корпоративных нагрузок, и в частности, приложений Red Hat JBoss Enterprise Application Platform (EAP), в облако рано или поздно состоится, и OpenShift представляется здесь естественным выбором. Сегодня мы вкратце ответим на типовые вопросы, которые возникают при таком переходе, и покажем на примере, как он производится.

Что будет, если к Perfmon применить быстрое преобразование Фурье? Или функцию корреляции? Получится #черте_что!

Рано или поздно любой разработчик или администратор СУБД, имеющий дело с MySQL, сталкивается с проблемой блокировок. Всё дело в природе MySQL как системы с конкурентным доступом на чтение/запись. Я расскажу о видах блокировок в MySQL, их преимуществах и недостатках, о проблемах, которые они вызывают, а также дам полезные советы по обнаружению и способам борьбы с блокировками.

SELinux, как и все средства безопасности, снижает производительность системы. И хотя для большинства рабочих нагрузок такое влияние невелико (см., например, проведенное  порталом Phoronix тестирование на примере платформы Fedora 31), некоторые операции, как выяснилось, могут выполняться быстрее. Кроме того, в SELinux есть определенные шероховатости, неоправданно увеличивающие размер образов виртуальных машин или требования по оперативной памяти. Сегодня мы расскажем о недоработках в SELinux, которые нашел, устранил и закоммитил наш инженер-программист, который работает в команде Red Hat, занимающейся SELinux.

Многие из вас уже были в серверной, заглядывали туда краем глаза или в крайнем случае видели в фильмах. В кино зачастую серверная выглядит, как кабина пилота космического челнока, но в жизни всё намного прозаичней – под IT-инфраструктуру переоборудуют старую кладовку, ставят туда пару стоек и кондиционер. Но по уму надо проектировать комнату или строить отдельное здание.

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

Рассказываем о тестировании платформы Supermicro на основе дисков форм-фактора E1.S.

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

1. Kubernetes разработан для компаний типа FAANG

Yandex Rate Limiter (далее просто YARL) — это сервис лимитирования нагрузки для распределённых сервисов. Его особенность в том, что он способен работать с миллионами квот, имея при этом очень низкие накладные расходы на проверку квоты. Если совсем кратко, это система распределённых Leaky Bucket'ов, с помощью которых можно ограничивать разные величины, связанные со временем: скорость передачи данных по сети, запросы в секунду и т. п.

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

По мере роста популярности нашего онлайн-шутера читеры все активнее его атаковали. Мы решили строить комплексную оборону по всем фронтам, где одним из шагов стала защита игрового процесса. Тогда взлому подвергались параметры здоровья, урона и скорострельности, кулдауны, количество патронов и многое другое — то, от чего в первую очередь страдали честные игроки.

Мы используем Photon Cloud для сетевого взаимодействия игроков, поэтому сразу стали искать удобное решение на его основе. И нашли Photon Plugin, который закрыл все потребности. Изначально его вводили только для защиты, но потом стали использовать и при разработке новых фичей, где требуется серверная логика. Как мы его внедряли — рассказал под катом.

Поделюсь с вами кейсом ускорения работы одного сайта на WP + WooCommerce. Статья будет полезна джунам и миддлам кто разрабатывает сайты, кто занимается оптимизацией сайтов и кто хочет посмотреть на работу php кода "с высоты". Для себя из полезного можно узнать как связать вместе OpenServer, PhpStorm и xDebug

В этом переводе к старту курса по Fullstack-разработке на Python напоминаем о том, насколько важно знать технологии в деталях, грамотно применять их и планировать работу в целом. Цифра 2850 в заголовке — не преувеличение: ранее занимавший две минуты запрос в базе данных компании Affinity сегодня выполняется за 42 миллисекунды. Подробности, как всегда, под катом. А если вам нужен план развития навыков с большим количеством практики, вы можете обратить внимание на наши курсы.