В честь нового года на наш сайт начало приходить все больше клиентов, пошли различные маркетинговые программы, и в итоге на базе данных нагрузка достигла 100 процентов и не падает. Конечно же стал вопрос, что делать?
Первое предложение от технического директора стало ограничение на сервере приложений количества возможных подключений к базе данных. Таким образом мы освободим количество подключений на SQL Server и нагрузка сократится. Я говорю, а если сервер приложений не сможет подключиться из-за отсутствия доступных подключений к базе, то приложение сгенерирует ошибку, и пользователь увидит не очень приятную страницу. Готовы на это? Конечно же нет.
Следующее предложение от технического директора: ну давайте тогда установим таймаут на соединение с сервером приложений. Если пользователь не получил ответа от сервера приложений в течении 30 секунд, разрывать соединение. Я говорю - хорошо, пользователи начнут видеть таймауты. Это лучше?
Ограничениями нельзя повысить производительность, ими можно ввести только ограничения. Они нужны для защиты от DDoS ну и от совсем нештатных ситуаций, когда запрос действительно выполняется слишком долго из-за возможной блокировки.
А для повышения производительности нужно работать над оптимизацией или масштабировать систему, но никак не ограничивать ее.
Поймите меня правильно, тайм аут нужен, как я уже сказал выше, как минимум две ситуации есть, когда он необходим - защита от DoS и защита от нештатных ситуаций. Но временные ограничения на выполнение запроса не отменяют необходимости оптимизировать запросы и загрузку страниц.
Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым
Если много операций чтения, ставить 2-3 сервера реплики только на чтение, а мастер только на запись. Правда придется бороться с консистентность реплик, наверно в виде синхронных реплик.
Так что таки решили делать?
Неужели у вас не было планов по поводу scale?
Я консультант. Я только свое мнение высказал, что никаких вводов ограничений не должно быть. Может быть оптимизация, может быть scale, но не ограничения.
А они SLA (Service level agreement) не писали?
-Режим работы
-Доступность
-Технологические окна и их продолжительность
-RTO
-RPO
-Продолжительность disaster recovery
Какой-то странный технический директор, раз такое говорит...
Хотите найти еще что-то интересное почитать? Можно попробовать отфильтровать заметки на блоге по категориям.
Программист, автор нескольких книг серии глазами хакера и просто блогер. Интересуюсь безопасностью, хотя хакером себя не считаю
Copyright © 2024 Михаил Флёнов. Тираж 1 штука. Отпечатано на ноутбуке. А за права отвечаю, или постараюсь.
А здесь еще и копирайт поставлю: Professional Web Development.
На сайте используются Cookie. Если вы из ЕС или Калифорнии США, то вы должны согласиться с их использованием - Согласен. Если вы из нормальной страны, то вам пох.
