Песочница → Ускоряем загрузку страниц сайта, или еще пара способов сжатия JS файлов из песочницы
Вариантов разгона сайта существует великое множество. Возможно, приведенные мной ниже способы являются велосипедом, но считаю, что они имеют полное право на жизнь.
Итак, способ №1 – кеширование содержимого JS файлов с помощью Memcached.
Основное требование к данному способу – установленная на сервере библиотека Memcached.
Серверная оптимизация → Простой принцип кеширования сайта из песочницы
Столкнувшись однажды с вселенским злом DDos-атакой, мне пришлось быстро написать библиотечку для снижения нагрузки на сервер, а точнее для кеширования всего сайта в файлах.
К моему удивлению, нагрузка упала примерно в 20 раз.
К моему удивлению, нагрузка упала примерно в 20 раз.
Веб-разработка → Кеширование и теги при использовании ZF + memcached из песочницы
Предисловие
В процессе разработки с использованием связки Zend Framework + Memcached приходится сталкиваться иногда как с (чрезмерной) обильностью имеющегося функционала фреймворка, так и с определёнными ограничениями. Об одном из таких случаев и найденном решении я и попытаюсь рассказать в этой статье.
Описание проблемы
Как известно, Memcached представляет собой относительно простое для использование Key/Value хранилище с простым, необходимым и достаточным функционалом. Предоставляемые ZF интерфейсы для взаимодействия с Memcached включены в общую библиотеку работы с кешем (включает в себя также адаптеры для Sqlite, Xcache, ZendServer и т.д.). Некоторые из этих систем кеширования поддерживают использование тегов для объектов кеширования, однако Memcached такой функцией не обладает, поэтому попытки использовать стандартные интерфейсы классов ZF для кеширования объектов с указанием тегов при работе с Memcached приведут лишь к ошибкам (в логах) вплоть до исключений. (Подробнее можно прочитать в документации).
PHP → Борьба с одновременным перестроением кеша с помощью RED
Описание проблемы
Представим среднестатистический высоконагруженный сайт. Обычно на таких сайтах между backend'ом и DB ставят прослойку кеша. С увеличением количества посетителей, вероятность того, что несколько пользователей одновременно наткнутся на "протухший" кеш увеличивается. Если такое случается, то нагрузка на backend и DB возрастает, что в свою очередь увеличивает время обработки запроса и увеличивает вероятность возникновения подобной ситуации. Вот такая вот система с положительной обратной связью:
Маленькие красные горбики — это "затупившие" на множественном обновлении кеша запросы.
Эта статья будет описывать один из подходов к решению проблемы на примере(
patch attached) связки PHP/APC, однако теоретическая база применима к любому языку и системе кеширования.
Разработка под Android → Кеширование изображений на SD карте из песочницы
Совсем недавно пользователь sly2m описал свой метод сохранения изображений из ImageView на SD карту телефона. Кто-то (лично я например) ожидал от этого поста нечто иное, а именно:
1. Работа с изображениями из Интернета
2. Автоматическая загрузка и сохранение таких изображений
3. Продвинутое кеширование изображений
Если заинтересовало — прошу взглянуть.
1. Работа с изображениями из Интернета
2. Автоматическая загрузка и сохранение таких изображений
3. Продвинутое кеширование изображений
Если заинтересовало — прошу взглянуть.
Nginx → Кеширующий прокси-сервер на nginx. Хитрая конфигурация из песочницы
На Хабре уже есть несколько описаний Nginx, но, думаю, моя конфигурация тоже будет интересна.
Ситуация выглядит следующим образом: есть размещённый на нескольких серверах IIS сайт (интернет-магазин), перед ним расположен балансировщик. Между ними решено установить nginx для уменьшения нагрузки на IIS.
Основная масса динамического контента отображается Ajax-ом, так что кеширование страниц каталога товаров вполне безопасно. Однако на них могут быть отзывы о товаре, за которые можно проголосовать — совсем как на Хабре, что тоже надо учесть.
Плюс к этому хочется поддерживать валидность популярных страниц в кеше автоматически.
Ситуация выглядит следующим образом: есть размещённый на нескольких серверах IIS сайт (интернет-магазин), перед ним расположен балансировщик. Между ними решено установить nginx для уменьшения нагрузки на IIS.
Основная масса динамического контента отображается Ajax-ом, так что кеширование страниц каталога товаров вполне безопасно. Однако на них могут быть отзывы о товаре, за которые можно проголосовать — совсем как на Хабре, что тоже надо учесть.
Плюс к этому хочется поддерживать валидность популярных страниц в кеше автоматически.
Серверная оптимизация → Что кешировать? из песочницы
Всё. На этом можно было бы статью закончить, так как эта аксиома повторяется из года в год на форумах и конференциях и кочует из текста в текст на всех технических ресурсах. Однако это ёмкое «Всё» не поясняет деталей. Ведь существует достаточно широкая прослойка программистов, движки и проекты которых справляются с задачей без мемкеша и шардинга. Но момент нагрузки приходит, и приходится разбираться.
Для таких людей я и разобрал на запчасти это универсальный ответ высоконагруженных проектов.
Ограничимся изучением системы для веба. Попросту говоря, на привычном обычном сайте. Используете ли вы готовую CMS, или уже выросли до каркаса, или написали «с нуля» код для нестандартного проекта – основными элементами процесса приёма-отдачи данных всегда будут одни и те же узлы. Я их рассмотрю с точки зрения «Где что можно закешировать».
Для таких людей я и разобрал на запчасти это универсальный ответ высоконагруженных проектов.
Ограничимся изучением системы для веба. Попросту говоря, на привычном обычном сайте. Используете ли вы готовую CMS, или уже выросли до каркаса, или написали «с нуля» код для нестандартного проекта – основными элементами процесса приёма-отдачи данных всегда будут одни и те же узлы. Я их рассмотрю с точки зрения «Где что можно закешировать».
Nginx → Прозрачное кэширование в nginx для всех и каждого
Представим, что у нас есть сайт, на который регулярно дают ссылки с хабра.
Нам нужно подготовить его к резким всплескам посещаемости. Как это сделать?
С версии 0.8.46 в nginx появились опции, позволяющие легко и просто настроить прозрачное кэширование для анонимных пользователей.
Для работы этой схемы от сайта требуется очень мало: достаточно лишь не начинать сессию, то есть не отправлять сессионную куку, без явной на то необходимости. Редкий сайт нельзя довести до такого состояния, а значит большинство сайтов можно защитить от резких всплесков посещаемости с помощью nginx с минимальными затратами сил и времени.
Нам нужно подготовить его к резким всплескам посещаемости. Как это сделать?
С версии 0.8.46 в nginx появились опции, позволяющие легко и просто настроить прозрачное кэширование для анонимных пользователей.
Для работы этой схемы от сайта требуется очень мало: достаточно лишь не начинать сессию, то есть не отправлять сессионную куку, без явной на то необходимости. Редкий сайт нельзя довести до такого состояния, а значит большинство сайтов можно защитить от резких всплесков посещаемости с помощью nginx с минимальными затратами сил и времени.
Веб-разработка → Пошаговая форма + кеширование промежуточных данных
О пошаговых html формах написано не мало и в общем то ни чего особенного в реализации нет. Обычное дело для получения от посетителя объемных и связанных данных, многим не раз приходилось решать такую задачу.
Чуть более сложнее обстоит дело с реализацией, если пользователю необходимо предоставить возможность возврата на предыдущие шаги формы, с сохранением заполненных ранее данных (отмечу, что речь идет о форме в которой каждый шаг — отдельная страница). Когда требовалась такая функциональность и было не много данных (полей формы) я пришел к следующему решению:
Но такой подход имеет проблему с потерей введенных ранее данных при переходе по прямому url (без submit-а) на любой шаг.
Чуть более сложнее обстоит дело с реализацией, если пользователю необходимо предоставить возможность возврата на предыдущие шаги формы, с сохранением заполненных ранее данных (отмечу, что речь идет о форме в которой каждый шаг — отдельная страница). Когда требовалась такая функциональность и было не много данных (полей формы) я пришел к следующему решению:
- На каждом шаге проверяются данные в специальных hidden input-ах и при наличии используются при подстановке значений полей формы
- Каждый следующий шаг принимает POST данные с предыдущего(их) шагов, сериализует и добавляет в специальные hidden input-ы
- Action формы меняется динамически (js) в зависимости от нажатия кнопки «Вперед» или «Назад», т.е. либо url следующего шага, либо предыдущего
- После чего также с помощью js производиться submit формы
Но такой подход имеет проблему с потерей введенных ранее данных при переходе по прямому url (без submit-а) на любой шаг.
JAVA → Несколько неожиданное поведение кеширования при boxing-е
Недавно на The Daily WTF писали о том, как с помощью Reflection можно неплохо подпортить кровь коллегам.Допустим, у вас есть следующий код:
public class ConstantHolder {
public static final Integer THE_ANSWER_TO_LIFE_THE_UNIVERSE_AND_EVERYTHING = 42;
}
public class TestBoxingVulnerability {
public static void main(String[] args) {
int theAnswer = ConstantHolder.THE_ANSWER_TO_LIFE_THE_UNIVERSE_AND_EVERYTHING;
System.out.println(theAnswer == 42);
}
}
Очевидно, что будет выведено true. Однако в проекте может оказаться такой код, который может изменить ситуацию в обратную сторону. Под катом приведён пример такого кода.