2008-11-30 2 views
6

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

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

<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> 

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

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

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

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

ответ

2

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

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

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

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

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

+0

Можете ли вы расширить этот ответ вообще? Не похоже, что это дает мне многое из того, что я хочу, но возможно, что я что-то упустил. – MrKurt 2008-11-30 20:50:32

1

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

2

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

1

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