В порыве пятничного отлынивания от работы, совместно с коллегой, родили нечто.

Нечто позволяет одним запросом обновлять неограниченное количество записей. Причем разные столбцы, на разные данные, в зависимости от уникального ключа.

Нечто имеет следующие недостатки:

• требует уникального ключа
• если строки с подходящим ключом нет, то она добавится
• для построения требует знаний о типах полей таблицы
• мускл на него ругается ворнингами
• NULL таким образом вставить невозможно

SQL:

CREATE TABLE  `bulk_update` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `int` int(11) NOT NULL DEFAULT '7',
  `str` varchar(5) NOT NULL DEFAULT 'def',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

INSERT INTO `bulk_update` (`id`, `int`, `str`)
  VALUES (1, 1, 'a'), (2, 2, 'b'), (3, 3, 'c');

INSERT INTO `bulk_update` (`id`, `int`, `str`)
  VALUES (1, 22, null), (2, null, 'bb')
  ON DUPLICATE KEY UPDATE
    `int` = IFNULL(NULLIF(VALUES(`int`), 0), `int`),
    `str` = IFNULL(NULLIF(VALUES(`str`), ''), `str`);

SELECT * FROM bulk_update;
+----+-----+-----+
| id |   int | str |
+----+-----+-----+
|  1 |   22 | a   |
|  2 |   2  | bb  |
|  3 |   3  | c   |
+----+-----+-----+

Тесты скорости показали следующие результаты:

Во время теста параллельно пускались три скрипта, делающие разнообразные селекты к таблице.

Тест, как всегда, прилагается.

В общем штука получилась интересная, но какая-то костылеподобная.

UPD: Теперь работает и для столбцов с NOT NULL и без оного.

В mysql есть тип данных set, который вполне для этого подходит. Но можно и ручками

Посмотрим взлетит оно или нет:

CREATE TABLE  `tests`.`article` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `mask` int(10) unsigned default NULL,
  `cset` set('1','2','3','4','5','6','7','8','9','10','11','12','13','14','15','16','17','18','19','20') default NULL,
  PRIMARY KEY  (`id`),
  KEY `mask` (`mask`),
  KEY `cset` (`cset`)
) ENGINE=InnoDB;

Добавление записей:

INSERT INTO article VALUES(NULL, 3, '1,2');

Выбор по одному тэгу:

select count(*) from article where mask & 1; //помеченные тэгом #1
select count(*) from article where cset & 1;

Выбор по нескольким тэгам – объединение:

select count(*) from article where mask & 3; //помеченные тэгом #1 ИЛИ #2
select count(*) from article where cset & 3;

Выбор по нескольким тэгам – пересечение:

select count(*) from article where mask & 1 AND mask & 2; //помеченные и  тэгом #1 И тэгом #2
select count(*) from article where cset & 1 AND cset & 2;

По скорости варианты равноценны, и на табличке с 500К записей (20 разных тэгов, по 1-20 тэгов на статью) все запросы обрабатывались за, примерно, 0.3 секунды, на средненькой домашней машинке.

Странное заключалось в поиске запросов от парсеров в логе nginx’а, и в поиске “дорогих” страниц.
Оказалось все просто:

• sed – потоковый редактор текста. Т.е. ты ему поток текста, а он его преобразует по данным тобою правилам.
• grep- потоковый фильтр. Ты ему критерий, он тебе данные, отфильтрованные по этому критерию.
• awk – скриптовый язык для обработки потоков. Мощная штука. Очень мощная штука.

А теперь хором

Задача номер один – поиск парсеров. Парсеры отличаются тем, что делают много запросов с одного IP. Понеслась…

Файл group_by_ips.sh:

awk '
{
  requests_count_from_ips[$1]++
}
END
{
  for (ip in requests_count_from_ips)
  {
    print requests_count_from_ips[ip] ": " ip;
  }
}' | \
sort -nr

Создаем массив, в котором в качестве ключей используем IP, а в качестве значений – количество запросов с него. Т.к. IP в access логе у нас стоит первым, то соответственно его значение попадет в скрипт, как $1. По окончанию обработки потока бежим по массиву и выводим первым – количество запросов, а потом IP. Ну и сортируем вывод sort’ом.

#cat ./access.log | ./group_by_ips.sh | head
81015: 66.249.72.83
11740: 69.80.244.163
6527: 82.193.155.236
2456: 88.212.197.90
1833: 195.131.145.226
1770: 67.202.41.3
1584: 195.208.157.26
1544: 89.239.140.106
1235: 89.252.9.34
1208: 72.26.227.114

Мы для кого работаем?

Задача #2 состоит в определении “стоимости” различных url. Стоимостью мы будем считать время работы backend’а. Для того, чтобы он попал в access лог будем использовать переменную “upstream_response_time”. Формат моих логов:

log_format fastcgi_log '$remote_addr $request $status $body_bytes_sent'
' $http_referer $upstream_response_time $request_time $time_local $host [$http_user_agent]';

Файл calc_weights_by_urls.sh:

awk '{
  gsub(/[0-9]+/, "X", $3);
  urls[$2" "$3] += $8;
}
END
{
  for(i in urls)
  {
    print urls[i]":"i;
  }
}' | \
sort -nr

#cat ./access.log | ./calc_weight_by_urls.sh | head
88160.2:GET /users/X/
85643.6:GET /photos/X/
84629.4:GET /photos/category/X/?pager=X
45453.2:GET /photos/X/?from_member
25910:GET /users/X/?pager=X
9275.3:GET /photos/category/X/
8299.5:GET /
8298.21:GET /users/X/photos/?category=X
4309.97:GET /my/favorite_authors_photos/
4304.44:GET /new_on_site/photos/?pager=X

Коль пошла такая пьянка

Раз уж у нас есть данные по стоимости каждого запроса, то можно улучшить решение первой задачи, и считать стоимость IP не по количеству запросов, а как сумму стоимостей запросов с этого IP.
Файл calc_weights_by_ips.sh:

awk '
{
  ips[$1] += $8;
}
END
{
  for(i in ips)
  {
    print ips[i]":"i;
  }
}' | \
sort -nr

cat ./access.log | ./calc_weight_by_ips.sh | head
42533.1:66.249.72.83
12886.8:69.80.244.163
5272.19:82.193.155.236
3892.73:93.189.148.97
1678.77:88.212.197.90
1424.76:67.202.41.3
1327.53:82.207.122.195
1318.4:81.19.66.89
1199.44:67.195.45.213
1114.04:80.72.18.82

В итоге три первых IP сохранились, а дальше уже картина немного другая.

Немного о скорости

Несмотря на то, что я, мягко говоря, не айс в этих утилитах, и скорее всего написал все криво и неоптимально, но скорость все равно радует:

• размер анализируемого лога – 160Mb (650К строк)
• время работы подсчета стоимости по IP – 2 секунды
• время работы подсчета стоимости по урлам – 4 секунды

И пусть весь мир подождёт

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

Честные блокировки на генерацию

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

Лок файловой системы

есть косяки, но иногда работает . Подробности в описании функции flock().

Мьютекс в хранилище

Если мы используем memcache и генерируемый кэш имеет ключ «popular_articles», тогда наличие данных с ключем «popular_articles_lock», говорит о том, что наш кэш уже кто-то генерирует. Тоже самое справедливо и для других хранилищ.

IPC семафоры

Настоящие пацанские семафоры Ни разу не использовал — руки не доходят.

Плюсы локов в том, что клиент сам решает, что делать в ситуации, когда ему нужны данные, а их кто-то генерирует. Например, если есть старые данные, то мы можем их отдать, а если данных нет, то либо подождать, либо честно вывести пользователю, что данных нет. На самом деле висящие в течении секунды пользователи совсем не есть гуд, но иногда можно допустить и такое. Так же не стоит забывать, что при генерации может возникнуть ошибка, и в этом случае лок может остаться висеть(в случае memcache можно ставить ttl на лок).

Организация «окна» для генерации

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

Я хочу вас всех, я хочу вас сразу!

Случай у нас тяжёлый, и пользователю будет скучно коротать 20 секунд рисуя матом надписи на пыльном столе. Я знаю про кого будут эти надписи. Главное откровение: чтобы избавиться от последствий многопоточности надо свести ее к одному потоку. Просто и со вкусом. Убираем всю генерацию кэша в оффлайн. ttl-ем в данном случае будет время перезапуска генерирующих кэш скриптов. Помимо быстрого ответа пользователю тут есть еще один плюс — наборы кэшей часто генерировать быстрее, чем каждый из них по отдельности, ибо можно хранить какие-то промежуточные данные. UPD: Вот ещё статья по теме.

Зачем?

Хочется убить двух зайцев: избавиться от запросов за редко изменяемыми данными, и их отрисовки. Вообще это смахивает на попытку минимальным количеством движений сделать глобальное счастье. Можно потом перед другими фрэймворками меряться, ага.

На самом деле задача избавиться от отрисовки куска страницы вообще какая-то странная, если мы используем быстрый шаблонизатор. Application-сервера, при нормальной арихитектуре, масштабируются легко и непринужденно, а APC, сам закэширует скомпилированный шаблон, если он компилируется в РНР-код, как это сделано в Smarty, Macro и многих других.

С другой стороны, если есть простой способ закэшировать, то почему бы и нет.

Откуда данные, и как заставить протухнуть кэш.

Данные в шаблоне могут получаться двумя способами. Первый и традиционный это push-подход, когда контроллер заполняет какой-то data-transfer-object, или в сам шаблон. Такой подход используется чаще всего, ибо это “тру MVC”!

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

Теперь об определении развалидации кэша. Тут тоже два основных подхода. Первый – ttl(time-to-live – время жизни). Мы определяем, что список новостей, например, валиден в течении 15 минут. Основной плюс – мы уверены, что за данными скрипт будет обращаться не чаще чем раз в 15 минут, и зная частоту обращений можем точно расчитать эффективность такого кеша. Второй плюс – простота реализации. Главный же минус в том, что наш список на самом деле может измениться через секунду после построения кэша, а пользователь увидит изменения только через 15 минут.

Второй вариант сброса кэша – по действию. Например, тот контроллер(экшн), который отвечает за публикацию новостей, сам убивает кеш, и формирует новый (тут тоже много разных камней, типа lost updates, и прочих порождений многопоточности, но все они решаемы). Плюс – кэш всегда валиден. Первый минус это сложность реализации (нам нужно добавлять код для работы с кэшем во все места, где идет работа с данными кэша – публикация новостей, их удаление, и т.д.). Второй минус в том, что эффективность такого кэша сильно зависит от частоты изменения данных.

А теперь тоже самое, но в свете кэширования частей страницы.

Push me. And then just touch me…

Кэшировать части страницы, при push-данных хуже, чем кэшировать эти самые данные. Почему? Потому что мы “загадим” кодом работы с кэшем и шаблон, и контроллер, а из плюсов только экономия на отрисовке.

Pull-данные и развалидация по действию

Что мы получаем? Логика работы с кешем в шаблоне и тех контроллерах, которые отвечают за действия. Опять не тру, и лучше опять кэшировать данные, через какой-нибудь LastNewsService.

Pull-данные и ttl

Вот то ради чего собственно и делаются теги cache, блоки django, компоненты и т.д. Вся логика только в шаблоне (или настройках компонента). Красотища!

Вывод:

Кэширование части HTML имеет смысл только для pull данных с устареванием по времени. Во всех остальных случаях его плюсы, по сравнению с кэшированием данных, сводятся к экономии работы шаблонизатора.

Ну вот опять!

Передо мной в данный момент стоит задача сравнить популярные бытрые хранилища данных, основанные на использовании оперативной памяти. Найденные сравнения(например, вот это) не совсем подходят, так как необходима информация не только о скорости get/set операций, но и о add/delete (их предполагается использовать для создания мьютексов).

На самом деле целей тестирования две:

1. Найти самый быстрый и удобный cache storage, с которым можно взаимодействовать из PHP-шного расширения напрямую, а не через сокеты, как у memcached.
2. Оценить разницу в скорости, между хранилищем из пункта 1 и memcached.

Итак в тестировании участвуют:

• APC [3.0.16]
• Memcached [1.2.1]
• XCache [1.2.1]

Идут лесом:

• MySQL memory (heap) storageSQLite database in memoryMySQL memory (heap) storageMySQL memory (heap) storage и MySQL memory (heap) storage

• shmop

• eAccelerator. За то, что не умеет работать в cli-режиме.

Тестирование проводилось с помощью немного измененного пакета limb/cache. Этот пакет позволит (я надеюсь в случае нехватки памяти на application-сервере, легко и непринуждённо (всего одна бессоная ночь) перейти на memcached.

Кто на свете всех быстрее, и румяней, и милее.

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

Загадочные цифры – это количество совершаемых операций в секунду.

* – В ходе тестирования выяснилось, что XCache не умеет работать с объектами, и их ему приходится отдавать в уже сериализованном виде. Это, конечно решается с помощью собственного драйвера, но “осадок остался” (с).

APC рулит! Поэтому и войдет в PHP6

Выходи memcached – биться будем!

Выводы делаейте сами, а я спать пойду.

Исходники тестов можно скачать и поправить

То о чем так долго говорили большевики…

Кратенько:

• пространства имен
• mysqlnd
• позднее статическое связывание
• динамические вызовы статических методов
• Прочие изменения

А теперь подробно…

Пространства имен

/* Серое и унылое настоящее */
class MyAclSimpleRole {}
$a = new MyAclSimpleRole;

/* или (Zend FW) */
class My_Acl_Simple_Role {}
$a = new My_Acl_Simple_Role;

/* А теперь так */
namespace My::Acl::Simple;
class Role {}

/* По прежнему можем использовать полное имя */
$a = new My::Acl::Simple::Role;

/* А если use добавить... */
use My;
$a = new Acl::Simple::Role;

use My::Acl;
$a = new Simple::Role;

use My::Acl::Simple;
$a = new Role;

/* А если alias добавить, то вообще красота */
use My::Acl::Simple as defaultAcl;
$a = new defaultAcl::Role;

use My as default;
$a = new default::Acl::Role;

class Foo {
  public static function whoIsItDrinkins() {
      return __CLASS__;
  }
}

class Bar extends Foo {}

echo Bar::whoIsItDrinkins(); //Foo

class Foo {
  public static function whoIsItDrinkins() {
      return get_called_class();
  }
}

class Bar extends Foo {}

echo Bar::whoIsItDrinkins(); //та-да!

class FooFactory {
  static function call() {
    echo 'Простите все операторы сейчас заняты';
  }
  static function __callStatic( $methodname, $args ) {
    echo '

Добрый день! Вы только вызвали статический метод ' . $methodname . '

';
    echo '

С параметрами:

';
    echo '

' . print_r( $args, true ) . '

$posted_articles = Articles::findByIsPosted(true);

$new_members = Member::findByRegistrationDateLessWhat($today);

$method = 'callAnotherTime';
FooFactory :: $method('Я вас каждый день вызывать буду!');