У нас специфика такая, что сегодня он принёс 1 000 прибыли, через месяц 1 000 прибыли, через два месяца… Ну вы поняли.
По метрике и гугланалитику они не просто так сидят, эти шестые. Доход есть и высок.
Статистика нашего топового магазина по посещаемости:
1.FF3.6
2.IE7
3.IE8
4.IE6
5. оперы, сафари и экзотическая живность
Как видно, первое место приятно, второе терпимо, третье заманчиво, четвёртое… Да. Пришлось изучить много матных слов, но мы его победили. Также как и оперу под мак и FF под линукс. Просто потому что если сайт приносит деньги он должен быть везде одинаков и с единым функционалом. И если ваш сайт посещают пользователи ie6 игнорировать их глупо.
Спасибо за разьяснение. Не подумал бы что параметры функции не учавствуют в названии переменной, помещенной в кэш. Хм. А если не секрет, чем это яснее? Искренне думал, что PAR_ что-то вроде контекстов и просто помогают уточнить какие-то странные штуки вроде global b=(2 || 3) и в зависимости от 2-х или 3-х разные данные запишутся/прочитаются из кеша.
utf8 всего-лишь кодировка. И когда вы строите приложение опираясь на паттерн проектирования MVC вы его выбираете не потому что это модно, а потому что это оправдано.
Можно конечно вспомнить рекомендации консоциума WC3 и то, что к php6 utf8 станет стандартом для большинства строковых функций. Но не о том было :)
В моих проектах применение юникода оправдано. В проектах Malerok — нет. Не понимаю почему нужно было устраивать какое-то скрытие покровов и выискивание истин.
Это очень хороший вопрос. Значит отходим от идеи: есть теги(группы), чтобы как-то разграничивать кешированные данные. Также при кешировании можно добавить дополнительные параметры(PARAM_ID,PARAM_USER), чтобы при разном поведении внешнего мира(не дай глобалсы) не происходило клюков кеша. В противном случае мы просто напишем
CacheTag::SetFunction('f2',$arg1,$arg2,$arg3); ну и далее по группам и выводу.
Если я верно понял суть и назначение PARAM_ID и PARAM_USER, то думаю, что явное указание дополнительных параметров обязательно.
А как у вас с кешированием, высокими нагрузками(каталог- 40 тысяч наименований, 150 тысяч изображений, уникальных посетителей в день- 15 тысяч)? Используется ли шаблонизация? Сколько стоит полная версия, помогает ли техподдержка ориентироваться в коде?
Мы говорим о микросекундах и я не понимаю в чём вы пытаетесь меня убедить. Вы сами подтверждаете мои слова о разнице в скорсти: 'расходы в скорости работы встроенных mb* функций по сравнению с не-mb минимальны'. Если в том, что на это стоит закрыть глаза и рваться к юникоду, то я спрошу вас- зачем это человеку, у которого весь его функционал работает и с использованием cp1251? Если в том, что расходов нет, то мы кажется выяснили, что они есть. Если в том, что ими стоит пренебречь, то я не вижу спора- тут каждый выбирает сам. Меня лишь поразила твердолобость обсуждавших этот вопрос людей. Для примера:
Записи $a=«Привет, мир» и $a='Привет, мир' имеют разное время выполнения. Разница минимальна. Вы же не станете меня сейчас убеждать в том, что мне стоит использовать первый вариант, потому что с ним проще не ошибиться?
PS: Думаю, это позволит выиграть еще пару микросекунд в синтетике с rand(0,132) и достаточно много времени на реальных проектах. Потому как сравнить время и восстановить обьект из кеша совершенно несопоставимые по сложности и ресурсам операции.
В общем я бы предложил сделать так:
При добавлении нового элемента в кеш писать в массив с его тегом время истечения жизни обьекта. При удалении выкидывать его из массива.
Таким образом не потребуется никаких replace.
И вызовы будут не
Собственно более просто: При указании времени=0 берется переменная protected $timeout = 30;
В общем метод Set в MemcacheTag.php показывает следующее(при CacheTag::SetTimeout(1);):
this->memcache_obj->set(product, Array,0, 60 * 1);
this->memcache_obj->set(_resetTags, Array,0, 60 * 0);
И еще вопрос. Зачем у нас при каждом запросе чего-то из кеша происходит два запроса а потом еще и замена?
Т.е. как-то так:
this->memcache_obj->get(_resetTags);
this->memcache_obj->get(product);
а потом мы всё равно:
this->memcache_obj->replace(_resetTags, Array, 0, 0);
Не два. Там больше на самом деле.
1. Обработка регулярного выражения, в котором есть класс символов типа \w (буква). В однобайтовой кодировке это один-два такта + допускает параллельное вычисление, в utf-8 несколько десятков оперций сравнения.
2. Таблица преобразования в 1251 – это 256 байт, которые помещаются в кэш современного процессора, а таблица преобразования для utf-8 вообще не существует в виде одной таблицы, это куча таблиц и соотв. условных переходов.
Так что зря человека заминусовали. Он говорит дело и если для него так важны накладные расходы и он не испытывает проблем с AJAX, то всё верно. Для его кириллического сайта cp1251 оптимальна.
IE7- 30 000
IE8-27 000
IE6-13 000
Опер тоже много, но меньше 10 000 посещений в месяц.
По метрике и гугланалитику они не просто так сидят, эти шестые. Доход есть и высок.
1.FF3.6
2.IE7
3.IE8
4.IE6
5. оперы, сафари и экзотическая живность
Как видно, первое место приятно, второе терпимо, третье заманчиво, четвёртое… Да. Пришлось изучить много матных слов, но мы его победили. Также как и оперу под мак и FF под линукс. Просто потому что если сайт приносит деньги он должен быть везде одинаков и с единым функционалом. И если ваш сайт посещают пользователи ie6 игнорировать их глупо.
Мой бухгалтер ненавидит ie, но банк-клиент и миллионы специфичных приложений только в ie6 и работают. Зря вы так.
Можно конечно вспомнить рекомендации консоциума WC3 и то, что к php6 utf8 станет стандартом для большинства строковых функций. Но не о том было :)
В моих проектах применение юникода оправдано. В проектах Malerok — нет. Не понимаю почему нужно было устраивать какое-то скрытие покровов и выискивание истин.
CacheTag::SetFunction('f2',$arg1,$arg2,$arg3); ну и далее по группам и выводу.
Если я верно понял суть и назначение PARAM_ID и PARAM_USER, то думаю, что явное указание дополнительных параметров обязательно.
*при учёте, что у вас нормальный просмотрщик
Записи $a=«Привет, мир» и $a='Привет, мир' имеют разное время выполнения. Разница минимальна. Вы же не станете меня сейчас убеждать в том, что мне стоит использовать первый вариант, потому что с ним проще не ошибиться?
Getting _resetTags
__get
Getting product
__get
__replace
а
__construct
Getting _resetTags
__get
Getting product
__get
PS: Думаю, это позволит выиграть еще пару микросекунд в синтетике с rand(0,132) и достаточно много времени на реальных проектах. Потому как сравнить время и восстановить обьект из кеша совершенно несопоставимые по сложности и ресурсам операции.
В общем я бы предложил сделать так:
При добавлении нового элемента в кеш писать в массив с его тегом время истечения жизни обьекта. При удалении выкидывать его из массива.
Таким образом не потребуется никаких replace.
И вызовы будут не
В общем метод Set в MemcacheTag.php показывает следующее(при CacheTag::SetTimeout(1);):
this->memcache_obj->set(product, Array,0, 60 * 1);
this->memcache_obj->set(_resetTags, Array,0, 60 * 0);
И следующее(CacheTag::SetTimeout(0);):
this->memcache_obj->set(product, Array,0, 60 * 31);
this->memcache_obj->set(_resetTags, Array,0, 60 * 0);
И еще вопрос. Зачем у нас при каждом запросе чего-то из кеша происходит два запроса а потом еще и замена?
Т.е. как-то так:
this->memcache_obj->get(_resetTags);
this->memcache_obj->get(product);
а потом мы всё равно:
this->memcache_obj->replace(_resetTags, Array, 0, 0);
Баг репорт #2.
Пример:
По-идее лимит времени- 0, в конце стоит очистка кэша. Но я уже пятую минуту обновляю и вижу всё те же 546. Меняются только при перезагрузки memcache.
PS: Система та же, конфиг из свн, код класса и моста для memcache не тронуты.
1. Обработка регулярного выражения, в котором есть класс символов типа \w (буква). В однобайтовой кодировке это один-два такта + допускает параллельное вычисление, в utf-8 несколько десятков оперций сравнения.
2. Таблица преобразования в 1251 – это 256 байт, которые помещаются в кэш современного процессора, а таблица преобразования для utf-8 вообще не существует в виде одной таблицы, это куча таблиц и соотв. условных переходов.
Так что зря человека заминусовали. Он говорит дело и если для него так важны накладные расходы и он не испытывает проблем с AJAX, то всё верно. Для его кириллического сайта cp1251 оптимальна.