memcached integration idea + other ideas

[sjsoft at newmail.ru]

Здравствуйте, Sergey.

Вы писали 7 октября 2006 г., 6:08:01:

> Memcached integration as a caching mechanism


> MAIN IDEA:

> 1. caching layer
>     if url + params or F(url,params) is in memcached return cached data
> w/o backend call
>    
>      F(x) - function such as crc32 / md5 / sha / ...

>      location /dir {
>           mem_cache on;  // activate cache check prior to backend query
>     }

> 2. Static data auto caching:
>     cache files according to criteria and specified timeout.
>   
>     Example: cache all gif / jpg (  /\.(jpg|gif)$/i  ) files for 10 minutes

>     location ~* ^.+\.(jpg|jpeg|gif)$ {
>        mem_cache on;                 //  turn on caching (#1)
>        mem_cache_ttl 600;            //  default cache time
>     }
А зачем кэшировать статику? Она же неизменна. В чем соль? Если соль в
том, что статика будет в памяти висеть, так используйте рам-диск.
Доступ на рам-диск быстрее, чем на обычные винты. Зачем телеге
пятое колесо?

> 3. Dynamic data caching:
>     Cache files according to  X-cache header
>   
>     Example:
>       header("X-cache: $timeout");   // cache url call for given timeout
Да и динамика судя по всему будет кэшироваться, очень странным
образом. Как бы скрипт не будет отвечать за достоверность кэша вообще.
Ведь, даже если скрипт вызыван с теми же параметрами, он может делать
запросы из базы, в которой чтолибо уже изменено. А так кэш будет
упорно показывать старые данные.

> 4. Internal server redirects
>     header("X-redirect: $timeout");

>     same as in Java Servlets forward.
>     a.    NGINX -> BACKEND1
>     b.    backend returns X-redirect and URL in  REDIR_URL
>     c.    NGINX -> REDIR_URL

>     maybe this already implemented
Вот этот механизм уже реализован в nginx и я считаю его наиболее
перспективным. Скрипт отрабатывает данные и если ничего не менялось(а
скрипт то должен знать, менялось или нет.) он выдает адрес внутреннего
редиректа, на собой же сгенерированую статику. Чем это хуже, если не на рам-диск
будет пихаться а в memcached я не понимаю.

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

>     header("X-redirect-cache: $key $no_key_url")

>     Example:
>     // guess what we want to show
>     $page="index-".random_number( from => 1, to => 10)
>     header("X-cache-key: $page /page-generator")

Если бы тока эти пункты выполнялись, было бы вообще зачем что либо
переделывать в nginx.:
1) Если memcached хранит весь свой кэш в памяти и работает с ним
существенно быстрее чем с рам-диском.
2) Если в memcached будет всегда актуальная информация лежать а не
устаревшая и актуальность ее будет проверена скриптом, как в пункте 5
по хэшу.
3) Если бы в каждом новом коде не появлялись бы уязвимости и баги, да
не добавлялось бы тормозов. тобишь, при компиляции можно было бы
отрезать этот модуль кому он не нужен.

-- 
С уважением,
 sjsoft                          mailto:sjsoft at newmail.ru