Меню
Что нового?

Что быстрее Memcache или file_get_contents()

MiksIr

miksir@home:~$
Что бы хранить большой объем структурированных данных.
 

Ярослав

Новичок
Я был неправ! ((
Почему то был всегда уверен, что функция var_export отрабатывает быстрее serialize.
Тесты показывают что наоборот.
Или может это было в предыдущих версиях?

Вот тесты:
PHP: 
TYPE       | ACTIVITY | TIME
-------------------------------------------------
serialize  |    WRITE | 0.03691
var_export |    WRITE | 0.04685
serialize  |      GET | 0.04023
var_export |      GET | 0.08005
Код теста:
PHP: 
<?php

for ($i = 0; $i < 100000; $i++) {
   $o[$i] = md5($i);
}

printf("%-10s | %8s | %s\n", 'TYPE', 'ACTIVITY', 'TIME');
printf("-------------------------------------------------\n");
$t = microtime(true);
file_put_contents(__DIR__ . '/cache/serialize.cache', serialize($o));
printf("%-10s | %8s | %.5f\n", 'serialize', 'WRITE', microtime(true) - $t);

$t = microtime(true);
file_put_contents(__DIR__ . '/cache/var_export.cache', '<?php return ' . var_export($o, true) . ';');
printf("%-10s | %8s | %.5f\n", 'var_export', 'WRITE', microtime(true) - $t);


$t = microtime(true);
$a = unserialize(file_get_contents(__DIR__ . '/cache/serialize.cache'));
printf("%-10s | %8s | %.5f\n", 'serialize', 'GET', microtime(true) - $t);

$t = microtime(true);
$a = include __DIR__ . '/cache/var_export.cache';
printf("%-10s | %8s | %.5f\n", 'var_export', 'GET', microtime(true) - $t);
 

MiksIr

miksir@home:~$
Похоже на правду. Все же синтаксический разбор должен быть медленнее, чем более заточенная под конкретную задачу функция. Но считать лучше в цикле, все же - время доступа к файлу может играть роль при таких малых цифрах.
 
Фанат

Фанат

oncle terrible
Команда форума
Чего-чего? При чем здесь скорость var_export?
Если массив требуется не только читать, но ещё и писать, то весь топик строем едет нафиг с пляжа без панамки. За профнепригодность.
 
Фанат

Фанат

oncle terrible
Команда форума
MiksIr написал(а):
восстановление осуществляет синтаксический парсер PHP (1)
засирание кешера опкода(2)
Нажмите для раскрытия...
Вы, Соломон Рюрикович, или крестик снимите, или трусики наденьте.
Или у тебя кэшер "засирается", или синтаксический анализатор работает. Что-нибудь одно.
 

MiksIr

miksir@home:~$
> Или у тебя кэшер "засирается", или синтаксический анализатор работает. Что-нибудь одно.
Именно так. Но скорее всего все же первое, если это не конфиг какой-то, а реально данные. Ну и потом актуально только для файлов, для иных источников хранения с eval-ом кода вообще не актуально.
 
fixxxer

fixxxer

К.О.
Партнер клуба
UPD:
___________________________________________________________________

DISCLAIMER:
ниже мы тут меряемся сферическими конями, серьезно не относиться!
___________________________________________________________________

1. var_export конечно не быстрее. быстрее - include (а если в кэш надо чаще писать, чем из него читать, то кэш очевидно не нужен)
2. и только если установлен опкод кэшер
 
Фанат

Фанат

oncle terrible
Команда форума
Balancer написал(а):
Вот ещё немного информации для размышления:
— Производительность кодирования и декодирования serialize и json — часть вторая
— Сериализация в php: serialize, json, bson
Нажмите для раскрытия...
Еще раз повторяю - это все полная ерунда
Если данных у вас столько, что начинает заботить разница в скорости их распаковки - надо в консерватории что-то менять
 
fixxxer

fixxxer

К.О.
Партнер клуба
Плюс к тому, там вообще дурные тесты - сравнивается последовательность сериализации и десериализации. Такие тесты имеют смысл для внутренних API, когда данные просто гоняются туда-сюда - но никак не применительно к кэшированию.

Не читайте до обеда хабр :)
 

MiksIr

miksir@home:~$
Нормально все сравнивается . И использовать опкод кешер для кеширования бред - плохоуправлямый кеш хуже его отсуствия, ибо может подкинуть проблем когда их не ждут. Например, много горячего контента, из-за чего из кеша начнут сами скрипты вылетать.
Хотя для начала нужно спросить - хранение сериализованного масиива человеку нужно для кеширования данных или для их хранения.
 
fixxxer

fixxxer

К.О.
Партнер клуба
использовать опкод кешер для кеширования бред
Нажмите для раскрытия...
Да ну, вот прямо всегда и во всех случаях бред?

Например, много горячего контента, из-за чего из кеша начнут сами скрипты вылетать
Нажмите для раскрытия...
Размер кэша настраивается.

Разумеется, не во всех случаях следует использовать опкод кэшер. Всегда приходится выбирать между расходом памяти и cpu.
 
Vladson

Vladson

Сильнобухер
По поводу
Собираюсь сохранить большой сериализованный массив.
Потом достать его.

Куда лучше сохранить: в файл и получить при помощи file_get_contents()
или в Memcache ?
Нажмите для раскрытия...
Ноль разницы, куда важнее смотреть на то зачем это делается, и в зависимости от этого, смотреть что логичнее (иногда лучше использовать более медленное решение, но которое позволит открыть простор для оптимизации быстродействия там где оно действительно необходимо)

А по поводу замечания серилизовать массив или нет, сказать не могу (не дочитал весь топик) но думаю что в совершенно любом случае надо смотреть на конкретный случай... Если в 60-ых годах в процессорах не было FPU и таблицы Брадиса загружались с дискет/лент/перфокарт в оперативку, то сейчас такое решение никому и в голову не придёт, хотя вовсе не значит что это решение единственно правильное или единственное неправильное.
 
fixxxer

fixxxer

К.О.
Партнер клуба
Надо понимать, что memcached как таковой нужен прежде всего для организации общего кэша для нескольких серверов.
И он уж никак не может быть быстрее работы с локальной памятью (а часто используемые файлы будут в кэше файловой системы ОС).
Смысл memcached не в "скорости", а в обеспечении эффективности кэша, если сервер не один.
 

MiksIr

miksir@home:~$
> Да ну, вот прямо всегда и во всех случаях бред?
>Размер кэша настраивается.
В большинстве случаев. За все говорить не буду. Размер кеша настраивается до определенных пределов. Дальше начинается вакханалия.

Кстати, а как бы потестить с опкод кешером? Пока у меня получается require в 3 раза медленнее, чем unserialize. Правда массив синтетический и большой.
А как вот с кешером... попробовал apc с включенным enable_cli - нет разницы.
Просто есть у меня подозрение, что опкод кешер не сильно спасет ситуацию. Я посмотрел опкод такого инклуда - ну там огромное число ADD_ARRAY_ELEMENT инструкций. По сути их же создает ансериализатор, только тратится еще на разбор строки, но строка эта удобна для машинного разбора, что не скажешь о результате var_export, где используется php-шный парсер, полагаю, с кучами оверхедов. Так что очень подозреваю, что результат работы будет если и быстрее unserialize, то не сильно.
 

MiksIr

miksir@home:~$
PS: а, все max_file_size нужно было. В общем без apc: 170 сек require, 70 сек unserialize; c apc 42 сек require, 56 сек unserialize (внезапно он стал тоже быстрее).

И заключающим аккордом идет igbinary_unserialize - (apc включен) - 49 секунд.

В общем, даже с apc не так уж и впечатляет require. Время - 100 десериализаций огромного массива (~200Мб в памяти пхп)
Испоьзование диска: чистый var_export - 60мб, с удаленными пробелами и переводами строк 23мб, serialize - 31мб, бинарный - 14мб.
 
fixxxer

fixxxer

К.О.
Партнер клуба
~200Мб в памяти пхп
Нажмите для раскрытия...
Ну это же совсем жесть! =)

Такие огромные хреновины надо вообще как-то иначе разруливать. Бить на части, например.

Но таки мои эмпирические соображения о том, что include с кэшером будут быстрее, подтвердились, хотя я ждал большего отрыва от unserialize =)

Вообще, я не то чтобы одобряю такой подход для кэширования данных. А вот для генерации [pre|post]-deploy кэша - самое то (и с инвалидацией в этом случае проблемы отсутствуют по определению).

Попробуй на пачке мелких файликов - там должен быть существенно бОльший прирост за счет использования RAM cache (shm/mmap/что там настроишь).
 

MiksIr

miksir@home:~$
У меня был рам кеш, полагаю - я апц 512М памяти дал, так что должен был запихнуть в память.
Большой файл исключительно для теста, что бы избежать измерения других оверхедов типа статов по файлам и т.п.
На очень маленьких файлах отрыв больше - 10 сек require против 14 сек unserialize, но это 1 мил итераций по мелкому файлу.
Так что выигрыш в скорости меня не убедил, а профиты serialize интереснее - хранение где хочешь, тогда как require привязано к общему оп-кешу и файлам.

Кстати, unserialize(file_get_contents) оказался чуточку быстрее чем unserialize(apc_fetch) на больших файлах.
А вот с мелкими (1 мил итераций) все стало на свои места
10сек - require, 14сек - unserialize(file_get_contents), и 7сек - unserialize(apc_fetch)
apc.stat=0 стоит, но php все-равно делает статы.
 
Войдите или зарегистрируйтесь для ответа.
Сверху