Russian TYPO3 community Форум больше не используется. Присоединяйтесь к каналу #community-ru в Slack for TYPO3 community  

Вернуться   Russian TYPO3 community > Тематические форумы > Разработка расширений / TYPO3 extension development

Ответ
 
Опции темы Опции просмотра
Старый 01.10.2013, 10:54   #31
Ивано++
Senior Member
 
Аватар для Ивано++
 
Регистрация: 18.01.2013
Адрес: Russia , Moscow
Сообщений: 796
По умолчанию

Цитата:
Сообщение от Ивано++ Посмотреть сообщение
В общем сейчас прихожу к выводу - кэшируется на БД realurl - и ладно...
В этом нет ничего плохого...
С memcache - конечно лучше стало (имею в виду, то что удалось поставить на memcache)... И это заметно даже на не большой проекте.

Единственное проблема с которой столкнулся при использовании memcache - это на основе чего генерировать уникальный ключ кэша - что бы разрешить запись кэша?

На основе id-страницы - не подходит
На основе useCacheHash - также не подходит

В обоих случаях пользователь может ввести id=xxxx - и будет создан кэш + 1...
И таким образом будет насоздано куча всяких "несущесвующих" кэшей.

А с тэгами ищу решение...
--- С генерацией ключа - так и не разобрался...
Ищу тэги для memcache...

Последний раз редактировалось Ивано++; 01.10.2013 в 11:04
Ивано++ вне форума   Ответить с цитированием
Старый 01.10.2013, 15:33   #32
dmartynenko
Senior Member
 
Аватар для dmartynenko
 
Регистрация: 20.07.2007
Адрес: Беларусь, Минск
Сообщений: 957
Отправить сообщение для dmartynenko с помощью ICQ
По умолчанию

В общем случае ключ в кэше должен учитывать все что у вас может повлиять на содержимое. Т.е. id страницы, текущий type, GET переменные, содержимое config и т.п. И еще место откуда вызывается.

Примерно так
PHP код:
            $cache_key md5(serialize(array(
                
__CLASS____FUNCTION__,
                
$GLOBALS["TSFE"]->id$GLOBALS["TSFE"]->type,
                
$_GET[...]))); 
Нужно помнить еще и такой нюанс - если у вас на одном сервере несколько проектов, и есть одни и те же модули. То теоритически разные клиенты могут использовать одинаковые ключи. Ведь в мемкешед общее пространство, никак не разграниченное между разными пользователями и подключениями.
dmartynenko вне форума   Ответить с цитированием
Старый 01.10.2013, 16:35   #33
Ивано++
Senior Member
 
Аватар для Ивано++
 
Регистрация: 18.01.2013
Адрес: Russia , Moscow
Сообщений: 796
По умолчанию

Цитата:
Сообщение от dmartynenko Посмотреть сообщение
В общем случае ключ в кэше должен учитывать все что у вас может повлиять на содержимое. Т.е. id страницы, текущий type, GET переменные, содержимое config и т.п. И еще место откуда вызывается.

Примерно так
PHP код:
            $cache_key md5(serialize(array(
                
__CLASS____FUNCTION__,
                
$GLOBALS["TSFE"]->id$GLOBALS["TSFE"]->type,
                
$_GET[...]))); 
Нужно помнить еще и такой нюанс - если у вас на одном сервере несколько проектов, и есть одни и те же модули. То теоритически разные клиенты могут использовать одинаковые ключи. Ведь в мемкешед общее пространство, никак не разграниченное между разными пользователями и подключениями.
Из всего этого не понятно следующее:

1. вот человек ввел id=5005034 (у нас движок выдаст 404 - ошибку) - сам просчитает, т.к. такой страницы нет, и для type - тоже самое
а вот если мы используем показ новостей к примеру по additionalparams для typolink - пример tx_news[id]=50
получается если человек от "себя" введет не верный id-записи, то у Вас запишется кэш +1 - которого в принципе не существует. И так до тех пор, пока он (злоумышленник-вредитель) не устанет вводить разные значения - одним словом так и сайт можно "завалить".... Получается как - каждый раз проверять на существоание такого ID, и если есть, то разрешаем писать кэш?

Как проверить валидность id-записи?

2. вот мое наблюдение по работе ядра системы:
если у нас запрашивается не верная страница по id, type - то typo3 в кэш ничего не пишет - здесь вродебы все ясно...
но вот как она проверяет additionalparams, в т.ч. useCachHash - что это валидный url? Как я не старался - все равно она лишних кэшей никаких не пишет... Даже useCachHash = FALSE

Цитата:
Сообщение от dmartynenko Посмотреть сообщение
Нужно помнить еще и такой нюанс - если у вас на одном сервере несколько проектов, и есть одни и те же модули. То теоритически разные клиенты могут использовать одинаковые ключи. Ведь в мемкешед общее пространство, никак не разграниченное между разными пользователями и подключениями.
А про это, думаю - что просто префикс добавить и все...
Ивано++ вне форума   Ответить с цитированием
Старый 01.10.2013, 18:58   #34
dmartynenko
Senior Member
 
Аватар для dmartynenko
 
Регистрация: 20.07.2007
Адрес: Беларусь, Минск
Сообщений: 957
Отправить сообщение для dmartynenko с помощью ICQ
По умолчанию

С левыми id проблем не вижу.

Вы же делаете как:
1. Строите cache_key
2. Проверяете в кэше
3. Если нет, то делаете запрос в БД
4. Если нет записи - выдаете 404
5. Если есть в БД, формируете контент и пишете в кэш

Логично что ответы 404 в кэш писать не нужно.

Цитата:
А про это, думаю - что просто префикс добавить и все...
Это я к тому, что бы не использовать тривиальные ключи вроде table_name+id, или просто id. Если добавить к ключу $GLOBALS["TSFE"]->id, а еще можно и domain, то уникальность между сайтами гарантирована.
dmartynenko вне форума   Ответить с цитированием
Старый 02.10.2013, 00:03   #35
Ивано++
Senior Member
 
Аватар для Ивано++
 
Регистрация: 18.01.2013
Адрес: Russia , Moscow
Сообщений: 796
По умолчанию

Цитата:
Сообщение от dmartynenko Посмотреть сообщение
С левыми id проблем не вижу.

Вы же делаете как:
1. Строите cache_key
2. Проверяете в кэше
3. Если нет, то делаете запрос в БД
4. Если нет записи - выдаете 404
5. Если есть в БД, формируете контент и пишете в кэш

Логично что ответы 404 в кэш писать не нужно.
К сожалению - это очень сложный механизм...
Возможно нашел решение - более простое - по поводу разрешить/запретить кэширование - но оно связанно с useCashHash - и не знаю насколько оно будет уместно ... И сейчас не совсем пойму - почему useCashHash так плох?

Цитата:
Сообщение от dmartynenko Посмотреть сообщение
Это я к тому, что бы не использовать тривиальные ключи вроде table_name+id, или просто id. Если добавить к ключу $GLOBALS["TSFE"]->id, а еще можно и domain, то уникальность между сайтами гарантирована.
Может это замечательная функция позволит уж точно не запутаться на разных проектах:
PHP код:
md5(t3lib_div::getIndpEnv('TYPO3_SITE_URL') ... // текущий url-страницы 
?
Ивано++ вне форума   Ответить с цитированием
Старый 02.10.2013, 01:08   #36
Ивано++
Senior Member
 
Аватар для Ивано++
 
Регистрация: 18.01.2013
Адрес: Russia , Moscow
Сообщений: 796
По умолчанию

Это то, что так долго искал - наверное не 1-и месяц:
самое странное что в тему useCashHash valid - на оффициальном форуме typo3.org - мне ничего не ответили, вернее ответили, но как-то расплывчато было сказано - что это не возможно - и это ответ от Core...!!!... Странно что там, даже PHP-код вставить нет возможности....

Теперь из t3lib_div::cHashParams и t3lib_div::calculateCHash стало понятно, как можно проверить ... useCashHash - оказывается - это просто md5 - всех _GET-параметров....

PHP код:
//////////////////////////////////////////////////////////////////////
    // Определяем тип страницы
    //////////////////////////////////////////////////////////////////////
    
$cHash_array t3lib_div::cHashParamst3lib_div::implodeArrayForUrl(''$GLOBALS['_GET'])  );
    
$cHash_calc t3lib_div::calculateCHash($cHash_array);
    
    
// обычные // "1" Обчыная страница
    
if ($GLOBALS['TSFE']->getHash() != null) {
            
        
// кэшировать можно
    
}
    
// useCashHash = 1 // "2" виртуальная страница 
    
if ($GLOBALS['TSFE']->cHash != null){ 
            
        
// кэшировать можно
                
    
}
    
// Не для кэширования // "3" запрещенная к кэшированию - виртуальная страница
    
if (($GLOBALS['TSFE']->cHash != null && $GLOBALS['TSFE']->cHash != $cHash_calc)
    OR (
$GLOBALS['TSFE']->cHash == null && $cHash_calc != null)){ 
    
        
// кэшировать запрещено!
    
    

А с тэгами - наверное - если в memcache - ничего не получится - то останусь на БД
Т.к. по тэгам хочется иметь что - то вроде

Код HTML:
//[prefixProject][domainName][pageId/Alias][typeNum][L][useCashHash][commendId]...
//[prefixProject][domainName][pageId/Alias][typeNum][L][useCashHash][newsId]...
ТЭГИ ::: https://code.google.com/p/memcached-...seMemcachedTag
Пока как-то так.

Последний раз редактировалось Ивано++; 02.10.2013 в 01:35
Ивано++ вне форума   Ответить с цитированием
Старый 07.10.2013, 22:28   #37
Ивано++
Senior Member
 
Аватар для Ивано++
 
Регистрация: 18.01.2013
Адрес: Russia , Moscow
Сообщений: 796
По умолчанию

Использую memcache - тэги можно хранить в БД.
Ивано++ вне форума   Ответить с цитированием
Старый 03.12.2013, 11:12   #38
Ивано++
Senior Member
 
Аватар для Ивано++
 
Регистрация: 18.01.2013
Адрес: Russia , Moscow
Сообщений: 796
По умолчанию

Немного по поводу сброса по тэгам...

Есть 1-страница - к примеру...
На ней работают два плагина:

Плагин А) - список новостей
Плагин Б) - список статей

Каждый из плагинов создает виртуальные страницы с useCachHash...
И добавим такой сложный элемент как постраничная навигация для каждого из плагинов.

При добавлении новости или статьи - нам же придется все равно сбрасывать весь кэш страницы с useCachHash - что бы заново пересчитать постраничную навигацию - или же делать так, что бы сбрасывался конкретный планиг - что думаю приведет в последствии к немалой путанице при поддержке проекта...
__________________
Иван Литовченко
http://iv-litovchenko.ru/
Ивано++ вне форума   Ответить с цитированием
Старый 06.12.2013, 13:49   #39
dmartynenko
Senior Member
 
Аватар для dmartynenko
 
Регистрация: 20.07.2007
Адрес: Беларусь, Минск
Сообщений: 957
Отправить сообщение для dmartynenko с помощью ICQ
По умолчанию

Вот поэтому я всегда рекомендую встраивать кэширование внутрь плагина.
Потому что в таком случае может получиться следующая картина: 1000 записей (страниц) в одном плагине, 1000 в другом. В итоге в худшем случае имеем 1000х1000 = 1 000 000 записей в кэше. Если не живые люди, то роботы поисковиков сканируя все ссылки на сайте это обеспечат. При том что реально уникальной информации 1000 + 1000 = 2000 единиц. И столько же будет в кэше, если делать кэширование внутри плагина.
dmartynenko вне форума   Ответить с цитированием
Старый 06.12.2013, 21:23   #40
Ивано++
Senior Member
 
Аватар для Ивано++
 
Регистрация: 18.01.2013
Адрес: Russia , Moscow
Сообщений: 796
По умолчанию

Цитата:
Сообщение от dmartynenko Посмотреть сообщение
Вот поэтому я всегда рекомендую встраивать кэширование внутрь плагина.
Потому что в таком случае может получиться следующая картина: 1000 записей (страниц) в одном плагине, 1000 в другом. В итоге в худшем случае имеем 1000х1000 = 1 000 000 записей в кэше. Если не живые люди, то роботы поисковиков сканируя все ссылки на сайте это обеспечат. При том что реально уникальной информации 1000 + 1000 = 2000 единиц. И столько же будет в кэше, если делать кэширование внутри плагина.
Не совсем сообразил в плане рассчетов по умножении и получению 1 000 000 записей в кэше.

1 страница - на ней два плагина:

первый плагин генерирует 1000 виртуальных страниц через useCachHash
генерирует 15 постраничных страниц (к примеру)
typolink = index.php?id=95&tx_my_ext_1[record_detail]=1&useCachHash=1
typolink = index.php?id=95&tx_my_ext_1[pagination]=1&useCachHash=1


второй плагин генерирует 1000 виртуальных страниц через useCachHash
генерирует 25 постраничных страниц (к примеру)
typolink = index.php?id=95&tx_my_ext_2[record_detail]=1&useCachHash=1
typolink = index.php?id=95&tx_my_ext_2[pagination]=1&useCachHash=1

1000 + 15 + 1000 + 25 = 2035 виртуальных страниц, ну и + 1 страница, на которой эти плагины работают...
откуда мильёон?
__________________
Иван Литовченко
http://iv-litovchenko.ru/
Ивано++ вне форума   Ответить с цитированием
Ответ

Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB code is Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход

Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Cлишком сложно показалось? carlos Вопросы выбора CMS 5 04.07.2007 16:37


Часовой пояс GMT +4, время: 17:37.


Работает на vBulletin® версия 3.8.1.
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Перевод: zCarot

Хостинг и техническая поддержка: TYPO3 Лаборатория