React.Js: достижение времени отклика сервера 20 мс с помощью рендеринга и кэширования на стороне сервера

  1. Маленький фон
  2. Вступает в реакцию!
  3. Вопросы !
  4. Входит Redis!
  5. Сожмите Больше!
  6. Разрушение кэша
  7. Выводы

Мы все любим ReactJ за его производительность рендеринга, модульность и свободу выбора стека. Но есть одна вещь, которая выделяет его. Рендеринг на стороне сервера . До React большинство фреймворков javascript были сосредоточены на создании одностраничных приложений и проделали довольно большую работу. Но сейчас 2016 год, эра гибридных приложений! Приложения, которые могут работать за пределами браузера . React начал тенденцию, поддерживая рендеринг на стороне сервера, что позволяет нам создавать сквозные приложения javascript.

Маленький фон

Мы все любим ReactJ за его производительность рендеринга, модульность и свободу выбора стека

Я сейчас работаю над Practo's Healthfeed место, где врачи и специалисты в области здравоохранения пишут статьи о здоровье и делятся своим опытом. Если не что-то иное, любая блог-платформа должна быть хороша в ОДНОЙ вещи больше всего: в SEO . Любой блог с хорошим SEO предназначен, чтобы получить больше читателей, чем кто-либо еще. И больше читателей означает больше SEO!

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

  • Создание вашего сайта для ботов .
  • Сделай это БЫСТРО . Как Тысячелетний сокол быстро!

Вступает в реакцию!

Когда вышел React, одним из преимуществ его продажи было то, что он поддерживал рендеринг на стороне сервера (SSR). Чтобы ваше приложение поддерживало SSR, все, что вам нужно, это сервер узлов и API . Современная архитектура выглядит примерно так:

Современная архитектура выглядит примерно так:

Обратите внимание! Сервер узла действует как посредник между пользователем и сервером API. Итак, поток выглядит так:

  • Пользователь нажимает на URL, запрос отправляется на Node Server .
  • Node Server отправляет запрос на API-сервер и получает данные с API- сервера.
  • Отправляет данные в приложение , которое, в свою очередь, создает окончательный HTML-код для пользователя.
  • Возвращает строку HTML обратно пользователю.

Теперь вся настройка завершена! Сервер принимает запросы, API - ответ, и, наконец, пользователи / боты получают полностью отображаемую HTML-страницу. Но это может оказаться кошмаром для пользователя .

Вопросы !

  • Что делать, если сервер API работает медленно ? Как время отклика 500 мс.

Одна из проблем, связанных с рендерингом на стороне сервера, заключается в том, что его время отклика сильно зависит от времени отклика сервера API. Это означает, что независимо от того, насколько эффективным и быстрым было ваше приложение, пользователь увидит белый экран, по крайней мере, 500 мс, при условии, что ваш сервер узла имеет время отклика 0 мс. Что практически невозможно (пока).

Итак, давайте посмотрим на разбивку здесь:

  • Время отклика 500 мс от API
  • 150 мс для рендеринга на стороне сервера (да, это занимает столько времени)
  • 10 мс для узла сервера
  • 150 мс задержка в сети

Таким образом, пользователь получит ответ через почти 810 мс ! Сейчас, конечно, это просто средние цифры, но в реальном мире это может быть намного хуже. Так как у нас нет большого контроля над задержкой в ​​сети, мы не допустим этого. Таким образом, время отклика сервера в настоящее время составляет 660 мс .

Чтобы улучшить ситуацию, мы сначала поймаем самую большую рыбу: время отклика API.

Входит Redis!

Redis - одно из самых мощных хранилищ структур данных, которое очень быстрое и эффективное. Там вы можете хранить все что угодно в виде пар ключ-значение. Интеграция Redis для хранения среды узла очень проста. Если мы сохраняем результат API в redis , мы можем сохранить нашу сетевую поездку на сервер API.

Так что теперь, когда пользователь делает какой-либо запрос, сервер узла будет запрашивать Redis, если у него уже есть ответ. Если это так, он напрямую передает его в приложение для рендеринга и, наконец, возвращает строку HTML. Если у него нет ответа, мы продолжим и вызовем API, а затем сохраним этот результат в redis перед передачей его в приложение.

Новая разбивка будет:

  • 150 мс для рендеринга на стороне сервера
  • 5 мс для сервера Redis (ПРИМЕЧАНИЕ. Время рендеринга может быть меньше или очень велико, в зависимости от размера приложения.)
  • 10 мс для узла сервера

С помощью простого кэширования наших ответов API мы упали с 660 мс до 160 мс .

Сожмите Больше!

Хотя 160 мс - это хорошо, мы можем получить больше, просто используя небольшую хитрость.

Вместо того, чтобы хранить ответ API в redis, почему бы не сохранить саму всю строку HTML?

и это был результат!

и это был результат

Среднее время отклика упало до 20 мс !

Разрушение кэша

Если не обращаться должным образом, кэширование становится болью в заднице. Люди начинают постоянно сообщать о старых данных / ошибки становятся обычным явлением. Так что с большим кешем нам также нужна хорошая стратегия очистки кеша. Обычно у нас есть два случая, когда мы должны очистить кеш:

  • Когда автор обновляет статью. (Когда происходят обновления данных)

Когда автор обновляет что-то, он хочет видеть изменения, отраженные немедленно! Для этого мы создали небольшой кэш параметров = false. Всякий раз, когда URL-адрес попадает с этим URL-адресом, сервер узла выполняет и вызов API вместо выборки данных из кэша Redis. И, следовательно, кэш обновляется новыми данными.

Каждый раз, когда вы развертываете, генерируется новый чанк для файлов js и css. Это означает, что если вы сохраняете всю строку HTML в кэше, она станет недействительной при развертывании. Следовательно, всякий раз, когда вы развертываете, redis db должен быть полностью очищен.

Выводы

Узел быстрый. Так же как и Реакт! Но иногда нам нужно добавить нового игрока, чтобы достичь этой невозможной цели, не жертвуя при этом очками пользовательского опыта. Redis - это круто. Используйте все это с умом.

Вместо того, чтобы хранить ответ API в redis, почему бы не сохранить саму всю строку HTML?
Stylish-Portal.infO 2011
При копирование материала активная ссылка на сайт!
Copyright 2004-2016 © www.zone55.ru. All rights reserved.