Кеширование промежуточного кода (Opcode Caching)
Кэширование кода это один из самых легких и эффективных путей увеличения производительности в PHP. Использовании данного вида кэширования позволит избавиться от большого количества неэффективностей, возникающих при процессе запуска выполнения кода. Кэширование кода сохраняет промежуточный код в памяти для того чтобы не компилировать PHP-код каждый раз при запуске файла.

Одим хмурым воскресным утром мне было нечего делать и я решил попробовать написать свой вариант велосипеда – облако тэгов на ASP.Net. Результат получился довольно интересным, поэтому решил оформить его в виде статьи и выложить на Хабре.
Сразу оговорюсь – это результат всего-лишь полуторачасового кодинга, соответственно просьба не воспринимать его как полностью готовый контрол, а лишь как концепт, который еще можно развивать и развивать.

Привет Хабр и всем кто использует PHP фреймворк CodeIgniter!

В процессе создания некого приложения на CI у меня возник вопрос о поиске информации в базе данных без использования GET.
Никаких готовых решений в CI wiki я не нашел, так что решил сделать свой «велосипед».

Иногда возникает необходимость кэширования результатов исполнения методов. Одно из возможных решений для java описано здесь. Всё, в принципе, тривиально: EHCache, Spring AOP для перехвата вызовов, немножко кода.

Рассмотрим, как мне кажется, более элегантное решение на scala.

В web-сервер и reverse-proxy nginx встроены очень мощные возможности по кэшированию HTTP-ответов. Однако в ряде случаев документации и примеров не хватает, в результате не все получается так легко и просто, как хотелось бы. Например, мои конфиги nginx-а местами написаны кровью. Этой статьей я попробую немного улучшить ситуацию.

В этой статье: а) подводные камни при полностраничном кэшировании; б) кэширование с ротацией; в) создание динамического «окна» в закэшированной странице.

Я буду предполагать, что вы используете связку nginx+fastcgi_php. Если вы применяете nginx+apache+mod_php, просто замените имена директив с fastcgi_cache* на proxy_cache*

Если выбирать, кэшировать ли страницу на стороне PHP или на стороне nginx, я выбираю nginx. Во-первых, это позволяет отдавать 5-10 тыс. запросов в секунду без каких-либо сложностей и без умных разговоров о «высокой нагрузке». Во-вторых, nginx самостоятельно следит за размером кэша и чистит его как при устаревании, так и при вытеснении нечасто используемых данных.

Кэширование всей страницы целиком

Если на вашем сайте главная страница хоть и генерируется динамически, но меняется достаточно редко, можно сильно снизить нагрузку на сервер, закэшировав ее в nginx. При высокой посещаемости даже кэширование на короткий срок (5 минут и меньше) уже дает огромный прирост в производительности, ведь кэш работает очень быстро. Даже закэшировав страницу всего на 30 секунд, вы все равно добьетесь значительной разгрузки сервера, сохранив при этом динамичность обновления данных (во многих случаях обновления раз в 30 секунд вполне достаточно).

Проблема

Ставил тут Flowplayer на сайт Агуши и столкнулся с непонятным поведением IE относительно этого плеера. Первый раз открываю страницу — всё ок (видео подгружается и играется), а если сделать refresh (f5) — то на сером фоне крутится кружочек загрузки и ничего не происходит.

Поиски

Долго гуглил по этой теме, нагуглил лишь только открытую тему на форуме самого плеера. Стал копаться сам.

На хабре недавно была опубликована статья под названием "Кэширование на Drupal". Хотелось бы добавить несколько соображений по теме.

Ни для кого не секрет, что Drupal голоден до ресурсов, а кэширование это чуть ли не первое что приходит в голову. Расскажу как выстроена общая схема кэширования на нашем сайте.

Первая линия обороны — мы используем CDN (Content Delivery Network), в нашем случае это AKAMAI. AKAMAI настроен на кэширование всего. Картинки, CSS, JavaScript, ответы на все GET запросы, все это кешируется в не зависимости от того аноним пользователь или зарегистрирован. Интервал кэширования от 1 до 5 минут для страниц, 45 минут для CSS и JavaScript, и час для остальных ресурсов. Такое распределение позволяет существенно уменьшить нагрузку на сервера.

Иногда попадаются такие ситуации, в которых нет никакой возможности ускорить работу некоторой операции. Она может зависеть от какого-то сервиса, который располагается на внешнем web сервере, или это может быть операция, которая дает высокую нагрузку на процессор. Или же это могут быть быстрые операции, однако, их параллельная работа может высосать из вашего компьютера все ресурсы производительности. Существует огромное количество причин чтобы использовать кэширование. Следует отметить, что PostSharp, изначально не предоставляет решений для вас какого-либо фреймворка кэширования, просто он позволяет сделать эту задачу на порядки быстрее, без каких-либо занудных действий, типа расстановки кода, отвечающего за кэширование по всему исходному тексту программы. Он позволяет решить эту задачу элегантно, вынося задачи в классы и позволяя их повторно использовать.

Предлагаю от лица подготовленного пользователя познакомиться с возможностями нового чипсета от ребят из Санта-Клары на примере флагманской материнской платы MSI Z68A-GD80 (B3). Разумеется, заранее я знаю, с чем мне придется столкнуться: возможность разгона процессора и встроенной графики, технология Intel RST SSD Caching (Rapid Storage Technology) и, конечно же, уникальная в своем роде инициатива LucidLogix Virtu.

Понадобилось недавно установить memcached и memcacheq на CentOs 6.2 и к сожалению было обнаружено, что готовых в репозитории нет, и надо компилировать самостоятельно. Причем, по сборке второго — нормальной и актуальной инструкции нету ни на русском, ни на английском. Последняя которая есть на всех сайтах достаточно древна и не совсем актуальна. Поиск гуглом находит только какие-то убогие китайские сайты. Вот и хочу восполнить этот пробел в русском сегменте сети.

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

Я все ждал, ждал, ждал, когда же все-таки умные ребята, разрабатывающие System.Web.Optimization добавят поддержку автоматической загрузки содержимого бандла в контейнер Azure Storage. На днях вышла «1.0.0-beta2», но желаемого функционала так я и не нашел, а быстроты то хочется…

Гем под названием "cache_digests" (включен по умолчанию в Rails 4) автоматически добавляет цифровую подпись к каждому фрагментному кэшу, основываюсь на представлении (вьюхе). При этом, если страница изменяется, то старый кэш автоматически удаляется. Но остерегайтесь подводных камней!

Intro

PHP + Java. Картинка взята отсюда

В этом комментарии к статье под названием «Пишите код каждый день» я сказал, что скоро покажу свой проект, на который я выделял ежедневно 1 час (кроме выходных). Так как в последнее время моя работа связана с написанием распределенных Java приложений, которые используют in-memory data grid (IMDG) в качестве хранилища данных, то мой проект связан именно с этим.

Подробнее про IMDG можно почитать в моих предыдущих статьях (1, 2). Но если кратко, то это кластерное распределенное хранилище объектов по ключам, которое держит все данные в памяти, за счет чего достигается высокая скорость доступа к данным. Позволяет не только хранить, но и обрабатывать данные, не извлекая их из кластера.
И если интерфейс для обработки данных у каждого конкретного IMDG свой, то интерфейс доступа к данным обычно идентичен хеш-таблице.

О чем эта статья

Большинство IMDG написано на Java и поддерживают API для Java, C++, C#, при этом API для веб языков программирования (Python, Ruby, PHP) не поддерживается, а протокол для написания клиентов сильно ограничен. Именно этот факт я и считаю основным тормозом для проникновения IMDG в массы — отсутствие поддержки самых массовых языков.

Так как производители IMDG пока не предоставляют поддержку веб языков, то веб программисты не имеют возможностей по такому же легкому масштабированию приложений, какие есть у серверных Java разработчиков. Поэтому я решил сделать нечто подобное самостоятельно и выложить в open source, взяв в качестве движка open source IMDG JBoss Infinispan (компания JBoss, принадлежащая Red Hat, довольно хорошо известна в кругу java разработчиков). Мой проект называется Sproot Grid, пока доступен только для PHP, но если у сообщества будет интерес, то сделаю и интеграцию с Ruby и Python.

В этой статье я еще раз расскажу про in-memory data grid и про то, как конфигурировать, запускать и использовать Sproot Grid.

В последнее время на Хабре появилось довольно много постов по данной теме, но по своей сути их можно назвать: «Смотрите, я поставил Varnish / W3 Total Cache и держу миллион запросов на «Hello world» страничке». Данная же статья рассчитана больше на гиков, желающих познать, как же это все работает и написать собственный плагин для страничного кеширования.

Зачем?

Стандартный вопрос, который возникает у каждого разработчика перед созданием велосипеда уже существующего функционала. Действительно, готовых плагинов уйма и многие из них довольно качественные, но нужно понимать что в первую очередь они рассчитаны на статические блоги. Что же делать, если у вас не стандартный WordPress сайт?

Вот уже вышло две статьи в потенциально очень длинной серии обзоров распределённой платформы Apache Ignite (первая про настройку и запуск, вторая про построение топологии). Данная статья посвящена попытке подружить Apache Ignite и Spring Boot. Стандартным способом подключения некой библиотеки к Spring Boot является создание для этой технологии «стартера». Несмотря на то, что Spring Boot весьма популярен и на Хабре описывался не единожды, про то, как делать стартеры, вроде бы ещё не писали. Этот досадный пробел я постараюсь закрыть.

Статья посвящена преимущественно Spring Boot'у и Spring Core, так что те, кого тема Apache Ignite не интересует, всё равно могут узнать что-то новое. Код выложен на GitHub, стартера и демо-приложения.

После того, как в предыдущих статьях данной серии обзоров распределённого Java-фреймворка Apache Ignite мы сделали первые шаги, познакомились с основными принципами построения топологии и даже сделали стартер для Spring Boot, неизбежно встаёт вопрос о кэшировании, которое является одной из основных функций Ignite. Прежде всего, хотелось бы понять, нужно ли оно, когда библиотек для кэширования на Java и так полным-полно. Тем, что предоставляется реализация стандарта JCache (JSR 107) и возможность распределённого кэширования в наше время удивить сложно. Поэтому прежде чем (или вместо того чтобы) рассматривать функциональные возможности кэша Apache Ignite, мне бы хотелось посмотреть, насколько он быстр.

Для исследования применялся бенчмарк cache2k-benchmark, разработанный с целью доказательства того, что у библиотеки cache2k кэш самый быстрый. Вот заодно и проверим. Настоящая статья не преследует цель всеобъемлющего тестирования производительности, или хотя бы научно достоверного, пусть этим занимаются разработчики Apache Ignite. Мы просто посмотрим на порядок величин, основные особенности и взаимное расположение в рейтинге, в котором будут ещё cache2k и нативный кэш на ConcurrentHashMap.

В этой статье говорится о том, как настроить обратный прокси-сервер NGINX или NGINX Plus в качестве балансировщика нагрузки для хранилища объектов (object storage) на базе Minio.

Если вы покупали молоко в магазине, вы сможете понять, как работает кэширование на стороне сервера и на стороне браузера.

Если вы — активный пользователь Интернета (а это, скорее всего, именно так), вы постоянно используете кэширование, но можете и не знать «закулисье»: когда и как оно работает.

С точки зрения разработчика, кэширование упрощает создание высокопроизводительных веб-приложений и веб-серверов: не нужно постоянно оптимизировать перегруженные тысячами запросов серверы — вы просто внедряете протоколы кэширования, и жить становится намного проще.

При кэшировании время загрузки страницы снижается с 2 секунд до 1 секунды… что не очень впечатляет, верно? Но без него не обойтись, когда приходится обрабатывать запросы от большого числа пользователей.

Использовав кэширование в одном из своих веб-приложений, я понял, что просто пройтись по терминам — не лучший способ объяснить этот подход. Мне пришло в голову, что хорошей аналогией будет путь молока от фермы до холодильника.

Чтобы понять мое объяснение, нужно немного знать об основах работы веб-серверов. Приступим!

Переведено в Alconost

^{Предлагаю вашему вниманию перевод оригинальной статьи от Mike Nakhimovich}

Давным-давно я работал в «Нью-Йорк Таймс» и создал библиотеку под названием Store, которая была «библиотекой Java для легкой, реактивной загрузки данных». Мы создали Store, используя RxJava и шаблоны, взятые из реализации Guava’s Cache. Сегодняшние пользователи приложений ожидают, что обновления данных будут происходить в UI без необходимости делать такие вещи, как pull-to-refresh, чтобы обновить данные или переходить между экранами туда-сюда. Реактивный фронтенд заставил меня задуматься о том, как мы можем иметь декларативные хранилища данных с простыми API, которые абстрагируют сложные функции, такие как многозадачный троттлинг и дисковое кэширование, которые необходимы в современных мобильных приложениях. За три года работы у Store 45 контрибьютеров и более 3500 звёзд на GitHub. Отныне я рад объявить, что Dropbox возьмет на себя активное развитие Store и выпустит его полностью на Kotlin с поддержкой Coroutines и Flow. И теперь Store 4 — это возможность воспользоваться тем, что мы узнали, переосмысливая API и текущие потребности экосистемы Android.

---