0

Вопрос:Проблемы с кэшированием Многоязычная веб-данных - Python - Google App Engine

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

Мой текущий подход заключается в следующем:

У меня есть многоязычный питон Google App Engine проекта. Многоязычная часть использует Babel и различные языки .po и .mo файлы для перевода. Это все прекрасно и денди. Проблемы, возникающие при рассмотрении кэширования данных. Например, допустим, у меня есть 1000 списков продуктов, которые я хочу, чтобы клиенты могли получать доступ к 100 за раз. Я использую memcache с объектом резервного копирования хранилища данных, если memcache взорван. Опять же, все прекрасно и денди, но не многоязычно. Каждый продукт должен быть сопоставлен, чтобы соответствовать ключу с конкретной локалью любого клиента, английского, французского, турецкого и любого другого. То, как я делаю это сейчас, - это сопоставить продукты под определенной локалью, например «en_US», и отобразить серверную часть с помощью шаблонов jinja2. Каждый бит данных, который является многоязычным, визуализируется с использованием настроек языкового стандарта для даты, названия форматирования цены и т. Д. И т. Д. В формате «en_US» и помещается в хранилище данных и memcache, все красиво составленные для рендеринга. Тем не менее, у меня есть дополнительный шаг, чтобы получить эти многоязычные данные в правильном формате для локали клиентов, и это делается в виде стандартных {{}} переводов и фильтров jinja2, как правило, для таких вещей, как форматирование цены и даты. Проблема в том, что это замедляет работу, так как все это нужно отображать на сервере, а затем передавать обратно клиенту. Первоначальные 100 продуктов всегда отображаются на стороне сервера, однако до кэширования я предоставлял остальную клиентскую сторону из данных JSON через аякс-вызовы на сервер. Теперь это все рендеринг на стороне сервера.

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

+0

Вопрос является способом широкого. –

+0

Тим, я должен не согласиться. Прочтите последний параграф. Это в основном суммирует его. Я не прошу конкретного решения, у меня его есть. Не означает, что я доволен этим и задавался вопросом, как другие люди справляются с такими проблемами. – Chez

ответ

1

Я предполагаю, что индивидуальный рендеринг продукта в конкретный язык учитывает большинство (или, по крайней мере, большой кусок) усилий по рендерингу для всей страницы.

Вы можете кэшировать серверные результаты рендеринга продукта для определенного языка, прежде чем собирать их на полной странице результатов и отправлять их клиенту, используя схему поиска 2D product x language.

Вы также можете отобразить индивидуальную информацию об изделии в автономном режиме в очереди задач, когда товары будут добавлены/изменены, а также будут хранить/кэшировать их на сервере раньше времени. Может быть, для самых сильно используемых языков?

Таким образом, вы избегаете индивидуального рендеринга продукта на критическом пути - в ответ на запросы клиентов за счет добавления memcache/storage.

Вам просто нужно:

  • разделить ваш рендеринг в 2 этапа (индивидуальная информация о продукте и полные результаты страницы сборки)
  • добавить логику для очистки/обновления хранимого/кэшированных оказанной информация о продукте, когда продукты добавить/изменить/удалить ops
  • (возможно) добавить логику для рендеринга информации о продукте по требованию, когда информация о предварительном рендеринге еще не доступна, когда клиентский запрос приходит (если не разрешено просто не отображать информацию)

может хочу проверить, желательно ли кэшировать/хранить информацию о рендерном продукте, сжатую (html сжимается хорошо) - балансировка расходов на кэширование памяти/хранилища vs затраты на время исполнения и время отклика (я еще не сделал такой эксперимент) ,

+0

Привет, Дэн, да, пятно на странице, страница продукта, которая выложена множеством из 100 предметов. Я рассмотрел офлайн-рендеринг и буду смотреть на него дальше. В настоящее время у меня есть код, который обрабатывает любые обновления или удаляет файлы в кеше с помощью задач. Я также рассматривал по запросу - поэтому, когда клиент видит последние продукты, я доставляю первые 100, а затем выполняю в задаче следующие 100 и так далее. Это может быть наилучшим подходом в настоящее время. Я собираюсь немного поэкспериментировать и посмотреть, как это происходит. – Chez

 Смежные вопросы

  • Нет связанных вопросов^_^