memcached integration idea + other ideas

[Sergey Pofiriev <parf@xxxxxxxxx>]

Комментарий к оригинальной статье "memcached integration idea + other ideas"


Я забыл упомянуть важный факт:
рассматривалась схема когда
nginx стоит на dedicated машине и используется как proxy_pass & load 
balancing
сам сайт имеет ~1M hits / day
вынос статики помог разгузить главные машины.


2. Static Auto Caching

Сейчас делаем sync статики через rsync -
но это неудобно и могут возникать моменты что ссылка есть а image еще не 
готовы.
Предлагаемая схема кеширования статики полностью убирает всю эту 
головную боль.
Более того - такую конфигурацию можно ставить для ускорения любого сайта 
не меняя при этом никаких его настроек.
** еще возможный вариант использования -
географическое зеркало - accelerated зеркала US сайта в EU, Asia

3. Dynamic Data Caching.

> >     Cache files according to  X-cache header
> >   
> >     Example:
> >       header("X-cache: $timeout");   // cache url call for given timeout
> >  закешировать результат на $timeout sec в ключе F(URL, PARAMS)
A1.
">" - comments from sjsoft
> Да и динамика судя по всему будет кэшироваться, очень странным
> образом. Как бы скрипт не будет отвечать за
> достоверность кэша вообще.
Мы говорим о memcached - а не просто memcache
Если надо обновить данные до завершения timeout (когда они сами обновятся)
достаточно просто удалить/обновить ключ в cache


A2.
> Ведь, даже если скрипт вызыван с теми же параметрами,
> он может делать запросы из базы, в которой чтолибо уже изменено. А так
> кэш будет упорно показывать старые данные.
Кеш для этого и делается чтобы лишний раз не нагружать backend
см(#A1)

Например меня вполне устроит дискретность в 1-5 минут для обновления многих 
страниц.
(для некоторых устоит и часовая дискретность)


> > 5. Redirect to "hash key"
> >     When page returns X-redirect-cache header:
> >     Return page stored in memcached key (key = value of 
> >
> > "X-redirect-cache" header)
> >     OR (if no page found)
> >     Internal redirect to  $no_key_url  and return content to caller
> >        in case of redirect server should pass "key" to $no_key_url ( as
> > a header or as a GET field )
достаточно необходимая функция
1. позволяет на backend разбирать что и как кешировать
  самому выбирать F( URL, PARAMS, whatever )

2. позволяет на backend контролировать когда cache должен обновляться
  те тот вопрос что ты спрашивал в #3

3. позволяет убрать дублирующиеся данные.
  самый простой пример - www.sitename.com == sitename.com

> Если бы тока эти пункты выполнялись, было бы вообще
> зачем что либопеределывать в nginx.:
>  1) Если memcached хранит весь свой кэш в памяти и работает с ним
> существенно быстрее чем с рам-диском.
- также + см load balancing config

> 2) Если в memcached будет всегда актуальная информация
> лежать а не устаревшая и актуальность ее будет проверена
> скриптом, как в пункте 5 по хэшу.
неактуальные ключи можно всегда удалить
+ см выше


> 3) Если бы в каждом новом коде не появлялись бы
>  уязвимости и баги, да не добавлялось бы тормозов. тобишь, при компиляции
> можно было бы отрезать этот модуль кому он не нужен.
уже сейчас в ngnix есть memcached support implemented as a module (see source 
code)
тч гемморой [ :)  ]  может быть только для желающих




PS: дополнительные плюсы

1. упрощение администритования nginx server
  - весь контроль делается на backend
  разворачивание сервера будет очень простым -
  прописал memcached server(или установил на этот же сервер)
  сделал config - и готово

2. Network Computing
  доп сервера могут генерировать разный content и класть его в memcache

3. простота построения M-M solutions
  Many Servers <-> Many Nginxs
  тк не надо думать об актуальности filesystem data.   

PPS: для совсем хорошего решения хотелось бы еще иметь template engine

TEMPLATE= CACHE_KEY.get_data ||  URL.get_data

// template can have references to other memory keys|url

output = PROCESS_TEMPLATE( TEMPLATE, SUBSTITUTIONS )

SUBSTITUTIONS - key => value hash

Example:

 %key%      - SUBSTITUTIONS["key"]
 %%key|url% - KEY.memcached_data || URL.get_data
 %/url%     - subrequest to url  (  URL.get_data )

example:
<html>
...
 %%banners|/banner%%
...

Hello %name%, today is %date%

<h1>News</h1>
 %%fp-news|/update_news%
...
</html>

+  logic:
 %?key{%  key defined %}%
 %!key{%  key undefined %}%
 %?key=value{%  key=%key% %}%


+ html escaping ( avoid/protect site from CSS )
My name is %key.e%   // escape
<a href="%key.q%">   // quote escape
<a href="xxx?url=%key.urle%">   // urlencode
<textarea>%key.ta%</textarea>

 %key!%  // - smart - должен сам из template догадаться


Substitutions backend может возвращать как:
k:value
k2:multiline
multiline     // subsequent lines have 1 space identation
multiline
k3:gfdgdfsdf 

у нас есть *project specific* реализации такой схемы - очень удобно
appserver <-> template server <-> [nginx] <-> customers

причем templates храняться на appserver(memcached) - template server довольно 
простая и тупая штука