Как подготовить сайт к большим нагрузкам: 5 практических советов и полезные инструменты



    Пользователи очень не любят, когда нужный им онлайн-ресурс «тормозит». Данные опросов говорят о том, что 57% пользователей покинут веб-страницу, если она грузится дольше трех секунд, при этом 47% готовы ждать лишь две секунды. Задержка в одну секунду может стоить 7% конверсии и 16% снижении удовлетворенности пользователей.

    Поэтому к росту нагрузки и всплескам трафика нужно готовиться. И сегодня мы поговорим о том, как это сделать.

    Примечание: материал нацелен не на гуру системного администрирования, а скорее на владельцев бизнес-сайтов, поэтому он носит скорее обзорный характер.

    1. Используйте кеширование


    Чем больше контента на сайте можно закешировать, чтобы не загружать каждый раз, когда пользователь заходит на страницу – тем лучше. Обычно, значительная часть контента статична, и ее просто не нужно постоянно перезагружать. Его кеширование особенно важно при всплесках трафика, и может не только помочь ускорить сайт, но и сэкономить.

    Если у вас просто сайт, на условном WordPress, то отлично подойдут кеширующие плагины, вроде Cache Enabler или Cachify.

    2. Обрабатывайте только полезный трафик


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

    В сегменте корпоративного интернета ситуация еще хуже – здесь объемы плохого бот-трафика могут превышать 42%. Для компаний это плохо по двум причинам. Во-первых плохие боты могут быть запущены конкурентами для кражи контента или сбора важных бизнес-данных, во-вторых, бот-трафик создает серьезную дополнительную нагрузку на инфраструктуру.

    Избавиться от проблемы и снизить нагрузку на сайт помогают системы фильтрации, но для их корректной работы нужно производить калибровку индивидуально для каждого сайта. Для этого ботовый трафик можно смоделировать. Отличный инструмент для имитации такой нагрузки – это использование сервисов, вроде Infatica, которые позволяют арендовать резидентные прокси.

    Многие современные боты используют резидентные IP, а значит для качественного теста понадобится большое количество таких адресов.

    3. Балансируйте нагрузку


    Изучите доступные варианты инструментов для балансировки нагрузки. Существуют три типа таких решений – работающие на уровне железа, облачные и программные балансировщики.

    С большой долей вероятности «железные» варианты окажутся очень дороги для небольших компаний или создателей стартапов, так что уделим больше внимания остальным двум вариантам.

    Среди популярных облачных инструментов можно назвать Cloudflare – им часто пользуются компании, испытывающие проблемы из-за всплеска трафика. Из программных вариантов можно назвать Neutrino, серьезные возможности по балансировке нагрузки заложены в веб-сервер Nginx.

    4. Оптимизируйте доставку контента


    Еще один шаг, который будет полезен при всплесках сетевой активности, это использование CDN или сети доставки контента. По своей сути, это набор серверов по всему миру, которые можно использовать для доставки контента пользователю по наиболее оптимальному маршруту.

    Обычно контент сайта располагается на некоем главном сервере в единственной локации, поэтому при поступлении запросов из разных мест, ответы могут приходить пользователям неравномерно – и это выглядит как задержка. Чем дальше пользователь от сервера с сайтом, тем дольше ему нужно ждать ответа.

    CDN же кеширует файлы на разные серверы и «достает» их для передачи пользователю с наиболее близкого к нему сервера из сети. Это позволяет построить для каждого пользователя свой маршрут доставки и серьезно ускоряет работу всей системы в целом.

    По ссылке можно найти целый список CDN, которые подходят для использования с веб-сайтами.

    5. Используйте компрессию


    Сжатие файлов – еще один инструмент ускорения загрузки сайта. Очень многие высоконагруженные ресурсы включают Gzip-компрессию для того, чтобы снизить размер файлов сайта для их выгрузки и пересылки.

    Gzip работает так – инструмент ищет повторяющиеся строки в файле и заменяет вторую из них указателем на предыдущую строку. Когда браузер распаковывает полученный файл, он проходит по строкам в нем, считывает указатель и отображает «удаленный» контент. Таким образом можно снизить общий вес файлов до 70%. Некоторые хостинг-провайдеры включают Gzip-компрессию по умолчанию, но лучше проверить эту настройку вручную.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 5

      0

      Может, немного не по теме статьи, но замечу, что готовить сайт к нагрузке лучше начинать почти в самом начале цикла разработки, потому что «само» скорее всего не взлетит. А все предложенные улучшения лучше проверять нагрузочным тестированием, а не на пользователях, т.к. часто всплывают неочевидные нюансы реализации любого из предложенных методов.
      Мысль про отсечение нежелательного трафика считаю наименее очевидной и потому самой полезной из статьи, спасибо.

        0

        Как сказал один умный человек (жаль не я):


        чтобы сайт быстро работал он должен
        1) отдавать ответ на 90% запросов из http-кэша (сервера и пользователя)
        2) из оставшихся отдавать 90% из кэша приложения
        3) из оставшихся отдавать 90% из кэша хранилища без чтения с диска
        • НЛО прилетело и опубликовало эту надпись здесь
            0
            Например, http-кэша пользователя, который посещает не только один сайт.

            HTTP кэш работает так:
            1) Пользователь переходит на страницу. Браузер проверяет не лежит ли она в локальном кеше (на диске) на компьютере пользователя (не на сервере), не прошла ли дата в заголовке Expires или Date+max-age. Если не прошла, то обращения на сайт даже не происходит.


            2) Если же нет нужных заголовков, то идет запрос на сервер с заголовками If-modified-since и If-none-match, которые берутся из Last-modified и etag. Веб-сервер или прокси (в зависимости от заголовков кеширования) вполне могут отдать ответ 304 Not modified и браузер опять-таки подгрузит страницу из локального кеша на диске пользователя.


            3) Эти же заголовки попадают в программу и программа может проанализировать запрос и решит вернуть 304 Not Modified, что опять заставит браузер показать пользователю страницу из локального кеша.


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


            Увы 1, 2 и 3 не работает при вбивании руками адреса и намеренном F5. По оптимизации главных\посадочных страницу с персонализацией меня есть отдельная методика.


            Вопрос: есть ли ограничения на кэши, не учитывая которых можно ухудшить быстродействие сайта?

            Наверное есть, но я не встречал. LRU кэш при достаточно большом объеме памяти все равно будет работать, даже если вы не очень грамотно занимаетесь кешированием.


            Чем больше контента и чем сложнее сайт, тем больше памяти потребуется на кэши, исходя из оценки того, чтобы в них хранилось ресурсов под 90% запросов.

            Памяти при высокой нагрузке памяти вообще нужно много. Потому что если вы не отдаете из памяти, то отдаете с диска, а это в тысячи и миллионы раз медленнее. Но надо еще грамотно эту память использовать.

            • НЛО прилетело и опубликовало эту надпись здесь

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое