Постобработка обратных HTTP-запросов? (как ESI Akamai) - PullRequest
Новая
       16

Постобработка обратных HTTP-запросов? (как ESI Akamai)

6 голосов
/ 30 ноября 2008

Мы запустили сайт с относительно большим объемом контента. Как и большинство контентных сайтов, большая часть каждой страницы является относительно статичной. Статьи редко меняются, что делает их хорошими кандидатами на статическое / краевое кэширование. Однако есть две большие проблемы. Элементы вторичной страницы (навигация, недавние списки содержимого и т. Д.) Изменяются довольно часто, быстро аннулируя «полные» кэшированные страницы. Также довольно часто мы добавляем на страницу больше динамических битов, таких как пользовательская информация и т. Д.

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

<html>
<body>
  <div id="content">
    Lorem ipsum whackem smackem.
    <%
      dynamic "http://related.content.service/this/story"
    %>
  </div>
  <div id="sidebar">
    <%
      dynamic do |request|
        url = "http://my.user.service/user-widget.html"
        if request.cookies.contains?("user_token")
          url = "http://my.user.service/" + request.cookies["user_token"] + "/user-widget.html"
        end

        error_text = "User service not available"
        { :url => url, :timeout => 500, :error => error_text }
      end
    %>
  </div>
</body>
</html>

В этом примере вы увидите небольшой кусочек Ruby, который определяет включаемый файл на основе значения cookie, а затем возвращает хэш с URL-адресом для извлечения, тайм-аут и некоторый текст по умолчанию для отображения в событие ошибки. Теоретически все включения могут быть запрошены также асинхронно.

Насколько я понимаю, Amazon делает что-то подобное. Бэкэнд-сервисы генерируют различные компоненты страницы со строгим ограничением времени ожидания для обеспечения общей скорости страницы. Я надеялся, что их сервис CDN будет включать что-то вроде этого, но это не так!

Существует спецификация W3 для Edge Side Includes (ESI) - почти то, что я хочу. Однако там очень мало поддержки. Он доступен через Akamai, есть программное обеспечение Oracle, которое делает это, и кэш Varnish с открытым исходным кодом имеет очень простую реализацию. Это также действительно уродливый формат XML.

Итак, вопрос в том, что мне позволят делать то, что я хочу? Кто-нибудь еще так поступает?

Ответы [ 4 ]

2 голосов
/ 22 апреля 2010

Получается, что у Varnish есть (и была) базовая поддержка ESI, которая делает почти все, что я хотел. Если кому-то и нужно что-то делать с ESI, Varnish, похоже, хорошо с этим справится. Это довольно простой, но все же потрясающий.

2 голосов
/ 30 ноября 2008

установите Nginx в качестве внешнего интерфейса и используйте SSI для выбора динамических частей страниц. Динамическим источником может быть HTTP-сервер, такой как Apache, или сервер FastCGI, например, PHP или Django.

редактирование:

Многие веб-серверы поддерживают некоторую форму SSI (Server Side Includes), эта функция позволяет добавлять некоторые теги в HTML как очень ограниченную форму сценариев, гораздо более простую и быструю (и более старую), чем PHP. Используя это, вы можете установить статические страницы с большей частью контента, а для «небольших динамических частей» тег SSI ссылается на динамическую страницу, созданную где-то еще.

Мне особенно нравится nginx как интерфейс практически ко всему. он быстро работает, не требует много ресурсов и отлично масштабируется (подумайте, что лучше, с более чистым и стабильным кодом). автор описывает его не как веб-сервер общего назначения; но как интерфейс прокси. Бэкэндами могут быть HTTP-сервер (обычно Apache) или процессы FastCGI (PHP, Python, Perl и т. Д.) Или ферма одного из них или обоих.

модуль memcached удивителен, он использует memcached (который является самым быстрым и наиболее масштабируемым распределенным хеш-таблицей общего назначения) для прямой связи веб-страницы с URL-адресом, без доступа к диску. поскольку memcached доступен извне самого веб-сервера, его можно использовать даже с динамическими страницами (при условии нормального сопоставления URL / ресурса); но я не думаю, что это очень поможет в вашем случае. в любом случае, сначала сделайте так, чтобы он работал с SSI, затем вы можете (при необходимости) оптимизировать динамическую часть с помощью memcached.

1 голос
/ 13 апреля 2011

Akamai предлагает решение для Edge Computing, которое позволяет запускать J2EE на Edge. Другие альтернативы сегодня включают любую услугу облачных вычислений - Rackspace и Amazon являются парой игроков на этом рынке. В идеале вы должны использовать комбинацию CDN и облачных вычислений, чтобы получить желаемый результат. Кроме того, вы можете выбрать, чтобы динамический контент обслуживался асинхронно через веб-сервис после загрузки шаблона страницы, а затем просто кэшировать статическое содержимое страницы с помощью шаблона html.

1 голос
/ 30 ноября 2008

Я знаю, что несколько человек писали об использовании nginx SSI с модулем memcache nginx для объединения фрагментов контента. Это намного более ограниченно, чем что-то вроде ESI, но все же полезно.

...