15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
Проблемы с блокировкой строк? Попробуй slotted counters
Это прикольный приём, который помогает распределить инкременты по нескольким строкам и тем самым снизить конфликт за ресурсы.
Представь сайт вроде YouTube, где нужно считать просмотры у каждого видео. Удобно хранить счётчик прямо в таблице video, но у популярных видео десятки тысяч запросов одновременно пытаются увеличить одно и то же поле.
Результат: конкуренция → блокировки → тормоза.
Решение — распределить счётчик по N строкам в отдельной таблице.
В примере N = 3, но можно сделать 100 или 1000 — зависит от нагрузки.
Каждое обновление выбирает одну из N строк случайным образом и увеличивает значение именно там.
Когда нужен общий счётчик для конкретного v_id, просто суммируем все строки с этим идентификатором. Это можно делать на лету или периодически и складывать результат обратно в основную таблицу video.
👉 @BackendPortal
Большинство сбоев происходят не из-за плохого кода.
Они происходят из-за предположений, которые никто не удосужился проверить.
Системы ломаются не потому, что люди невнимательны.
Они ломаются, потому что что-то «очевидное» так и не было озвучено.
Самые опасные вещи — это тихие моменты:
«Этот API никогда не вернёт пустой payload.»
«Кэш всегда будет warm»
«Этот cron никогда не выполнится дважды одновременно.»
«Очередь сообщений никогда не потеряет сообщение.»
«Место на диске никогда не закончится во время процесса.»
Невысказанные предположения превращаются в единые точки отказа.
🚀 Ты — разработчик, но не до конца понимаешь, как твой код оказывается в проде?
Пора разобраться с новым курсом по GitLab CI на Stepik!
От теории и концепций до рабочих пайплайнов со сборкой, тестами, линтингом, временными отчетами и деплоем нейросети DeepSeek!
📝 50+ уроков, реальные примеры, минимум теории.
👨💻 60+ учащихся уже записаны на курс.
🎁 Для подписчиков канала — промокод CICD15 (скидка 15%).
👉 Открыть курс на Stepik
malloc — не единственный способ выделения памяти.
Фактическое выделение и освобождение памяти происходит с помощью системных вызовов brk, sbrk и mmap, а malloc — это удобная оболочка над ними.
Стандартная реализация malloc на большинстве Linux-систем — это ptmalloc2 из glibc. Она подходит для общих задач, но имеет фундаментальные ограничения, которые становятся узкими местами в production-системах, особенно при:
- конкуренции за блокировки (lock contention)
- фрагментации памяти
- плохой локальности кэша
Некоторые популярные и широко используемые реализации malloc — это jemalloc и tcmalloc.
Используйте jemalloc, если у вас:
- долгоживущие процессы, где фрагментация накапливается (базы данных, кэши, игровые серверы)
- требуется стабильная производительность при разных паттернах выделения памяти
- важна не только скорость, но и эффективность использования памяти
- нужно подробное исследование и статистика работы памяти
Используйте tcmalloc, если у вас:
- много потоков с высокой активностью выделения памяти
- в основном маленькие и краткоживущие объекты
- приоритет — максимальная пропускная способность
- вы готовы пожертвовать немного большим потреблением памяти ради скорости
Популярные пакеты, такие как Redis и Varnish, перешли на jemalloc для повышения производительности, а Cloudflare использует tcmalloc, что привело к снижению потребления памяти в 2.5 раза.
Эти реализации открыты, и я потратил некоторое время на изучение их кода на GitHub и переписывал некоторые фрагменты.
Надеюсь, это будет полезно.
👉 @BackendPortal
Интересный факт про vector search: проверка меньшего объёма данных делает поиск быстрее и точнее.
Алгоритм HNSW это основа одних из самых быстрых векторных поисков. Если вы использовали Weaviate или другие векторные базы, вы уже сталкивались с HNSW, это стандартный тип индекса, и не случайно.
HNSW можно представить как многоуровневую транспортную систему для векторов: сверху —> редкие длинные связи для глобальной навигации, средний уровень —> средние связи для регионального поиска, низкий уровень —> плотные связи для всех векторов для точного результата. Поиск начинается сверху, постепенно уточняется на каждом слое и в конце достигает максимальной точности на нижнем уровне. Алгоритм «перепрыгивает» через множество неактуальных данных вместо проверки каждого вектора, что делает его быстрее brute-force методов.
Основные параметры, которые можно настраивать:
• maxConnections —> плотность графа; большее значение повышает точность, но замедляет поиск и требует больше памяти
• ef, efConstruction —> динамический размер списков для поиска и построения графа, влияющий на баланс между скоростью и точностью
HNSW это баланс между скоростью, точностью и расходом памяти; улучшение одного всегда требует компромисса с другими.
Подробнее о настройке HNSW и оптимизации: Weaviate docs
👉 @BackendPortal
Программисты из Telegram создали сильнейшие IT- каналы
🐍 Ghostly Python - автоматизируй всё, что можешь. Боты, скрипты, парсеры, утилиты - делаем Python простым и полезным. Уверенный старт для новичков и не только.
☕️ Easy Java - Java без боли. От основ до фреймворков. Просто, понятно и по делу. Если хочешь реально понять язык - тебе сюда.
😎 IT Syndicate - главный хаб для тех, кто живёт IT. GameDev, InfoSec, Frontend, DevOps, AI и многое другое. Готовь мозг, тут будет жарко.
🧡 Ghostly Frontend - фронтенд без лишнего шума. HTML, CSS, JavaScript, React, Vue — всё, что нужно, чтобы создавать быстрые и красивые интерфейсы.
Сети для самых маленьких
Это серия статей о сетях, их настройке и администрировании. Здесь собраны основные аспекты, которые необходимо знать и понимать. В этой серии рассматривается планирование сети, настройка маршрутизаторов, работа с коммутацией и маршрутизацией, протоколы и технологии: STP, NAT, VPN, BGP, MPLS и многое другое.
https://linkmeup.gitbook.io/sdsm
👉 @BackendPortal
Никогда не вызывай API внутри транзакции.
В реляционных базах данных — это плохая практика. Транзакции должны быть как можно более короткими.
Долгие транзакции приводят к росту конкуренции за ресурсы. Если каждая транзакция захватывает блокировки строк, то чем дольше она живёт, тем выше вероятность ожидания блокировок и задержек выполнения.
Плюс MVCC. В Postgres используется мультиверсионность (MVCC), и долго живущие транзакции мешают старым версиям строк становиться кандидатами для autovacuum. В MySQL это решается через undo log. Когда активных долгих транзакций становится много, журнал приходится держать дольше — это увеличивает его размер и снижает производительность.
Если ты используешь пул подключений, например PgBouncer в режиме transaction pooling, долгие транзакции легко могут привести к исчерпанию пула и сбоям на стороне клиентов.
База данных — самое критичное звено твоего стека. Минимизируй конкуренцию за её ресурсы.
👉 @BackendPortal
Ты на собеседовании на backend-разработчика.
Тебе задают вопрос:
«Как защитить API от replay-атак?»
Вот как стоит разложить ответ по пунктам:
1. Метки времени + окно актуальности
Каждый запрос содержит временную метку (timestamp).
Сервер отклоняет запросы, которые выходят за пределы короткого окна допустимой давности.
2. Nonce (уникальные идентификаторы)
К каждому запросу прикрепляется одноразовое случайное значение — nonce.
Сервер хранит уже использованные nonce и отклоняет повторные.
3. Подписи HMAC
Клиент подписывает запрос секретным ключом.
Сервер проверяет подпись и одновременно удостоверяется в "свежести" запроса (по timestamp и nonce).
4. TLS повсюду
Всегда использовать HTTPS, чтобы предотвратить перехват токенов или подписей.
5. Короткоживущие токены
Применять JWT или session tokens с малым временем жизни — это сокращает окно риска, если токен всё-таки утёк.
6. Idempotency key для критичных операций
Для операций вроде платежей или переводов использовать уникальные идентификаторы запросов.
Даже если replay произойдёт, сервер просто проигнорирует повтор.
КУРС "Python Backend собеседование | 101 вопрос + 101 тест"
Получите структурированные ответы на самые частые вопросы с технических интервью
ЧТО ВНУТРИ КУРСА ПРЯМО СЕЙЧАС:
📚 101 РАЗОБРАННЫЙ ВОПРОС
• Полные объяснения с примерами кода
• Ответы на вопросы всех ключевых тем:
• Python (GIL, функции , структуры данных)
• FastAPI
• Базы данных и SQL
• Асинхронное программирование
• Docker и контейнеризация
• Архитектура API
• Кеширование и Redis
•101 тестовое задание
🛠 ПРАКТИЧЕСКИЕ МАТЕРИАЛЫ:
• Тестовые задание к каждому вопросу
• Готовые шаблоны кода для проектов
• Примеры из реальных коммерческих проектов
🎓 ФОРМАТ ОБУЧЕНИЯ:
• Пожизненный доступ к материалам
• Постепенное усложнение - от Junior до Middle
• Структура "вопрос → ответ → практика"
Ссылка на курс: https://stepik.org/253465
Быстрая шпаргалка по kubectl
# 1) Просмотр ресурсов (быстрая отладка событий и полей)
kubectl describe pod my-pod -n apps
# 2) Просмотр логов Pod’а (используй -c для конкретного контейнера/sidecar)
kubectl logs my-pod -n apps -c sidecar
# 3) Применение YAML-манифестов (золотое правило идемпотентности)
kubectl apply -f resource.yaml
# 4) Перезапуск Deployment для обновления ConfigMap/Secret
kubectl rollout restart deployment api-server -n apps
# 5) Масштабирование Deployment (снизи до 0 перед изменениями или тестами)
kubectl scale deployment my-app --replicas=0
# 6) Публикация Deployment через NodePort (быстрый внешний доступ)
kubectl expose deployment web-app \
--name=web-svc --port=80 --target-port=80 --type=NodePort
# 7) Запуск временного debug Pod’а (интерактивная shell-сессия, автоочистка)
kubectl run tmp-shell --image=busybox --rm -it -- sh
# 8) Подключение внутрь Pod’а (проверка сетевых политик, доступности, тулов)
kubectl exec -n test-ns pod-a -it -- sh
# 9) Точечное обновление Deployment с помощью JSON Patch
kubectl patch deployment logger -n workloads \
-p '{"spec":{"template":{"spec":{"priorityClassName":"critical"}}}}'
# 10) Генерация ConfigMap YAML (не писать вручную — сгенерировать и подправить)
kubectl create configmap web-config --from-file=config.conf \
--dry-run=client -o yaml > cm.yaml
# 11) Генерация Deployment YAML (удобно для экзаменов и тестов)
kubectl create deployment web-app --image=nginx \
--replicas=2 --dry-run=client -o yaml > web-app.yaml
# Bonus: аналогично можно сгенерировать шаблон Pod’а
kubectl run test-pod --image=busybox --dry-run=client -o yaml > pod.yaml
# 12) Быстрое объяснение полей CRD (когда нет документации под рукой)
kubectl explain certificate.spec.subject
Backend вопрос на собеседовании по сценарию, связанному с теоремой CAP
Вы ведущий архитектор в Uber. Ключевой функционал опирается на распределённую систему, которая отслеживает местоположение водителей и доступность поездок в реальном времени. Чтобы обеспечить низкие задержки, система развёрнута в нескольких географических дата-центрах (например, один в Лондоне и другой в Манчестере).
Система должна:
Позволять водителям постоянно обновлять своё местоположение и статус доступности.
Позволять пассажирам видеть доступных рядом водителей и бронировать поездку.
Теперь представьте, что произошёл network partition: сетевое соединение между дата-центрами Лондона и Манчестера упало. Дата-центры больше не могут обмениваться данными между собой, но оба всё ещё могут общаться с пользователями в своих регионах.
В этот момент:
Спустя мгновение водитель выходит в онлайн, но его запрос попадает в дата-центр Манчестера (хотя он отслеживался лондонским дата-центром; перемещение в зону Манчестера означает, что для Лондона он как бы оффлайн).
При этом обновление о его статусе в Лондон не уходит.
Одновременно пассажир в Лондоне делает запрос на поездку, и этот запрос попадает в лондонский дата-центр.
Так как система Лондона не получила обновление об «онлайне», она всё ещё видит водителя как недоступного.
Вопросы:
Во время network partition, с какой фундаментальной дилеммой или компромиссом сталкивается система, когда пассажир в Лондоне пытается увидеть доступных водителей? Какие два возможных исхода есть для пассажира?
Напоминание о CAP theorem:
Теорема CAP утверждает, что распределённая система может одновременно гарантировать только два из трёх свойств: Consistency, Availability и Partition Tolerance. Так как сетевые разделения (P) — это данность для распределённых систем, реальный выбор приходится делать между C и A.
Подходы, о которых кандидат должен знать:
- Приоритизация Availability
- Асинхронная репликация (Asynchronous Reconciliation)
- Системы разрешения конфликтов (Conflict resolution system)
- Eventual Consistency
👉 @BackendPortal
Джуны — всё, ИИ победил. По статистике BCG, за последний год компании выбросили на улицу 75% молодняка. При этом миддлам и сеньорам зарплаты подняли в 4 (!) раза.
Чтобы подняться до уровня элит в аномально короткие сроки — подпишитесь на легендарные каналы для айтишников:
Новости и инсайды
Фронтенд разработка
ИИ и биг дата
Node js
Вёрстка
Питон и нейросети
QA-тестировщики
Там раскрыли инфу из курсов общей стоимостью 5.000.000р в эксклюзивных пошаговых инструкциях. Пока остальные пойдут на дно якорем, вы войдете в 10% тех, кто сломал систему.
Очень частый сценарий для собеседований по бэкенду, который игнорировать нельзя.
Нужно ли защищать API?
Сценарий = ваш endpoint для логина может вызываться не более 10 раз в минуту для одного пользователя.
→ Простейший подход — Fixed Window Counter (счётчик фиксированного окна) = считаем запросы с 10:01 до 10:02, потом сбрасываем счётчик.
Проблема? Пользователь может сделать 10 запросов в 10:01:59 и ещё 10 в 10:02:01. Итого 20 запросов за 2 секунды 🤯
Для более надёжного решения используют Sliding Window для плавного ограничения или Token Bucket, чтобы корректно обрабатывать всплески.
→ Sliding Window
Избегает проблемы резких всплесков на границе окна. Вместо фиксированной минуты (например, 10:01) считает запросы за последние 60 секунд от момента запроса. Дает более плавное и точное ограничение скорости.
→ Token Bucket
Отлично подходит для корректной обработки всплесков. Представьте ведро, которое постепенно наполняется «токенами» (например, 1 токен в секунду, ведро для одного пользователя/IP/endpoint). Каждый API-запрос «съедает» один токен. Если токенов нет — запрос отклоняется. Так контролируется средняя скорость, но при этом пользователи могут накопить несколько токенов для небольшого всплеска.
Выбор алгоритма зависит от того, хотите ли вы строгое ограничение сверху или управлять средней скоростью.
👉 @BackendPortal
Самые популярные стратегии деплоя
Существует множество подходов, но вот пять наиболее распространённых.
У каждой свои сильные стороны:
🔸Blue/Green Deployment
↳ Популярен благодаря отсутствию даунтайма, используется два окружения — Blue и Green. Одно обслуживает продакшен, второе тестирует новую версию.
↳ После тестирования без воздействия на живой трафик пользователи переводятся на обновлённое окружение.
↳ При обнаружении проблем легко вернуть старую версию.
↳ Основная сложность - затраты и управление двумя полноценными окружениями.
🔸Canary Deployment
↳ Назван в честь канареек в шахтах: изменения сначала получают небольшая группа пользователей.
↳ Это позволяет мониторить производительность и собирать обратную связь.
↳ При успешном тесте апдейт постепенно расширяют на всех.
↳ Отлично снижает риски, так как затрагивает ограниченное число пользователей.
🔸Rolling Deployment
↳ Обновление выкатывается поэтапно, а не сразу на всю систему.
↳ Сегменты инфраструктуры обновляются по очереди, что сохраняет работоспособность большей части системы.
↳ Подходит для критичных сервисов, где нельзя допускать простоя.
↳ Недостаток - более длинное время обновления и временные несоответствия между сегментами.
🔸Feature Toggles
↳ По сути это тумблеры для функций.
↳ Позволяют деплоить код заранее, включая новые фичи только для отдельных пользователей.
↳ Поддерживают сценарии типа canary-релизов и A/B-тестирования.
↳ Минус - рост числа флагов и сложность их управления, что может вызвать конфликты.
🔸A/B Testing
↳ Работает как эксперимент: разные версии фичи показываются разным группам пользователей.
↳ Помогает проверить гипотезы и предпочтения аудитории.
↳ Эффективность подтверждается метриками - вовлечённость, конверсия, удобство использования и др.
👉 @BackendPortal
Твой Kubernetes-DNS работает медленно, потому что поды обращаются к DNS-серверу, который находится на другом конце кластера.
Каждый запрос к имени хоста превращается в сетевой раунд-трип: приложение на ноде 1 пытается разрешить имя сервиса — и делает DNS-запрос к CoreDNS, запущенному на ноде 5.
Ответу приходится проходить весь путь обратно по сети.
NodeLocal DNSCache решает эту проблему, размещая DNS-кеш на каждой ноде.
Теперь поды обращаются за DNS-разрешением к localhost, не гоняя трафик по сети. Кешированные запросы возвращаются мгновенно.
Если записи в кеше нет — запрос всё ещё уходит в CoreDNS, но в продакшне большинство DNS-шаблонов повторяются, так что кеш срабатывает часто.
Настройка максимально простая: разворачивается DaemonSet, который запускает локальный DNS-кеш на каждой ноде. Поды продолжают использовать те же DNS-настройки, просто ответы приходят быстрее.
Разница в производительности особенно заметна в кластерах с высоким количеством DNS-запросов или при перегрузке DNS-серверов. В некоторых случаях задержка DNS падает со сотен миллисекунд до единичных.
Развернуть можно одной командой kubectl. Локальный кеш автоматически синхронизируется с основным DNS-сервисом.
Чем больше кластер, тем важнее это становится. В маленьких кластерах узкое место DNS может быть незаметно, но при масштабировании оно превращается в серьёзный фактор, влияющий на производительность.
Приложения, которые часто обращаются к сервис-дискавери, получают заметное снижение латентности.
Это один из тех апгрейдов, которые ничего не стоят, но могут значительно ускорить отклик приложений.
👉 @BackendPortal
Ваши Docker-контейнеры медленные, раздутые и уязвимые. И скорее всего, вы повторяете те же ошибки, что делают 90% инженеров в продакшне.
Вот мои советы:
Не используйте теги latest, вместо этого указывайте конкретные версии, например node:18.17-alpine.
Не собирайте толстые одностадийные образы, используйте многостадийную сборку, чтобы получать 50 МБ вместо 800 МБ.
Не запускайте контейнеры от root, создайте пользователя без прав root для безопасности.
Не копируйте всё с COPY . ., используйте .dockerignore и точные команды COPY.
Не позволяйте контейнерам использовать неограниченные ресурсы, задавайте лимиты памяти и CPU.
Не деплойте без проверок здоровья, добавляйте команды HEALTHCHECK, чтобы Kubernetes знал, что приложение работает.
Не создавайте 20 отдельных слоёв с RUN, объединяйте команды через &&, чтобы уменьшить количество слоёв.
Не пропускайте сканирование на уязвимости, используйте docker scan или Trivy в CI/CD.
Не берите полные образы ОС для простых приложений, используйте scratch или distroless как базу.
Не пишите логи в файлы внутри контейнера, логируйте в stdout/stderr и пусть оркестратор собирает их.
Библиотеки Java, которые должен знать каждый backend-разработчик
Lombok → уменьшает количество шаблонного кода в Java-классах
Guava → расширенные коллекции и утилиты
Jackson → мощная сериализация/десериализация JSON
Apache Commons → вспомогательные методы для стандартных Java-классов
JUnit 5 → современная платформа для модульного тестирования
Mockito → гибкое создание моков для тестов
SLF4J → абстракция для логирования
MapStruct → безопасное преобразование между Java-бинами
Logback → надёжная реализация логирования
OkHttp → эффективный HTTP-клиент для REST-запросов
👉 @BackendPortal
Опа, тут бывший сеньор одного из IT-отделов Яндекса Игорь Никитин выкатил целый канал про Python — и это лучшее, что есть в рунете по теме.
Качественные гайды. Советы от известных прогеров. Тематические мемасы. Короче, ничего лишнего.
Хватит душить питона, учись его кодить: /channel/+MHz6ewg03OVkZjcy 🐍
Твой кеш не сломан из-за LRU —> он сломан, потому что ты забыл про TTL.
LRU сам по себе не решает проблему, потому что горячие ключи никогда не устаревают, и в кеше может бесконечно храниться вчерашняя, давно неактуальная информация. Если память не заполняется полностью, ничего не вытесняется, и «мертвые» ключи продолжают занимать место. В итоге кеш может содержать некорректные данные, а это даже хуже, чем промах.
TTL тоже не панацея. Когда срок жизни данных истекает, все клиенты одновременно обращаются к источнику — начинается классический эффект «thundering herd». Если TTL выставлен слишком большим, в памяти остаются «холодные» ключи, которыми никто не пользуется, а если слишком коротким — данные постоянно сбрасываются, снижая эффективность кеша.
LRU и TTL решают разные задачи. Механизм вытеснения вроде LRU или LFU включается, когда память заполнена, и помогает оптимизировать использование пространства. TTL, наоборот, активируется, когда данные устаревают, обеспечивая их корректность.
Хороший кеш работает как холодильник: LRU выбрасывает продукты, когда они занимают всё место, а TTL следит за сроком годности, чтобы ты не выпил прокисшее молоко. Вместе они дают и свежие данные, и свободную память.
👉 @BackendPortal
SQLBolt - изучайте SQL с помощью простых интерактивных упражнений.
https://sqlbolt.com/
👉 @BackendPortal
Недавно Дима Александров (руководитель подразделения разработки в Яндекс Еде) писал про минимизацию ущерба при инцидентах в бэкенде. И очень зацепила мысль: «сначала откатывай, потом думай».
У меня не раз было так: сервис падает, а команда вместо отката лезет в логи, спорит, что сломалось, кто виноват. А время идёт, пользователи страдают. В итоге понимаешь, что самым быстрым решением был бы простой откат. Даже если нет уверенности, что откат поможет, лучше сразу его запустить и разбираться уже параллельно. В 95% случаев хуже не станет — виноват обычно крайний релиз.
Из опыта ещё очень больно, когда сам откат сделать легко, но сервис поднимается вечность. Один раз мы откатили релиз за минуту, а пользователи ждали ещё час, пока система стартанёт, потому что набирал полный кеш из БД. С тех пор я стараюсь обращать внимание не только на код, но и на то, как сервис «просыпается».
Ну и режим деградации, это вообще мастхэв. Лучше пусть сервис работает хоть как-то, чем лежит полностью. Даже «обрезанная» выдача или fallback-заглушка в критический момент спасает больше, чем кажется.
Поэтому такие мысли, как у Димы, я особенно ценю. Это вроде бы простые вещи: откат, быстрый рестарт, режим деградации. Но именно из таких «мелочей» складывается уверенность инженера и умение держать систему живой даже тогда, когда всё идёт не по плану.
📘 На Stepik вышел курс — «Golang - микросервисная архитектура, проектирование API»
Уже знакомы с Go и хотите перейти на следующий уровень? Этот курс — именно то, что нужно, чтобы прокачать свои навыки.
• Полный путь от сетевых протоколов до Kubernetes: HTTP/REST, gRPC, RabbitMQ и Kafka, PostgreSQL, Redis, Docker, Prometheus + Grafana
• Практика на реальных кейсах: проектируем API, пишем микросервисы, покрываем тестами, выкатываем CI/CD
• 180+ интерактивных заданий с автопроверкой — код прямо в браузере, в любое удобное время
• Итоговый pet-project: к финалу курса у вас будет рабочая мини-экосистема из нескольких сервисов
🎓 Сертификат по завершении — добавьте его в резюме или профиль LinkedIn
🚀 Прокачайте Golang с пользой и удовольствием. Начните уже сегодня и получите скидку 25%, которая действительна в течение 48 часов
👉 Пройти курс на Stepik
Как Netflix синхронизирует данные между 200 млн устройств
Чтобы пользователи могли без задержек продолжать просмотр на любом устройстве, Netflix обрабатывает свыше 150 000 событий в секунду.
Для этого используется отдельный микросервис, который собирает события, отправляет их в Amazon SQS, распределяет по приоритетам и через AWS-кластеры рассылает уведомления.
Данные хранятся в Cassandra, что позволяет сочетать push и pull обновления — онлайн-устройства получают события мгновенно, а офлайн-устройства при следующем подключении.
👉 @BackendPortal
Нагрузка на сервер такая высокая, что даже по SSH не подключиться?
Используй эту команду:
ssh -o ConnectTimeout=1 -o ConnectionAttempts=1 user@host "nice -n -20 bash"
👩💻 Всем программистам посвящается!
Вот 17 авторских обучающих IT каналов по самым востребованным областям программирования:
Выбирай своё направление:
👩💻 Backend — t.me/backend_ready
📱 GitHub & Git — t.me/github_ready
👩💻 Frontend — t.me/frontend_ready
📱 JavaScript — t.me/javascript_ready
👩💻 Весь IT — t.me/it_ready
📖 IT Книги — t.me/books_ready
👩💻 Python — t.me/python_ready
🤔 InfoSec & Хакинг — t.me/hacking_ready
🖥 SQL & Базы Данных — t.me/sql_ready
🤖 Нейросети — t.me/neuro_ready
👩💻 C/C++ — /channel/cpp_ready
👩💻 C# & Unity — t.me/csharp_ready
👩💻 Java — t.me/java_ready
👩💻 Linux — t.me/linux_ready
🖼️ DevOps — t.me/devops_ready
👩💻 Bash & Shell — t.me/bash_ready
🖥 Design — t.me/design_ready
📌 Гайды, шпаргалки, задачи, ресурсы и фишки для каждого языка программирования!
TCP это один поток.
Мы используем TCP для отправки сообщений (например, можно думать о них как об HTTP-запросах).
Некоторые сообщения большие, другие маленькие. TCP не «видит» сообщений — для него это просто поток байтов.
Байты в TCP это ценный ресурс, и сегодня всё полностью контролируется клиентом (в протоколах с моделью request/response). Разные клиенты отправляют как маленькие, так и большие сообщения, и всё это уходит как «сырые» байты на один и тот же backend.
Связь с этим бэкендом может перегружаться по мере роста объёма передаваемых байтов. Тогда возникает вопрос: как сделать так, чтобы передавались в первую очередь байты сообщений с более высоким приоритетом?
Если дать бэкенду право решать, какие сообщения можно отправлять от разных клиентов, то мы гарантируем, что передаются байты именно от сообщений с высоким приоритетом. Таким образом длинные сообщения с низким приоритетом не смогут «забить» сеть, вызвать перегрузку и тем самым сократить TCP window size без необходимости.
Именно эту проблему решает протокол Homa
👉 @BackendPortal
Интервьюер:
«Вы сказали, что ваш сервис быстрый. Имеете в виду высокую пропускную способность или низкую задержку?»
«Мы снизили задержку за счёт оптимизации SQL-запросов и кэширования часто используемых данных. Чтобы повысить пропускную способность, мы горизонтально масштабировали сервис и добавили rate limiting, чтобы избежать перегрузки».
Где найти кнопку переключения с «вялый прокрастинатор» на «энергичный достигатор»?
Порой все так достанет, что кроме как накричать на кого-то или плюнуть на все и залипнуть в соцсети, ничего не могу.
Рутина сжирает, а тревога теперь – верный спутник?
Тогда рекомендую кликнуть сюда, потому что сам ты уже не справишься 🫠
Волшебную кнопку ты, конечно, не получишь, зато научишься выходить из состояния апатии и тревоги и разберешься – а в чем же, собственно, их причина?
Яркая жизнь, где есть место не только работе и обязанностям, но и прочим прелестям жизни, есть!
📍 Поэтому подписывайся на @metaskills_center, чтобы прийти к ней как можно скорее.
Рекомендую начать с закрепа в канале.
Там тебя ждет мега полезное видео «3 первых шага, чтобы построить систему жизни, где есть радость, энергия и время для себя».
В Java-приложениях одна небольшая настройка может улучшить производительность в 50 раз.
@Transactional
public List<Order> getRecentOrders() {
return orderRepository.findRecent();
}
@Transactional на методе, который просто делает read/GET вызов.@Transactional работает в режиме read-write, то есть:@Transactional(readOnly = true)
Пропустить ненужные flush-операции в Hibernate.
Оптимизировать работу транзакций для SELECT-запросов.
Уменьшить оверхед от прокси и избежать лишних блокировок.
@Transactional везде подряд только ради «красоты».@Transactional(readOnly = true) для запросов.@Transactional, если методу вообще не нужна транзакция.