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

Если честно, менеджеры паролей давно стали для меня чем‑то вроде зубной щётки. Пользуюсь каждый день, но задумываюсь о них только тогда, когда что‑то идёт не так. Обычно всё просто: клик — и нужная форма заполнена. Красота. Но именно эта красота может сыграть злую шутку. Совсем недавно я наткнулся на исследование про DOM Clickjacking, и понял, что даже привычное «автозаполнить» может подставить.

В отличие от старого доброго clickjacking с iframe, здесь никто ничего поверх не накладывает. Всё хитрее: страница сама превращается в ловушку. Менеджер паролей видит поле логина и честно вставляет туда пароль. А пользователь (ну то есть мы с вами) жмёт на кнопку и уверен, что всё нормально. На самом деле клик улетает в невидимый элемент, и данные — вместе с ним. Честно говоря, когда я это увидел на демо, стало немного не по себе.

Есть три главные причины, почему расширения ведутся на такой обман. Во‑первых, некоторые из них слишком доверчиво вставляют пароль сразу, без всякого подтверждения. Во‑вторых, они проверяют только домен верхнего уровня. А если у сайта есть хитрый поддомен — привет, уязвимость. И в‑третьих, далеко не все разработчики заморачиваются с CSP, поэтому любой внедрённый скрипт может вытворять с DOM что угодно.

Проверить страницу самому несложно. Открываете DevTools, смотрите на элементы. Если видите кучу строк с opacity:0 или position:absolute; left:-9999px — повод насторожиться. В Chrome во вкладке Layers это особенно хорошо видно. Для любителей автоматизации есть и короткий скрипт на JavaScript, который подсветит такие штуки.

Всем привет, меня зовут Денис Лимарев, я руковожу разработкой в одной из продуктовых команд Uzum Tezkor. В этой статье разберу несколько оптимизаций запросов к БД, которыми наша команда пользуется при разработке своих сервисов, и опишу подход к оптимизациям запросов в целом. В своих проектах мы используем PostgreSQL версии 14.15, поэтому все запросы я проанализировал на ней, и ваши результаты могут отличаться в зависимости от вашей версии.

За более чем 10 лет в разработке я не раз сталкивался с проблемой недостаточной производительности сервисов. Особенно это заметно на Python – отличном языке для быстрого старта, с множеством библиотек и фреймворков. Однако, когда проект растёт, его производительности начинает не хватать, и проблемы с задержками превращаются в угрозу стабильности и пользовательскому опыту. В этом руководстве я поделюсь практическими решениями, основанными на реальных кейсах, чтобы помочь вам оптимизировать Django-сервис и значительно сократить время ответа на запросы.

Как обрабатывать миллионы строк в PHP и не убить память?

Всё просто: генераторы и итераторы. Покажу, как ленивые вычисления экономят ресурсы, ускоряют код и упрощают работу с большими данными. С примерами, бенчмарками и разбором изнутри.

Когда‑то безопасность строилась вокруг простого правила: если ты внутри сети, значит «свой». Ставим фаервол, заворачиваем трафик в VPN, прикручиваем IDS — и вроде всё под контролем.

Сегодня этот подход разваливается. Удалёнка, подрядчики, BYOD, фишинг — периметр размазан. Атакующему не нужно ломать фаервол: достаточно украсть логин и пароль через поддельную форму входа. И вот он уже «свой».

Истории из ИБ‑практики:

Под катом – анимация, демонстрирующая сборку приложения для macOS в режиме реального времени:

Я расскажу, как она получилась, но для начала обрисую контекст этого проекта.

Компиляция конкретного софта может быть очень длительной просто потому, что в этой программе очень много кода — как, например, в проекте LLVM. Но бывает и так, что сборка идёт медленно по глупым и вполне устранимым причинам. Подозреваю, что большинство сборок просто тормозят из-за ерунды, но проверить это мне пока не удавалось. Поэтому я разработал кроссплатформенный инструмент для визуализации сборок (пока он существует в приватной бета-версии, ссылка в конце статьи). Он работает с любой системой сборки и с любым языком программирования (а не только C/C++/Rust).

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

Микросервисы обещают решение. Гибкость. Масштабируемость. Независимые команды. Быстрые релизы. Звучит идеально. Но дорога к этой цели усеяна ловушками. Я видел проекты, которые провалились, потратив миллионы. Они просто поменяли один большой клубок проблем на десятки маленьких.

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

Как всё началось

Обычный рабочий день. Я проверял список процессов на сервере (ps aux) и вдруг вижу:

```bash

sshpass ‑p 'Qwerty123' ssh admin@10.0.5.21

Пароль. В открытом виде. В командной строке.

Подошёл к коллеге...

Балансировка нагрузки в веб‑сервисах решает сразу две задачи: масштабирование и отказоустойчивость. В этой статье поговорим о возможностях балансировки нагрузки для HTTP(S) протокола в Angie.

Теоретическая основа, описание алгоритмов уже описана разработчиком Angie, поэтому рекомендую обращаться к статьям с обзором балансировки и алгоритмам балансировки в Angie. Здесь же разберём практическую сторону настройки балансировки.

41 ТБ/сутки по маршруту Oracle → Postgres Pro без остановки исходной системы — это не теория, а цифры последних тестов. Мы разложили миграцию на три этапа: быструю начальную загрузку, CDC из redo-логов и валидацию, и собрали их в ProGate. Как устроен конвейер, почему Go и где прячутся узкие места — расскажем в статье.

Контейнерные приложения все чаще требуют постоянного хранилища, будь то базы данных, кэш или файловые серверы. Но Kubernetes по умолчанию не «умеет» работать напрямую с системами хранения данных, в этом ему помогает CSI (Container Storage Interface). А если хочется управлять хранилищем через единый стандарт и без привязки к конкретному вендору, на помощь приходит спецификация Swordfish.

В статье расскажем, как мы в лаборатории реализовали CSI-драйвер, поддерживающий спецификацию Swordfish и создали сервер-эмулятор, позволяющий тестировать и разворачивать такую систему без физического оборудования — и поделимся этим эмулятором, чтобы вы могли попробовать сами. 

Привет!

Недавно в рамках одного из проектов на стеке KMP, Ktor и Kotlin Serialization мы с командой решили провести эксперимент и определить возможность и целесобразность минификации тел запросов / ответов на Json.

Да, мы знаем про GraphQL, Protobuf и др., но в нашем случае имел место необузданный интерес наколхозить такое решение. И при всей его наивности удалось сократить средний размер итоговых джсонов (после всех внутренних оптимизаций) на 15-20%.

Все говорили о микросервисах. Гибкость. Масштабируемость. Независимые команды. Звучало как мечта. Многие компании бросились распиливать свои монолиты. Разработка действительно ускорилась. Отдельные компоненты стало проще обновлять и разворачивать.

А потом сервисам понадобилось общаться. И мечта превратилась в сложную, многомерную головоломку.

Время от времени приходится слышать мнение, что Postgres никуда не годится для решения задач аналитики. При при этом, в качестве аргументации приводятся в пример результаты тестирования на TPC‑H или ClickBench. Что ж, когда стоит простая задача перебрать 100 млн строк на диске и посчитать набор агрегатов над ними — формат хранения и распараллеливания действительно сильно ограничивают нас в возможностях оптимизации СУБД. Однако когда запросы высоко селективны, им по факту требуется не так много строк таблицы и фокус внимания смещается на порядок JOINов, кэширование промежуточных результатов и минимизацию операций сортировки. В этом случае Postgres, имеющий весьма широкий выбор различных стратегий выполнения запроса, может получить преимущество...

Уже несколько лет компания AMD предлагает совершенно атомные, а точнее ядерные, а ещё точнее суперМНОГОЯДЕРНЫЕ процессоры Epyc. В этой статье мы рассмотрим основные «бутылочные горлышки», настройки биос и другие вещи, которые мешают раскрыть потенциал этих процессоров.

Как Java поддерживает динамические вызовы? От медленной рефлексии до оптимизированных MethodHandle и invokedynamic — изучаем эволюцию динамизма в JVM. Разбираем внутреннее устройство MethodHandle и какие роли играют CallSite и invokedynamic.

Привет! Меня зовут Дима, я Backend-разработчик в Doubletapp. В этой статье расскажу про кеширование API (на примере Django Ninja): чем оно полезно бизнесу и когда его стоит внедрять.

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

А теперь представьте: вы можете обрабатывать одновременно в несколько раз больше запросов пользователей без расширения ресурсов и без переписывания ядра продукта. Как? С помощью кеширования — подхода, который «запоминает» одинаковые запросы и снижает нагрузку на сервер.

Содержание

• Серверный кеш (хранилища «ключ-значение»)
• Клиентский кеш (браузер, прокси)
• Условные HTTP‑запросы
• Промежуточное кеширование (CDN, reverse proxy)

Ваш проект взлетел. Первые пользователи превратились в тысячи. Тысячи стали десятками тысяч. Метрики в дашбордах рисуют красивую кривую, устремленную вверх. Но есть и другие кривые, которые ползут вверх с не меньшей скоростью. Время ответа сервера. Количество ошибок 502 и 504.

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

TL;DR Иногда «убить» самый тяжёлый JOIN — проще, чем кажется. Достаточно вынести агрегат в коррелированный под-запрос и дать движку опереться на индекс.

Как-то было свободных полчаса перед встречей. Ни туда, ни сюда. Дай, думаю, сниму трейс с приложения. Вдруг что-то интересное найдётся.

А в качестве бонуса: использование var может привести к багам? Узнаем в самом конце ;)