ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

memcached integration idea + other ideas



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



 




Copyright © Lexa Software, 1996-2009.