memcached integration idea + other ideas

[Sergey Pofiriev]

Комментарий к оригинальной статье "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 довольно простая и тупая штука