|
||||||||||||||||
|
||||||||||||||||
|
| |||||||||||||||
|
||||||||||||||||
|
||||||||||||||||
|
|
 |
| |
|
| |
| |
|
|
|
|
|
АРХИВ :: nginx-ru |
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: proxy_next_upstream + haproxy
Просьба не ругать за криворукость :) Придется начать из далека. Картинки у нас хранятся в hbase (не очень много, пока всего чистыми данными 500 гигов). Извлекаются от туда руби с рельсами. Для ускорения процесса был настроен сквид. Который тупо кешировал все http://127.0.0.1:8000/show_pictures/........ (он торчал на 8000 порту)
Потом появился локальный сквид на машинке которая раздает 90% траффика. Этот сквид имел парента - предыдущего сквида. Все было нормально. Но тут у hetzner-а в DC10 наступил сбой во внутренней маршрутизации. Я с перепугу тот сервер перезагрузил (кто знал что не надо). Они потом мне прислали "ну типа незапланированный сбой поэтому предупредить не могли). В общем, когда все начало работать, то оказалось что картинки раздаются только с одного диска, и производительнось отдачи зависит тупо от одного диска. И пока не нарастится кеш в памяти то все страшно тормозит!
Срочно сквиды были переведены в режим sibling (с перепугу было настроено еще 3 дополнительных сервера под это), Но после этого оказалось что тк урлы которые к ним идут отличаются от http://127.0.0.1:8000/ , и, как следствие, нифига не закешированы.
Haproxy мгновенно спас ситуацию - он висит на 127.0.0.1:8000 и берет из сквидов именно то что нужно (сквиды переехали на исторический 3128 порт). Собственно, все. Возможно сквиды умеют работать в режиме акселератора и не обращать внимания на название хоста, но я этого быстро не нашел, а нужно было спасать ситуацию.
2012/11/29 Maxim Dounin <mdounin@xxxxxxxxxx> Hello! _______________________________________________ nginx-ru mailing list nginx-ru@xxxxxxxxx http://mailman.nginx.org/mailman/listinfo/nginx-ru
|