All streams
Search
Write a publication
Pull to refresh
32
0

Управление проектами в IT

Send message
FF 3.6- 36 000
IE7- 30 000
IE8-27 000
IE6-13 000

Опер тоже много, но меньше 10 000 посещений в месяц.
У нас специфика такая, что сегодня он принёс 1 000 прибыли, через месяц 1 000 прибыли, через два месяца… Ну вы поняли.
По метрике и гугланалитику они не просто так сидят, эти шестые. Доход есть и высок.
Статистика нашего топового магазина по посещаемости:
1.FF3.6
2.IE7
3.IE8
4.IE6
5. оперы, сафари и экзотическая живность

Как видно, первое место приятно, второе терпимо, третье заманчиво, четвёртое… Да. Пришлось изучить много матных слов, но мы его победили. Также как и оперу под мак и FF под линукс. Просто потому что если сайт приносит деньги он должен быть везде одинаков и с единым функционалом. И если ваш сайт посещают пользователи ie6 игнорировать их глупо.
//бухгалтеров, секретарей и прочих сотрудников, которые просто не компетентны

Мой бухгалтер ненавидит ie, но банк-клиент и миллионы специфичных приложений только в ie6 и работают. Зря вы так.
Спасибо за разьяснение. Не подумал бы что параметры функции не учавствуют в названии переменной, помещенной в кэш. Хм. А если не секрет, чем это яснее? Искренне думал, что PAR_ что-то вроде контекстов и просто помогают уточнить какие-то странные штуки вроде global b=(2 || 3) и в зависимости от 2-х или 3-х разные данные запишутся/прочитаются из кеша.
utf8 всего-лишь кодировка. И когда вы строите приложение опираясь на паттерн проектирования MVC вы его выбираете не потому что это модно, а потому что это оправдано.
Можно конечно вспомнить рекомендации консоциума WC3 и то, что к php6 utf8 станет стандартом для большинства строковых функций. Но не о том было :)

В моих проектах применение юникода оправдано. В проектах Malerok — нет. Не понимаю почему нужно было устраивать какое-то скрытие покровов и выискивание истин.
там не ssl, а картиночка :)
Наверное рабочие фабрик тоже сначала шутили, а потом пришли они- машины.
Это очень хороший вопрос. Значит отходим от идеи: есть теги(группы), чтобы как-то разграничивать кешированные данные. Также при кешировании можно добавить дополнительные параметры(PARAM_ID,PARAM_USER), чтобы при разном поведении внешнего мира(не дай глобалсы) не происходило клюков кеша. В противном случае мы просто напишем
CacheTag::SetFunction('f2',$arg1,$arg2,$arg3); ну и далее по группам и выводу.

Если я верно понял суть и назначение PARAM_ID и PARAM_USER, то думаю, что явное указание дополнительных параметров обязательно.
Какое предложение здесь является дезинформацией?
Вы не поверите, но изменив его на gif была бы та же самая картинка*

*при учёте, что у вас нормальный просмотрщик
Платные писатели и так есть. Сотрудники Тематических Медиа. И это всё еще Хабр ;)
А как у вас с кешированием, высокими нагрузками(каталог- 40 тысяч наименований, 150 тысяч изображений, уникальных посетителей в день- 15 тысяч)? Используется ли шаблонизация? Сколько стоит полная версия, помогает ли техподдержка ориентироваться в коде?
Мы говорим о микросекундах и я не понимаю в чём вы пытаетесь меня убедить. Вы сами подтверждаете мои слова о разнице в скорсти: 'расходы в скорости работы встроенных mb* функций по сравнению с не-mb минимальны'. Если в том, что на это стоит закрыть глаза и рваться к юникоду, то я спрошу вас- зачем это человеку, у которого весь его функционал работает и с использованием cp1251? Если в том, что расходов нет, то мы кажется выяснили, что они есть. Если в том, что ими стоит пренебречь, то я не вижу спора- тут каждый выбирает сам. Меня лишь поразила твердолобость обсуждавших этот вопрос людей. Для примера:
Записи $a=«Привет, мир» и $a='Привет, мир' имеют разное время выполнения. Разница минимальна. Вы же не станете меня сейчас убеждать в том, что мне стоит использовать первый вариант, потому что с ним проще не ошибиться?
__construct
Getting _resetTags
__get
Getting product
__get
__replace

а

__construct
Getting _resetTags
__get
Getting product
__get

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);

И следующее(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.
Пример:
error_reporting(E_ALL);
require_once("CacheTag.class.php");

function f()
{
  return rand(1,1000);
}

CacheTag::SetBackend(CacheTag::BACKEND_MEMCACHE);
CacheTag::SetFunction('f');
CacheTag::SetTags(CacheTag::TAG_PRODUCT);
//CacheTag::SetParam(CacheTag::PARAM_ID, 2);
CacheTag::SetTimeout(0);
$var=CacheTag::Fetch();
echo $var;
CacheTag::Flush();


* This source code was highlighted with Source Code Highlighter.


По-идее лимит времени- 0, в конце стоит очистка кэша. Но я уже пятую минуту обновляю и вижу всё те же 546. Меняются только при перезагрузки memcache.

PS: Система та же, конфиг из свн, код класса и моста для memcache не тронуты.
Видимо имеется в виду спагетти-код. Они когда варятся перемешиваются сильно.
Не два. Там больше на самом деле.
1. Обработка регулярного выражения, в котором есть класс символов типа \w (буква). В однобайтовой кодировке это один-два такта + допускает параллельное вычисление, в utf-8 несколько десятков оперций сравнения.
2. Таблица преобразования в 1251 – это 256 байт, которые помещаются в кэш современного процессора, а таблица преобразования для utf-8 вообще не существует в виде одной таблицы, это куча таблиц и соотв. условных переходов.

Так что зря человека заминусовали. Он говорит дело и если для него так важны накладные расходы и он не испытывает проблем с AJAX, то всё верно. Для его кириллического сайта cp1251 оптимальна.

Information

Rating
Does not participate
Location
Санкт-Петербург и область, Россия
Date of birth
Registered
Activity