Re: nginx и memcache

[Ihalainen Nickolay]

2010/11/7 paranoidchaos <nginx-forum at nginx.us>

> не соглашусь немного - в случае когда
> всего навсего три сервера (один под
> фронт два под бекенды) схема с нфс на
> фронтенде (имеется нфс сервер на
> фронтенде) куда лучше подходит в тех
> случаях когда невозможно управлять
> контентом. (всякие рсинки не помогут -
> надо учесть что контент добавляется по
> фтп или через веб формы соответсвенно
> фтп будет коннектится к фронту а всякий
> веб контент будет добавляться на
> бекендах)
>
> и ещё если посмотреть на лбычный ЛАМП
> то по нфс бекенды будут тянуть только
> (допустим пхп) скрипты которые в свою
> очередь кешируются на уровне байткода
> ну и на уровне фронтенда. и плюс всякий
> аплоад через веб формы будет
> передаваться по нфс на сервер.
>
> пс: если есть другое более негеморойное
> решение (на трёх серверах) - пожалуйста
> в студию.


Для кода больше подходиит распространение через Version control системы
(svn,mercurial,git) или rsync.
Дело в том, что даже при включенных opcode cachers будет делаться syscall
stat на файл. до тех пор, пока stat не отработает (на nfs это как минимум
round-trip time) никаких действий с файлом не будет происходить, т.к. nfs
сетевая ФС, то кешировать stat на клиенте нельзя безопасно.
Скрипты обычно состоят из большого количества подключаемых файлов, вполне
небольшая и милая задержка в 7мс на гигабите вырастает в 700 мс на 100
подключаемых файлах. Если используется php, можно библиотеки объединять в
phar архивы (уменьшать количество ключаемых файлов), но гораздо проще иметь
на backends живые файлы, лежащие в filecache, к которым stat и read не стоит
операций ввода вывода.
Т.е. NFS для web можно использовать практически всегда только для записи,
если количество записей небольшое. Например можно на бекендах по nfs
записывать сгенерированные картинки (запись операция не атомарная, поэтому
сначала надо писать в tmp файл на nfs, а потом уже вызывать rename в
конечный файл).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20101107/5f3cd632/attachment.html>