Google App Engine - кеширование сгенерированного HTML

Я написал приложение Google App Engine, которое программно генерирует кучу HTML-кода, который действительно является одним и тем же выходом для каждого пользователя, который входит в мою систему, и я знаю, что это будет неэффективно, когда код будет в производство. Итак, я пытаюсь найти лучший способ кэшировать созданные страницы.

Самый вероятный вариант - сгенерировать страницы и записать их в базу данных, а затем проверить время операции с базой данных для данной страницы с момента последнего обновления кода. Затем, если код новее, чем последний, помещенный в базу данных (для конкретного HTML-запроса), новый HTML будет сгенерирован и обслужит и будет кэширован в базу данных. Если код старше, чем последний, помещенный в базу данных, я просто получаю HTML-код непосредственно из базы данных и обслуживаю его (поэтому избегаю всех потерь процессора при генерации HTML). Я не только стараюсь минимизировать время загрузки, но и минимизировать использование ЦП.

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

Я открыт для любых предложений по этому подходу или других подходов к кэшированию сгенерированного html.

Обратите внимание, что хотя memcache может помочь в этой ситуации, я считаю, что это не окончательное решение, так как мне действительно нужно только повторно генерировать html при обновлении кода (в отличие от каждого раза, когда истекает срок действия memcache).

Ответ 1

В порядке скорости:

Memcache
кэшированный HTML в хранилище данных
полная генерация страниц

Ваше решение для кеширования должно учитывать это. По сути, я бы, вероятно, рекомендовал использовать memcache в любом случае. Это будет быстрее, чем доступ к хранилищу данных в большинстве случаев, и когда вы создаете большой блок HTML, одним из основных преимуществ кэширования является то, что вы, возможно, не должны были нести ответственность за доступ к данным за ввод-вывод магазин. Если вы используете кеш с использованием хранилища данных, у вас все еще есть штраф ввода-вывода. Разница между регенерированием всего и вытаскиванием из кэшированного html в хранилище данных, вероятно, будет довольно небольшой, если у вас нет очень сложной страницы. Вероятно, лучше получить кучу очень быстрого кеша, удаляющегося из memcache, и выполнять полный регенератор каждый раз в то время, чем каждый раз вызывать вызов в хранилище данных. Там ничего не мешает вам недействить кэшированный HTML-код в memcache при обновлении, и если ваш трафик достаточно высок, чтобы гарантировать его, вы всегда можете выполнять многоуровневую систему кэширования.

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

В любое время, когда вы выполняете оптимизацию производительности, сначала измерьте! Много "оптимизаций" производительности оказываются либо медленнее, чем оригинальные, точно так же, либо имеют отрицательные характеристики пользовательского опыта (например, устаревшие данные). Не оптимизируйте, пока вы не уверены, что вам нужно.

Ответ 2

Некоторое время назад я писал серию сообщений в блоге о написании системы ведения блога в App Engine. Вы можете найти сообщение о статической генерации HTML-страниц, представляющих особый интерес.

Ответ 3

Это не полное решение, но может предложить интересный вариант для кэширования.

Google Appengine Frontend Caching позволяет вам кэшировать без использования memcache.

Ответ 4

Просто выполните статическую версию вашего сайта

На самом деле это намного проще, чем вы думаете.

Если у вас уже есть файл, содержащий все URL-адреса вашего сайта (ex urls.py), половина работы уже выполнена.

Здесь структура:

+-/website
+--/static
+---/html
+--/app/urls.py
+--/app/routes.py
+-/deploy.py

/html - это то, откуда будут загружены статические файлы. urls.py содержит список всех URL-адресов вашего сайта. routes.py(если вы переместили маршруты из main.py) необходимо будет изменить, чтобы вы могли видеть динамически сгенерированную версию локально, но использовать статическую версию в процессе производства. deploy.py - это ваш универсальный генератор статического узла.

Как вы планируете свой модуль URL-адресов. Я лично использую его как универсальный магазин для получения всех метаданных для страницы, но YMMV.

Пример:

main = [
  { 'uri':'about-us', 'url':'/', 'template':'about-us.html', 'title':'About Us' }
]

Со всеми URL-адресами для сайта в структурированном формате он автоматически сканирует ваш собственный сайт как пирог.

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

Вот он:

# Detect whether this the 'Development' server
DEV = os.environ['SERVER_SOFTWARE'].startswith('Dev')

Я предпочитаю помещать это в main.py и выставлять его глобально, потому что я использую его для включения/отключения других вещей, таких как ведение журнала, но еще раз, YMMV.

Наконец, вам нужен сканер/компилятор:

import os
import sys
import urllib2
from app.urls import main

port = '8080'
local_folder = os.getcwd() + os.sep + 'static' + os.sep + 'html' + os.sep
print 'Outputting to: ' + local_folder

print '\nCompiling:'
for page in main:
  http = urllib2.urlopen('http://localhost:' + port + page['url'])
  file_name = page['template']
  path = local_folder + file_name
  local_file = open(path, 'w')
  local_file.write(http.read())
  local_file.close()
  print ' - ' + file_name + ' compiled successfully...'

Это действительно рудиментарный материал. Я был на самом деле ошеломлен тем, как легко это было, когда я его создал. Это буквально эквивалентно открытию вашего сайта по страницам в браузере, сохранению как html и копированию этого файла в папку /static/html.

Лучшая часть: папка /html работает как любая другая статическая папка, поэтому она будет автоматически кэшироваться, и срок действия кеша будет таким же, как и все остальные ваши статические файлы.

Примечание. Это обрабатывает сайт, на котором все страницы обслуживаются с уровня корневой папки. Если вам нужна более глубокая вложенность папок, для его обработки потребуется небольшая модификация.

Ответ 5

Старый поток, но я буду прокомментировать anyways, поскольку технология немного продвинулась... Другая идея, которая может или не может быть одобрена для вас, - это создать HTML-код и сохранить его в Google Cloud Storage. Затем обращайтесь к HTML через ссылку CDN, которую предоставляет облачное хранилище. Не нужно проверять memcache или ждать, пока datastore не проснется при новых запросах. Ive начал хранить все мои JavaScript, CSS и другие статические материалы (изображения, загрузки и т.д.), Как это для приложений appengine и его работы для меня.