Статьи

Улучшение производительности сайта в Черную пятницу и Кибер понедельник

Июль 14, 2017

«Среди хаоса также есть возможность» — Сунь Цзы, Искусство войны

Типичный продавец получает почти четверть своего годового дохода между Днем благодарения и Рождеством. Для многих интернет-магазинов два самых загруженных дня в году — это Черная пятница (день после Дня благодарения) и следующий кибер-понедельник, в котором наблюдается подавляющее количество продаж электронной коммерции. В то время как в эти дни наблюдается огромный всплеск продаж, они также представляют собой огромные всплески трафика и связанный с этим стресс и неопределенность в отношении производительности и времени работы сайта.

Покупатели требуют от вашего сайта высокой производительности и безупречного опыта. Если из-за притока трафика время загрузки вашей страницы сокращается всего на одну секунду, вы можете ожидать, что количество конверсий снизится на 7% . А в пиковые периоды трафика более 75% онлайн-потребителей скорее уйдут на сайт конкурента, чем пострадают ( PDF ).

На результаты поиска Google влияет производительность сайта, поэтому вы можете создать эффективный круг: более быстрая работа приносит вам больше клиентов, благодаря улучшенным результатам поиска, и вы получаете больше конверсий, поскольку покупатели получают лучший опыт. Воспользуйтесь приведенными ниже советами, чтобы повысить производительность своего сайта — не только в часы пик, но и каждый день в году.

Начало работы: знайте, где вы стоите против своих конкурентов

Улучшение производительности потенциально бесконечно; откуда ты знаешь, что плохо, достаточно хорошо или отлично? Конкурентные данные помогут вам узнать, где вы стоите.

Сравните размер страницы и время загрузки для ключевых клиентов и конкурирующих страниц; рассмотреть в том числе:

  • Время ответа домашней страницы для главных конкурентов
  • Время ответа в списке поиска товаров
  • Время отклика страницы продукта для продуктов, похожих на ваш
  • Продолжительность ожидания подтверждения после нажатия кнопки «Купить»

Вы можете протестировать ключевые страницы для полдюжины конкурентов и свой собственный сайт всего за несколько часов. (Обязательно очистите кэш браузера с помощью shift-refresh перед измерением времени загрузки.) Вот некоторые вещи, которые вы можете сделать с результатами:

  • Индекс общей производительности . Сколько времени занимает процесс посещения, поиска и покупки «супа с орехами» на разных сайтах? Смотри, где ты стоишь.
  • Определите сильные и слабые стороны . Найдите конкретные области, где эффективность вашего сайта впереди, конкурентоспособна или отстает.
  • Обратите внимание на особенности функции . Посмотрите, повышают ли конкуренты ценность процесса покупки с помощью дополнительных функций или того, что ваш сайт сильно сравнивает.
  • Создать план . Если вы значительно отстаете от конкурентов в одной или нескольких областях эффективности сайта, старайтесь соответствовать их среднему времени отклика; если вы уже конкурентоспособны, постарайтесь стать # 1.

Примечание . Builtwith — это веб-служба, позволяющая проверять веб-сервер, подключенный к Интернету, на наличие избранных сайтов, в том числе конкурирующих. (Он не показывает внутреннюю архитектуру.) Вы можете ввести URL-адрес, который вы хотите проверить, на встроенном сайте или использовать подключаемый модуль встроенного браузера для сравнения сайтов в Интернете. Расширение Chrome, Wappalyzer , предоставляет аналогичную информацию. Используя любой инструмент, вы увидите, что NGINX — это серверное программное обеспечение для Интернета, предназначенное для очень высокого процента высокопроизводительных сайтов.

Использование buildtiwth для проверки того, какие веб-сайты используют технологии

Примечание : чтобы выжить и процветать в праздничные дни, начните с поста главы NGINX Оуэна Гарретта, который был в прошлом году, « Перед лицом орд в Черную пятницу и Кибер понедельник» . Затем добавьте советы ниже, чтобы получить остальную часть пути там.

Увеличьте емкость с помощью шлюза HTTP

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

Многие сайты имеют простую архитектуру: веб-сервер, на котором выполняется код приложения для объединения веб-страниц, часто с сервером базы данных, поддерживающим приложение. Чаще всего сервер приложений является сервером Apache.

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

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

  1. Серверу Apache может не хватить памяти и начать выгружать сессии на диск, что значительно снижает производительность. Если запросы на подключение продолжают монтироваться, обмен может увеличиться, затрагивая все больше и больше пользователей сайта.
  2. На сервере Apache не хватает соединений. Чтобы сэкономить память, серверное программное обеспечение может ограничивать количество одновременных подключений, но эффект аналогичен нехватке памяти: доступные подключения используются, новые запросы на подключение должны ждать, и пользователи видят низкую производительность — особенно если запросы на подключение резервное копирование.
  3. Серверу приложений может не хватить ресурсов процессора из-за управления соединениями и запуска приложения, что снова заставляет пользователей ждать и вызывает запросы на резервное копирование.

Обратный прокси-сервер шлюза HTTP может предотвратить эти проблемы. Обратный прокси-сервер получает запросы из Интернета и передает их по локальной сети на сервер Apache. Затем сервер Apache запускает код приложения и возвращает нужный файл обратному прокси-серверу, который быстро подтверждает получение. Сервер Apache может работать со своей номинальной мощностью, поскольку ему не нужно держать открытыми тысячи соединений в ожидании подтверждений от удаленных клиентов.

Для этой цели очень широко используются программное обеспечение с открытым исходным кодом NGINX и NGINX Plus, при необходимости добавляются другие функции (см. Ниже). NGINX использует управляемую событиями архитектуру, которая может одновременно обрабатывать сотни тысяч соединений, переводя медленные интернет-соединения в высокоскоростные локальные транзакции.

Использование NGINX в качестве обратного прокси для повышения производительности сайта

Используя NGINX в качестве обратного прокси:

  • Сервер Apache может работать на полной скорости, получать запросы и отвечать по локальной сети.
  • Статические файлы легко кэшируются на сервере NGINX, поэтому нагрузка на сервер Apache и, следовательно, на сервер базы данных значительно снижается.
  • Можно добавить больше серверов Apache, с распределением нагрузки между серверами NGINX (см. Ниже).

Кэширование и микрокеширование содержимого вашего сайта

Кеширование объектов имеет множество полезных эффектов. Большая часть данных на типичной веб-странице состоит из статических объектов — файлов изображений, таких как файлы JPEG и PNG, файлов кода, таких как JavaScript и CSS, и так далее. (Вы можете увидеть, как это происходит на обычной странице с сайта электронной коммерции.) Кэширование этих файлов может значительно повысить производительность. Вы также можете кратко кэшировать динамически сгенерированные файлы, что называется микрокэшированием.

Существует три уровня кэширования для статических файлов:

  • Локальное кеширование . Вы можете поддерживать локальное кэширование статических ресурсов с помощью параметров конфигурации и повторяя одни и те же активы на нескольких страницах. Пример настроек конфигурации для NGINX приведен ниже. (Вероятно, вы получите некоторые преимущества локального кэширования от кэширования организаций и поставщиков услуг.)
  • Кэширование сети доставки контента (CDN) . CDN помещает контент ближе к пользователю и на выделенные машины, которые быстро отвечают на запросы. Однако влияние HTTP / 2 на CDN может снизить их преимущества без тщательной оптимизации; см. документ NGINX HTTP / 2 ( PDF ).
  • Кеширующий сервер . Вы можете установить сервер кэширования перед веб-сервером и сервером приложений. Программное обеспечение с открытым исходным кодом NGINX сочетает в себе кэширование статических объектов с возможностями веб-сервера, а NGINX Plus добавляет оптимизированные функции кэширования и мониторинга.

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

В следующем коде показано, как использовать директивы proxy_cache_pathand proxy_cacheв конфигурации NGINX или NGINX Plus. Подробнее об этом коде см. В этой статье о кэшировании контента , а обзор конфигурации кэширования см. В руководстве по кэшированию NGINX .

# Define a content cache location on disk
proxy_cache_path /tmp/cache keys_zone=mycache:10m inactive=60m;

server {
    listen 80;
    server_name localhost;

    location / {
        proxy_pass http://localhost:8080;

        # reference the cache in a location that uses proxy_pass
        proxy_cache mycache;
    }
}

Идея запуска PHP (или аналогичного) сервера состоит в том, чтобы предоставлять только что собранный контент каждому пользователю. Это простой и привлекательный подход, но он застопорился, когда трафик взлетел, а сервер приложений не успевал.

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

Как и другие PHP-фреймворки, Magento является хорошим примером преимуществ микрокэширования. Magento — это гибкая, мощная система управления контентом, которая широко используется для электронной коммерции. Magento часто реализуется как веб-сервер и сервер приложений, на котором выполняется PHP для сборки страниц, вызывая сервер базы данных для контента. Эта сборка прекрасно работает до определенного момента, а затем может умереть ужасной смертью, когда трафик превышает способность сервера приложений справиться с ситуацией — что может легко случиться с сайтом электронной коммерции, особенно в праздничные дни.

Чтобы предотвратить перегрузку, установите обратный прокси-сервер, такой как сервер с открытым исходным кодом NGINX или сервер NGINX Plus, перед сервером приложений Magento, затем используйте сервер NGINX для микрокэширования. Если сервер NGINX находится на переднем крае, это освобождает от обработки и кэширования интернет-трафика из Magento, одновременно снижая пиковые требования к обработке на сервере приложений на один или два порядка. Это также открывает возможности для расширения до нескольких серверов приложений, балансировки нагрузки между ними и мониторинга, которые позволяют масштабировать сайт без изменения логики ядра приложения.

Добавить несколько серверов приложений с балансировкой нагрузки

If you have a simple web server architecture, adding load balancing is the quickest step you can take to make it more flexible and resilient. (The NGINX Admin Guide has extensive details on load balancing.)

Load balancing assumes a few things that we should spell out, because each item can be either a gateway for better performance, or a performance bottleneck:

  • Web and/or application servers. A reverse proxy server can improve performance even if you have just one application server, as it offloads Internet traffic from the application server, can implement static caching, and provides the first building block for a more robust setup. However, the promise of a more robust setup is only fully realized when you use multiple web and/or application servers and load balance between them.
  • Smart load-balancing strategy. You need a load-balancing strategy that makes sense for your web application. “Next request goes to next server” — also known as round robin — is a good start. But taking steps to send traffic to a less-used server, to keep specific clients on the same server during a session, and to monitor processing as it occurs are all important elements of an effective load-balancing strategy. (Click for more information on the advanced load-balancing and monitoring features in NGINX Plus.)
  • Resource extensibility and flexibility. A smart load-balancing strategy should allow you to almost arbitrarily route traffic and add resources, whether running on physical servers or in the cloud, to meet spikes and long-term increases in demand.
  • Use of additional features. Using your reverse proxy server to support additional features such as content caching (as mentioned), SSL termination //link//, HTTP/2 termination //link//, and so on are important steps for maximizing your investment in a more complex site architecture and minimizing the impact of placing an intermediary between your application server and the Internet.

Note: For a deeper description of where a reverse proxy server fits in your application architecture, see our article on Layer 7 Load Balancing.

Limit Incoming Requests per User

A typical web page may have more than 100 assets, including the core HTML file, images, and code files. WIth the typical browser opening half a dozen or so connections per user session, a user moving quickly through your site may generate a small blizzard of requests.

However, both legitimate and illegitimate non-human users may generate many more requests than an actual visitor. During busy periods, you want to take extra care to preserve site capability for regular users.

Spiders for search engines are one example of a non-human, high-resource user; a spider can hammer a site, slowing performance for regular users. Use the HTTP gateway to restrict access, shutting out high-volume (generally, not human) users. Restrictions include the number of connections per IP address, the request rate, and the download speed allowed for a connection. You can also take additional steps to prevent distributed denial of service (DDoS) attacks.

Conclusion

Black Friday, Cyber Monday, new product releases, and other real-world events are an opportunity to examine website architecture for weak points that can lead to slow response times and downtime. But effective performance optimization is a continual process.

Set goals, review your architecture, then search for weak points and vulnerabilities. NGINX open source and NGINX Plus are widely known remedies for site performance problems, opening the door for many different optimization techniques.

33
Share: