Comments 4
Вы ведь понимаете, что открывая статью, заголовок которой начинается с «Оптимизация высоконагруженных конфигураций», читатели ожидают увидеть более-менее конкретные рекомендации или хотя бы истории успеха, но никак не статью, где будет рассказываться, что критерии успешности оптимизации — это сокращение количества обращений пользователей, уменьшение количества аварий и сокращение времени обмена данными с базой до установленных значений?
Идеи высказаны в целом верные, но над оформлением надо работать.
Главное, что надо помнить — картинки и мемасики не заменят конкретику.
В целом, статьи, состоящие из общих рекомендаций, в принципе имеют право на существование. Но если они подкреплены практическими рекомендациями и реальными примерами, это идёт им сильно в плюс.
Наличие же длинного и путанного вступления с самоповторами, а так же большого количества картинок работают в минус, и оставляют легкое ощущение "что я сейчас прочитал"?
В целом статья оставляет впечатление сентенции "лучше быть богатым и здоровым, чем бедным и больным". Ну отлично, "поиск узких мест". А КАК их искать? "Выявление взаимосвязей в ошибках". Не очень понятно, что имеется в виду. "Анализ достаточности серверных мощностей". А это разве не входит в "поиск узких мест в БД"? Тут же ведь либо индексов не хватает, либо памяти под индексы. Если второе, то вот оно — узкое место и необходимость апгрейда — нет? "Проверка длительности запросов в разных сценариях" — опять же, это разве не тот же самый поиск узких мест? И почему бы не подключить средства самой БД, slow_query_log в mysql и аналоги в других базах?
Отдельно хочу отметить, что хотя действительно проще застрелиться, чем победить Новый Суперэргономичный и Значительно Улучшайзенный Редактор Хабра 2.0, но старая версия всё ещё доступна по ссылке.
- И с помощью
- несложного маркдауна
- вполне можно
- делать аккуратные
- вложенные
- списки
Оптимизация высоконагруженных конфигураций: от “всё пропало, мы все умрем” до комфортной работы без страха за жизнь