Подписка на RSS

Рубрика «архитектура»

В статье описываетеся способ кэширования страниц и блоков (например блока авторизации и блока содержания) с применением технологий SSI, memcachedи nginx. С помощью SSI Web-сервер делает дополнительные запросы к бэкэнду, и в связке с кешированием это становится мощным инструментом. Для кэширования же персонализированных данных предлагается добавлять идентификатор пользователя в ключ memcached.

Ссылка: Nginx + Memcached + SSI – кеширование страниц и блоков (partials)

Верите вы или нет, но первая история произошла в середине 70-х.

Во время учебы в средней школе, мне повезло иметь доступ к миникомпьютеру Data General Nova. В отличие от других «космических» компьютеров, Новы были действительно очень крутыми. У них была возможность непрямой адресации, которая означала, что вы можете сделать любой адрес как непрямой, что заставит использовать этот адрес аппаратно как адрес адреса. Эта возможность делала вызовы и передачу параметров очень быстрой. Единственным недостатком была возможность зависания машины, если вы заставляли адрес ссылаться на самого себя).

Как бы то ни было, моей задачей было написать программу классификации. Эта программа должна была получать вход на оптических карточках (которые были как перфокарты, с тем отличием, что нужно было заполнять точечки карандашом, вместо того, чтобы пробивать отверстия), сравнивать ответы по ключу и выдавать всевозможные отчеты в качестве результата. Все просто, не так ли?

В моем предыдущем посте о управление параллельностью я говорил о том, что из-за экспоненциального роста времени ответа от увеличения параллельных запросов лучше отклонить лишние запросы, чем позволить им негативно влиять на вашу систему. Такой метод является выходом, но не самым желаемым. Очередь запросов предоставляет более мощное решение.
Одним из важных принципов построения системы с высоким коэффициентом готовности — это управление параллельностью. Идея заключается в том, чтобы разрешить ровно столько трафика, сколько ваша система может успешно обработать. Например: если проверено, что ваша система может обработать 100 одновременных соединений, тогда 101-ому запросу должно быть предложено попробовать попозже или подождать, пока один из 100 предыдущих запросов выполнится. Нельзя позволять 101-ому запросу негативно воздействовать на других 100 пользователей. Задержки должны быть только в выполнение 101-го запроса.