Разработка → LRU, метод вытеснения из кэша
К сожалению, в очередной раз заметил, что почти все мои коллеги не знают, что такое LRU, и как реализовать кэш определенного размера. Поэтому я решил написать небольшую статью, где расскажу как быстро реализовать метод LRU, и не вынуждать коллег вручную сбрасывать кэш там, где не требуется.
Мы будем под кэшированием понимать сохранение результатов вычислений в ответ на некоторые запросы. То есть, повторный результат запроса не всегда вычисляется заново, но иногда берется из таблицы, называемой кэшем. Сложно переоценить роль кеширования в современных системах. При этом часто возникает проблема, связанная с недостатком памяти. Действительно, что делать, если запросов много, а памяти хватает лишь для хранения ограниченного числа результатов? В этом случае, как правило, кеш стрится следующим образом. Фиксируется размер кэша, пусть будет N, и сохраняются результаты только для N самых «популярных» запросов.
То есть сохраняются результаты вычислений, которые скорее всего запросят заново.
Как определять эти «популярные» запросы? Наиболее известным способом является LRU, о котором я и расскажу в этой статье.
Мы будем под кэшированием понимать сохранение результатов вычислений в ответ на некоторые запросы. То есть, повторный результат запроса не всегда вычисляется заново, но иногда берется из таблицы, называемой кэшем. Сложно переоценить роль кеширования в современных системах. При этом часто возникает проблема, связанная с недостатком памяти. Действительно, что делать, если запросов много, а памяти хватает лишь для хранения ограниченного числа результатов? В этом случае, как правило, кеш стрится следующим образом. Фиксируется размер кэша, пусть будет N, и сохраняются результаты только для N самых «популярных» запросов.
То есть сохраняются результаты вычислений, которые скорее всего запросят заново.
Как определять эти «популярные» запросы? Наиболее известным способом является LRU, о котором я и расскажу в этой статье.
Серверная оптимизация → Простой принцип кеширования сайта из песочницы
Столкнувшись однажды с вселенским злом DDos-атакой, мне пришлось быстро написать библиотечку для снижения нагрузки на сервер, а точнее для кеширования всего сайта в файлах.
К моему удивлению, нагрузка упала примерно в 20 раз.
К моему удивлению, нагрузка упала примерно в 20 раз.
Разработка под Android → Кеширование изображений на SD карте из песочницы
Совсем недавно пользователь sly2m описал свой метод сохранения изображений из ImageView на SD карту телефона. Кто-то (лично я например) ожидал от этого поста нечто иное, а именно:
1. Работа с изображениями из Интернета
2. Автоматическая загрузка и сохранение таких изображений
3. Продвинутое кеширование изображений
Если заинтересовало — прошу взглянуть.
1. Работа с изображениями из Интернета
2. Автоматическая загрузка и сохранение таких изображений
3. Продвинутое кеширование изображений
Если заинтересовало — прошу взглянуть.
Веб-разработка → Повторно используемый кэширующий прокси на JavaScript из песочницы
Проблема
Ни для кого не секрет, что производительность и по сей день остается одним из основных показателей качества веб-приложения. И, конечно, любой веб-разработчик провел не один час, оптимизируя свое приложение и добиваясь приемлемой производительности, как на серверной, так и на клиентской стороне. Несмотря на то, что аппаратное обеспечение день ото дня становится все мощнее и мощнее, всегда находятся узкие места, которые бывает непросто обойти. С приходом AJAX, HTTP запросы стали «мельче» по объему получаемых на клиента данных, но их количество увеличилось. Каналы связи могут быть достаточно широкими, а вот время соединения и процесс формирования ответа на сервере могут занимать значительное время. Кэширование результатов запросов на клиенте может значительно повысить общую производительность. Не смотря на то, что кэширование может быть настроено на уровне HTTP протокола, часто оно не удовлетворяет реальным требованиям.
SQL → О кэшировании ресурсоемких SQL-запросов на веб-сервере из песочницы
В этой статье я постараюсь описать распространенную ошибку создателей систем кэширования
Началось всё в далекие времена, когда я управлял сайтами, которые были расположены на хостинге в FreeBSD jail, который был весьма ограничен в ресурсах. Почему так? Потому, что я использовал для отображения отчетов и печатных форм расширение pdflib, которого в наборе расширений на стандартном хостинге не было. Я скомпилировал там свой apache и php, залил туда документы и сайт заработал.
Началось всё в далекие времена, когда я управлял сайтами, которые были расположены на хостинге в FreeBSD jail, который был весьма ограничен в ресурсах. Почему так? Потому, что я использовал для отображения отчетов и печатных форм расширение pdflib, которого в наборе расширений на стандартном хостинге не было. Я скомпилировал там свой apache и php, залил туда документы и сайт заработал.
.NET → Postsharp. Решаем задачу кэширования
Иногда попадаются такие ситуации, в которых нет никакой возможности ускорить работу некоторой операции. Она может зависеть от какого-то сервиса, который располагается на внешнем web сервере, или это может быть операция, которая дает высокую нагрузку на процессор. Или же это могут быть быстрые операции, однако, их параллельная работа может высосать из вашего компьютера все ресурсы производительности. Существует огромное количество причин чтобы использовать кэширование. Следует отметить, что PostSharp, изначально не предоставляет решений для вас какого-либо фреймворка кэширования, просто он позволяет сделать эту задачу на порядки быстрее, без каких-либо занудных действий, типа расстановки кода, отвечающего за кэширование по всему исходному тексту программы. Он позволяет решить эту задачу элегантно, вынося задачи в классы и позволяя их повторно использовать.Системное программирование → Беззамочные алгоритмы: ненастойчивый кэш
(Тот факт, что русского перевода понятию «lock-free» в литературе ещё не устоялось, — нисколько меня не убеждает, что такого перевода не должно быть.)
Предположим, анализ производительности вашего приложения выявил, что существенная часть процессорного времени тратится в некой вычислительной функции, и более того, эта функция многократно вызывается с одними и теми же параметрами — выполняя одинаковые вычисления вновь и вновь. Напрашивается простая оптимизация — кэш из одной записи, в котором бы хранились исходные данные и результат последнего вычисления.
Само собой, этот код потоконебезопасен: если один поток находится внутри вызова
Простое решение — заключить код в критическую секцию; но простота идёт в ущерб производительности: если, скажем,
Посмотрим, как можно реализовать наш кэш беззамочно.
Предположим, анализ производительности вашего приложения выявил, что существенная часть процессорного времени тратится в некой вычислительной функции, и более того, эта функция многократно вызывается с одними и теми же параметрами — выполняя одинаковые вычисления вновь и вновь. Напрашивается простая оптимизация — кэш из одной записи, в котором бы хранились исходные данные и результат последнего вычисления.
BOOL IsPrime(int n)
{
static int nLast = 1;
static BOOL fLastIsPrime = FALSE;
// если значение параметра не изменилось с прошлого раза,
// воспользуемся готовым результатом
if (n == nLast) return fLastIsPrime;
// вычислим и запомним новый результат
nLast = n;
fLastIsPrime = slow_IsPrime(n);
return fLastIsPrime;
}
Само собой, этот код потоконебезопасен: если один поток находится внутри вызова
slow_IsPrime(), то другой поток, вызвавший IsPrime(), застанет значения переменных nLast и fLastIsPrime несоответствующими одно другому.Простое решение — заключить код в критическую секцию; но простота идёт в ущерб производительности: если, скажем,
nLast = 5, fLastIsPrime = TRUE, и два потока одновременно вызывают IsPrime(5), то совершенно ни к чему им выстраиваться в очередь: ничего не мешает им одновременно воспользоваться кэшированным значением.Посмотрим, как можно реализовать наш кэш беззамочно.
MODx CMS → CacheAccelerator для MODx Evo. Уменьшение в разы количества запросов к базе за счет кэширования динамических сниппетов из песочницы
Всем привет. Я совсем недавно познакомился с MODx CMF. Осваиваю в данный момент версию Evolution. Система в целом довольно приятная и очень гибкая, однако, ознакомившись поближе, я обнаружил ряд недостатков. Причем некоторые из них не давали мне никакого покоя и оставлять как есть я никак не смог.
Остановлюсь на одном из самых чувствительных критериев любой CMS/CMF — производительности.
В целом, с производительностью у MODx все норм. Сам он написан достаточно грамотно, оптимизирован. Более того, за счет своей гибкости, дает разработчику возможность самому управлять узкими местами в реализуемом проекте.
Тем не менее, меня просто шокировал метод обработки вывода новостей с помощью Ditto, комментариев с помощью Jot и тд. А именно, необходимость отключать кэширование как для всей страницы у Ditto (из-за проблем в работе с PHx), так и для вызова самого сниппета у Jot.
Ведь, если записей достаточно много, то на одной странице они не поместятся, а это значит что, например, новостную ленту нужно разбивать на несколько страниц. Но, если в MODx включено кэширование этой страницы, то при переходе между частями новостной ленты, мы увидим все то же содержимое, которое первое попало в кэш!
Что же советуют официальные источники?
Они советуют, чтобы сниппеты, работающие с несколькими
страницами, никогда не кэшировались.
Остановлюсь на одном из самых чувствительных критериев любой CMS/CMF — производительности.
В целом, с производительностью у MODx все норм. Сам он написан достаточно грамотно, оптимизирован. Более того, за счет своей гибкости, дает разработчику возможность самому управлять узкими местами в реализуемом проекте.
Тем не менее, меня просто шокировал метод обработки вывода новостей с помощью Ditto, комментариев с помощью Jot и тд. А именно, необходимость отключать кэширование как для всей страницы у Ditto (из-за проблем в работе с PHx), так и для вызова самого сниппета у Jot.
Ведь, если записей достаточно много, то на одной странице они не поместятся, а это значит что, например, новостную ленту нужно разбивать на несколько страниц. Но, если в MODx включено кэширование этой страницы, то при переходе между частями новостной ленты, мы увидим все то же содержимое, которое первое попало в кэш!
Что же советуют официальные источники?
Они советуют, чтобы сниппеты, работающие с несколькими
страницами, никогда не кэшировались.
Google App Engine → Кэширование в Google App Engine
Как вы уже знаете из предыдущей статьи, в App Engine есть множество способов хранения информации. Но многие из них весьма специфичны, и для повсеместного пользования подходят всего три: память инстанса, memcache и datastore.Под катом вас ждёт изложение в цифрах и картинках, краткие рекомендации по кэшированию и исходные коды простого cacher'a и приложения для тестов.
Drupal → Кэширование на Drupal
Недавно я столкнулся с тем, что мой сайт на Drupal стал тормозить. Причем, сайт не особо то и посещаемый. В конечном счете, проблема решилась переходом на другой хостинг (shared-хостинг от Руцентра не выдерживал никак), но рассказать я хочу не об этом, а о проблемах ускорения Drupal путем кэширования, с которыми я столкнулся.
Итак, какое инструменты для ускорения существуют на Drupal?
Итак, какое инструменты для ускорения существуют на Drupal?