User Tools

Site Tools


Translations of this page:
ru:new_rotation_faq

Table of Contents

New Rotation FAQ

What is mod_rewrite

mod_rewrite - это модуль для апача, которые позволяет делать “красивые” урлы. Тот же модуль есть и для nginx и для lighttpd.

Например, в дефолтных темпелйтах урлы примерно такие http://domain/gallery/cool-gallery/index.html , понятно что реально на серваке таких урлов нет. Мот реврайт преобразовывает этот урл в http://domain/scj/tube/?slug=cool-gallery , а красивый урл - для СЕ и юзеров.

.htaccess который создается в самом начале задает правила реврайтов.

Попоытка просто объяснить как это работает:

И так, как было сказано выше /gallery/cool-gallery/index.html такого урла реально на сервере нет. Что бы посмотреть галеру урл должен быть такой: /scj/cgi/out.php?url=content&slug=cool-gallery, что не совсем эстетически хорошо. Поэтому мы в специальный файл .htaccess пишем реврайт - это специальное правило, как апач будет преобразовывать урлы. Для этого конкретнго случая у нас есть такой реврайт:

RewriteRule ^gallery/(.*)/index.html$ /scj/cgi/out.php?url=content&slug=$1

это значит, что если урл начинается с gallery/, а потом идет что угодно (.*) до знака /, и заканчивается это на /index.html - значит это наш случай. каждый из “что угодно” (.*) получает номера - соотв. первое “что-то” это $1 , второе - $2.

В нашем примере $1 будет равно cool-gallery. Соотвественно апач преобразует этот урл в /scj/cgi/out.php?url=content&slug=cool-gallery и вы увидите галеру.

Урлы вида /gallery/cool-gallery/index.html на страницах получаются потому что в сабтемплейтах страниц у вас записано что-то вида

href="/gallery/<!--GALLERY_SLUG-->/index.html

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

Почему в Rotation - Groups у меня показывает в группе 10 галер, а на странице сайта или Rotation - List thumbs 20

1 галера может находится в больше чем 1 групп (категории). Это видно в редактировании любой тумбы - у нее есть main группа (одна) и ext группы (много). Rotation - groups считает только по main. Это сделано что б было ясно сколько точно уникальных галер.

Например, у нас 2 группы А и Б. и 2 галеры - у одной main группа А, у другой main групра Б. Но у обоих в поле ext groups отмечены и А и Б. Rotation - Stats покажет что у нас конкретно 2 галеры , одна в группе А и одна в группе Б.

На сайте же в каждой из групп будет видно по 2 галеры.

  1. Залить куда угодно тумбы
  2. при и импорте указать Image List = перечисление урлов картинок

Что такое Init cats в Rotation - Special или почему я добавил категорию в админке, а она не появилась на сайте

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

Если вы добавили новую категорию - она появится максимум через 15 минут, если надо быстрее - жмите эту кнопку.

What is cache

Скрипт не генерит статические html страницы (см выше вопрос по mod_rewrite), все страницы динамические. Дабы не пересоздавать страницу для каждого пользователя скрипт создает ее один раз и сохраняет в кеше на опредленное время (CACHE_TIME), следующий посетитель в течение времени жизни кеша - получит эту страницу уже из кеша, не нагружая сервак.

Время кеша задается в common.php CACHE_TIME, начиная с апдейта 46 время в common.php можно не указывать, а указывать в сетингах ротации. Обратите внмиание, что время указаннное в common.php имеет преимущество, те если указано в common.php то настройки ротации скрипт игнорирует.

Дабы посмотреть какую-то страницу без кеша надо добавить в урле параметр skip_cache=true. Например, http://domain.com/?skip_cache=true

Начиная с апдейта 46 появила recreate cookie - Rotation - Special - Recreate visited pages - скрипт ставит секретную куку вашему браузеру на 10 часов (можно снять куку в любой момент там же). Если вы зайдете с этой кукой на любую страницу вашего сайта, эта страница будет пересоздана (те сброшен кеш именно для этой страницы). Бывает полезно при изменении дизайна какой-то одной определенной страницы.

Те разница между skip_cache и recreate cookie в том, что skip_cache покажет страницу без кеша только вам и все, а recreate cookie покажет страницу без кеша, потом такой какую вы ее видете положит в кеш и другие пользователи будут видеть ее из кеша в таком виде.

Еще раз: страница создава в 00 минут. Время кеша 10 минут. в 05 вы меняете дизайн. если вы в 05 посмотрели его со skip_cache - то увидите новый дизайн, но пользователь, который пришел в 06 (те ДО времени когда проэкспарится кеш) - увидит старый дизайн. если вы в 05 открыти страницу с recreate cookie - то пользователь который пришел в 06 увидит в новом дизайне.

Cache Engines (New)

Базовый принцип работы движка - сгенерить нужную страницу, положить ее в кеш на определнное время и показывать ее пока кеш не проэкспарится. Какие движки есть на данный момент:

Файловый Базово кеш хранится в файлах (scj/cache - файловый кеш). Плюсы - он работает везде и сразу. Минусы - это именно файловый кеш, он он не так быстр, не так эффективно кешится системой как хотелось бы и приходится отдельлно заботиться о размере папки с кешем.

Memcached В свое время это конечно был большой шаг вперед в плане кеширования. Плюсы - все его знают, админы без проблем ставят на хостиинг, его просто администриировать и тп. Минусы - никакого понимания о реально занимаемой памяти получить практически невозможно, при перегрузке сервака весь кеш удаляется и нужен тн “разогрев кеша” те положить туда наиболее используемые данные. При перегрузке сервака из-за нагрузки это серьезная проблема - сервак и так нагружен, а тут еще и всесь кеш исчез.

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

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

Как установить:

  1. попросить админа поставить Memcached
  2. прописать в конфиге мемкеш
$config['memcached_host'] = '127.0.0.1';
$config['memcached_port'] = '11211';

Поэтому сейчас появились новые движки которые рекомендуются к использованию

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

Решение на которое наиболее просто перейти - Couchbase CouchBase - это продолжение MemBase, видимо ближайщего потомка memcachedb, который в свою очередь родом из memcached.

Главное - от вас не требуется практически никаких движений дабы начать его использовать. Вы ставите CouchBase и он работает точно так же как мемкеш. Те для того что бы начать его использовать надо

  1. попросить админа поставить CouchBase
  2. в пхп добавить extension couchbase
  3. прописать в config.php
	$config['couchbase_host'] = '127.0.0.1';
	$config['couchbase_port'] = '11210';
	$config['couchbase_username'] = 'testuser';
	$config['couchbase_password'] = 'testuser';
	$config['couchbase_bucket_name'] = 'test';

и все, вы уже используете современную версию мемкеш. Вы можете это использовать даже с версией 48-49.

Чем это лучше чем memcached

  • Нет понятия “разогрев кеша”. По факту это файловый кеш,но сделанный на порядок правильнее, который намного меньше грузит диск, просчитывает когда и как лучше записать данные блоком на диск и тп. Данные при этом лежат как бы в нескольких файлах, а не сотнях файлов как файловый кеш.
  • Проэкспаренные данные исчезают с диска\памяти сами, не надо самостоятельно заботиться об этом.
  • Можно так же как и с мемкешем ограничить кол-во памяти выделенное под кеш, но при этом кеш не будет ограничен этим кол-вом. Даже если данных будет больше - оно оставит самые активные в памяти, а остальное сгрузит на диск. И подгрузить нужный элемент с диска - быстрее чем сгенерить его по новой.
  • Можно быстро и просто масштабировать систему из вебадминки
  • Можно легко завести несколько кешей. В варианте Couchbase - это как несколько мемкешей, но делается все опять же из вебадминки, что быстро и удобно. те можно завести например 10 кешей, каждый из которых будет на своем порту и просто указать для каждого сайта свой порт. В этом случае осуществиться желание о внопке “Удалить весь кеш” - вы сможете из вебадминки удалять весь кеш для одного сайта.
  • При перезде кеш легко скопировать поскольку копируется не масса мелких файлов как с файловым кешем, а одна база.

Redis - отдельный написанный с 0 проект NoSQL базы. Смысл его для наших целей практически тот же (в реальности couchBase это уже больше document oriented хранилище, а Redis - чисто key-value хранилище ). Для работы с ним функционал был добавлен в версии 50.

Для того что бы начать его использовать надо

  1. попросить админа поставить Redis
  2. попросить его же поставить модуль redis для пхп
  3. прописать в config.php
$config['redis_host'] = '127.0.0.1';
$config['redis_port'] = '6379';
$config['redis_database'] = 0; 
$config['redis_password'] = '';

если redis висит на сокете то выглядеть будет примерно так 

$config['redis_host'] = '/tmp/redis.sock';
$config['redis_port'] = '0';

и все.

В данным конфиге кроме понятных полей есть несколько новых. redis_password - в большинстве случаев не актуально посколько сейчас все на dedicated servers. redis_database - у Redis нет буквенных названий баз, а есть номера. те если у вас несколько сайтов - вы можете указать каждому сайту свой номер. Но можно и не указывать и использовать одну базу для всех сайтов. Разница будет в том, что если вы захотите скинуть весь кеш и у вас используется одна база для всех сайтов - кеш удалится для всех сайтов. Если же у каждого сайта будет своя база - кеш скинется для одного.

Чем это лучше чем memcached

  • Все теже плюсы и в случае couchbase.
  • Redis более заточенное под кеш решение, но у CouchBase готовая удобная админка (говоря о версии 2+).

Где хранится кеш ? (memcache)

По умолчанию используется файловый кеш (храниться в /scj/cache), но можно использовать и например Memcache. Для этого надо только добавить в scj/includes/config.php

$config['memcached_host'] = 'localhost';
$config['memcached_port'] = '11211';

адрес и порт могут меняться (уточните у вашего админа), но в большинстве случаев они будут такими же.

Имеет смысл настроить memcache на работу через сокт - это быстрее. В этом случае конфиг будет примерно такой

$config["memcached_host"] = "unix:///tmp/memcache.sock";
$config["memcached_port"] = 0;

Есть несколько ньансов:

  1. файловый кеш не такой медленный как можно подумать. Смысл в том, что работа с ним эффективно кешируется системой и разница не глобальна
  2. при этом кеш перманентно лежит на диске и в случае перегрузки сервера никуда не пропадет и скрипту не придется по новой генерить весь кеш по новой. Те ситуация такая: у нас много трафа, вдруг что-то пошло не так и мы перегружаем сервак. После поднятия сервака какая-то часть сайта уже есть в кеше и все продолжает работать, в случае же в мемкешем весь кеш утерян и скрипту надо на лету создать массу страниц которые до этого лежали в кеше, что опять создает нагрузку
  3. если вы все же ставите мемкеш - убедитесь, что ему выделено достаточно памяти. Сложно сказать конкретно сколько надо памяти, тк это прямо зависит от размера базы и веса шаблонов (в кеш кладет уже сгенерированную страницу, html), потому что как только законится доступная память - страницы будут генериться на лету.
  4. размер мемкеша должен быть достаточным, иначе данные будут “выдавливаться” из кеша. Например у нас кеш 10 метров, и есть 10 записей по 1 метру. Добавление еще одного в кеш - выдавит первый из кеша. Проблема тут в том, что у мемкеша есть понятие фрагментации памяти, когда даные занимают в реальности больше, чем говорит статистика. Мемкеш сохраняет грубо говоря блоками. Для простоты понимания если блок 100 байт, а мы сохраняем 1 байт, то репортит оно что занят 1 байт, но в реальности оно занимает 100 байт. Для скрипта проблема в том, что если вытесняются какие то данные то никакой ошибки мемкеш не возвращает и обработать такую ситуацию в скрипте невозможно. Примерно наблюдение - 15% фрагментация.

Почему у меня в админке и на такой-то странице сайта тумбы стоят в разном порядке

При одинаковой сортировке порядок должен быть одинаковым с учетом следующих ньансов:

1. в админке показывает имено так как оно есть в базе по цтр например, на странице сайта в каких то местах могут стоять “новые тумбы”, которые тестируются. Например, на странице тумба 123 стоит на 15м месте, а в админке на 50м. Вероятно это новая тумба, которую скрипт тестирует.

2. Новая тумба может получить неожиданно большой цтр. Например, показали 2 раза и 1 раз по ней кликнули = цтр 0.5 , однако 2 показа это не повод судить что тумба хорошая. Потому по дефолту “новые” тумбы не показываются на первых местах. Изменить это можно в сетингах (New Rotation: New thumbs placement : Place new thumb (shows less then New thumbs timelive) on places other then Test positions start if it has good CTR. ). Проверить легко если в List Thumbs выбрать New Thumbs = dont show new.

Почему у меня на старнице пустое облако тагов

Облако тагов генерится из активных тагов раз в 30 минут и кладется в кеш. Соответственно варианты:

  • нет активных тагов
  • не прошло 30 минут
  • вы прибили кеш

Тумбы (галереи) не удаляются

  • ранее была проблема при удалении большого кол-ва тумб, например у спонсора 10к тумб, вы удаляете спона, скрипт пыдается это удалить сразу, но не успевает - получается таймаут. Это усугубляется если надо удалить не просто тумбы, а кастом гали.
  • сейчас тумбы удаляются по крону. Те когда вы жмете в админке “удалить” тумбы не удаляются мгновенно, а переходят в статус 'Marked for deletion', раз в 10 минут крон смотрит есть ли такие и удаляет
  • если надо удалить “прямо сейчас” - запускаем rotation.php с параметром process_deleted=true
  • cd /PATH_TO_/scj/bin/; env HTTP_HOST=yourdomain.com php rotation.php process_deleted=true 
  • единственое исключение: если вы удаляете тумбы в Rotation - List thumbs и удаляется меньше 30 тумб - то удаление происходит сразу.

Скорость удаления гадер сложно прогнозируема и зависит от кол-во и нагрузки сервака, есть ли кастом гали, на текущем серваке они или на фтп и так далее.

Сколько надо траффика чтобы отротировать тумбы

Не обязательно отротировать все до конца, чтобы прода была хорошая, но в целом посчитать сколько надо трафа очень легко.

Тумба считается отротированной, когда ее показали New thumbs timelive раз , по дефолту 500. Допустим на странице - 200 тумб, а % of test places on page по дефолту 15, те из 200 мест на старнице новые будут показываться на 30 местах. Те каждый заход на старницу это +30 показов для новых тумб. Например у нас 10 000 тумб, что б их отротировать нам надо 10000*500 = 5000000 показов. Одиз заход на старницу - это 30 показов, те что б отротировать базу в 10к нам надо 5М /30 = 167к загрузок страницы.

Если не считать банальной нехватики трафика, речь обычно о том, что у галеры например 10 тумб, но показы только у одной. Как это происходит: например у нас 100 галер по 10 тумб, на странице 20 тумб. Начинаем ротацию. У всех цтр 0. Вывели первую тумбы с галер ИД 1 - 20. Они получили цтр больше 0. Нам надо обновить страницу. тестовых например 5 на странице.

Мы выводим ИД 1 - 15 как 15 лучших (а там пока цтр и показы получила только пурвая тумба с галеры). А потом 5 тестовых - тут мы можем взять тумбу номер 2 с галер ИД 16-20

Получилось так что эти тумбы набрали меньше чем тумба 1 галер ИД 1-15, мы берем например 3ю тумбу с галер ИД 16-20.

Таким образом получается что у галер ИД 1-15 показы есть только у пурвой тумбы. Когда их ЦТР будет меньше чем ЦТР других - их “выдавит” из топа.

У них там же есть возможность быть показанными на странице 2 пагинации, но опять же при условии что ваш траффик доходит до 2й страницы.

Изначально у out.php есть параметр &link=blabla смысл которого в том, что статистику по blabla можно видеть Stats - Links. Но ротация использует его для передачи параметров ротации (12x123x1234). Выглядит это на практике очень просто: например линк /gallery/cool-desc/index.html?12x345x567 реврайтом (см выше что это такое) преобразуется в урл вида out.php?slug=cool-desc&link=12x345x567 и позже скрипт обрабатывает статистику по линкам преобразуя это в статистику по тумбам. Соответсвенно если у вас урл вида out.php?member=domain.com&link=top то такой вариант все такое же работает, однако для линков ротации его использовать не получается. Дабы решить эту ситуацию был введен еще один пармтер &link2 смысл которого в том, что вы можете делать out.php?slug=cool-desc&link=12x345x567&link2=blabla и все так же смотерть статистику по линкам и одновременно ротировать тумбы.

Что такое тумбы категории

Тумба категории - это по-дефолтлу лучшая тумба из категории. Однако, есть возможность поставить тумбой категории не лучшую, а например 2ю по ЦТР или 3ю и тп, эти настройки можно найти в Rotation - CMS - Settings.

How to create a master site from a slave

  1. Делаем дамп базы мастера
  2. Смотрим в rot_linked_db номер слейва, который мы отсоединяем (Х)
  3. Отсоединяем нужный слейв от мастера
  4. Заливаем в базу бывшего слева (дамп) из пункта 1, но только таблицы rot_*
  5. Удаляем все rot_gallery_stats* кроме номера из п2
  6. rot_gallery_statsХ переименовываем в rot_gallery_stats1
  7. В rot_linked_db удаляем все записи кроме записи с ИД 0

Pool - Active - Old - фактически надо для работы Shift settings в группах ротации. Смысл в том, что бы наполнять сайт автоматически. Те вы добавили много галер в статус pool, поставили добвлять раз в день 10 галер и сайт их доабвляет из пула в активные, и они появляются на сайте. Получается видимость ежедневного обновления. Old - если вы хотите убирать старые галеры с сайта сохраняя общее кол-во одинаковым.

На сайте в листинге показываются галеры только со статусом active.

preload - галеры добавляются в Preload (в админке) что б вы могли выбирать какие из сграбеленных тумб по итогу будут на сайте. Те которые вы не выберете - будут удалены.

to_grab - когда галеры добавляются в базу они получают этот статус прежде чем граббер создаст тумбы для них. В момент создания тумб они получают статус processing. to regrab - галера ожидает реграба.

to delete - галера ожидает удаления. Часо на удаление помечается много галер, и мгновенно удалить их невозможно, особенно

grab error - если при грабе тумбы что-то пошло не так галера или удаляется или получает статус grab error в зависимости от ваших настроек.

Banned - урл остается в базе и не будет добавлен снова. Как и grab error это имеет смысл только в том случае, если вы добавляете галеры через import sets и есть вероятность что какие-то галеры будут добавлены снова и снова. Например, вы добавляете через импорт сет, галеры идут в preload. Вы отобрали часть галер, а какие то решили не добавлять. Через час этот импорт сет добавляется снова, а там есть та же галера снова - она опять попадет в preload и вам придется опять ее отсеивать. Что б этого не было - можно добавить в banned. Минус в том, что база в этом случае растет и там есть галеры которые не используются, но занимают место в базе.

Inactive (и аналог hidden в версии 1.X ) - галера не показывается в листинге, но при прямом заходе на урл - видна. Смысл следующий: например у нас была галера, она проиндексирована, но она хотлинковала контент откуда-то. В какой-то момент контент удалили и галерея стала нерабочей. Ранее чекер удалял такие галереи (точнее 2 варианта - удалить сразу или inactive), но был минус в том, для СЕ спайдеров старый урл теперь стал 404. Возможно лучше если будет возвращать страницу без контента, но не 404. Для этого и есть статус “Hidden” - это значит галера будет видна по прямому урлу, но тумбы этой галеры не будут в ротации. те попасть на нее можно будет только по прямому урлу. Этот статус можно выставить в импорт сете, который удаляет галереи.

Аналогичная опция есть у Gallery Checker.

Точный эффект от этого для СЕ - неизвестен.

Как импортировать очень большой дамп

Версия 2.* умеет добавлять большие файлы через importset самостоятельно (теоретически любого размера). Просто добавляете урл и он постепенно все добавит.

eval()'d code

Если при заходе на любую страницу у вас пишет что-то вроде “Parse error: some error, in /some/path/scj/tube/index.php(0) : eval()'d code on line 1717” - это 100% значит что у вас ошибка в вашем пхп коде в темплейте.

По опыту наиболее частой проблемой является несоблюдение ковычек. http://smartcj.com/wiki/doku.php?id=ru:new_rotation_hints#php_code_in_template

Crop Profiles

Это наборы параметров для обработки тумб.

Если вам надо размер только по одной стороне, но вторую сторону ставим 0. Например, если указана ширина, а высота 0, то ширина будет фиксированной, а высота будет меняться под размер тумбы. Это актуально для сайтов типа пинтерест.

Image Command - это команда которая применяется ДО того как сделана тумба. единственный параметр {FILE} - это текущая картинка. Например,

/usr/bin/your_command -some_param {FILE}

Thumb Command - аналогично только для уже сделанной тумбы.

Face Detect - см FaceDetect

How to grab custom galleries

Иногда по какой-то причине вы не хотите делать другой сайт слейвом, а хотите сграбить кастом галеры с другого своего сайта, а например исходные урлы уже недоступны. При этом галеры у вас сделаны с картинками на отдельной старнице - в этом случае единственный вариант сграбить их это использовать Deep fetch. Проблема тут однако в том, что с таких страниц обычно стоят ссылка на страницы тагов, категорий и прочего, где очень много других тумб, в при deep fetch скрипт пытается их все скачать. Другой вариант - если на кастом галере есть какой-то ским. В этом случае такой граб может быть весьма длительным процессом.

Лучше сделать так:

  1. создайте отдельный темпелйт, например plain_gallery где все ссылки будут прямо на картинку, а не на отдельную страницу
  2. Rotation - export даст вам урлы вида http://domain/scj/tube/?content_id=0a5cf5010394ea3a0111f3cce9cca0b7
  3. в любом редакторе поиск\замена и у вас http://domain/scj/tube/?force_template=plain_gallery&content_id=0a5cf5010394ea3a0111f3cce9cca0b7
  4. и уже эти урлы отдаете на граб в другой скрипт

How to copy rotation info

Данные по ротации хранятся в таблицах rot_gallery_stats*, таким образом если вам надо скопировтаь данные по ротации с одного слейва на другой вам надо

  1. посмотреть какой ИД у слейва с которого копируем
  2. какой ИД слейва на который копируем
  3. скопировать(!) таблицу условно rot_gallery_stats2 в rot_gallery_stats3

Category tags does not work

Проблема обычно в использовании тага категории на страницах галеры, например <!–CATEGORY_NAME–>, при этом галера может иметь более одной категории и не ясно какую из них надо выводить. Поэтому используется либо таг вида <!–CATEGORY_1_NAME–> либо конструкция <groups … >…</groups>

Group Deactivation (Group Exclusion)

Допустим у нас есть мастер на котором группы А и Б. Мы подключаем слейв на котором деактивируем группу Б. При выборке для слейва у нас есть 2 варианта:

  • выборка все галеры КРОМЕ группы Б
  • или все галеры из группы А

на первый взгляд это одно и тоже. Однако если у нас галера состоит в обоих группах то в одном случае она попадет в выборку, а в другом нет.

Поэтмоу в сетингах есть настройка Group Exclusion

  1. Hard = выборка идет как “все галеры КРОМЕ группы Б” (те тут галера состоящая в обоих группах не попадает в выборку)
  2. Soft = выборка идет по 2му варианту, те “все галеры из группы А” (те галера попадает в выборку)

Когда это надо: вариант hard - это когда у нас условно 3 группы: страйт, гай и тин. на слейве мы хотим например только страйт. Понятно что серфер гай видеть вообще не хочет. Те тут жесткое исключение.

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

В этом случае можно сделать тн гейт что бы преобразовать ее в более понятный вид:

Пример:

Условно у нас есть галера http://gallery/ со странными тагами

<html>
<body>
<dont_grab_this src='http://gallery/0.jpg'></dont_grab_this>
<some_strange_tag src='http://gallery/1.jpg'></some_strange_tag>
<some_strange_tag src='http://gallery/2.jpg'></some_strange_tag>

стандартным парсер скрипта такое разобрать не может, поэтому мы делаем гейт http://my_server/gate.php который разбирает эту галеру и показывает тумбы оттуда (код упрощен для примера, конечно надо больше проверок)

<?php

if (!isset($_GET['url']) or !$_GET['url']) die("Need url");

if ($html = file_get_contents($_GET['url']) ) {
	preg_match_all("|<some_strange_tag src='(.*?)'>|", $html, $out);

	$image_num = (isset($_GET['num'])) ? $_GET['num'] : 1;

	if ($out[1][$image_num-1]) {
		header("Content-type: image/jpeg");
		echo file_get_contents($out[1][$image_num-1]);
	}
}

проверяем что гейт работает

http://my_server/gate.php?url=http://gallery/ http://my_server/gate.php?url=http://gallery/&num=2

по этим урлам в браузере должны отобразиться соответственно http://gallery/1.jpg и http://gallery/2.jpg с нашей галеры.

Теперь импортируем эту галеру, паттерн: url|thumb_url

http://gallery/|http://my_server/gate.php?url=http://gallery/,http://my_server/gate.php?url=http://gallery/&num=2

Как тут видно урл будет http://gallery/, а для тумб мы возмем изображения, которые видны по урлами http://my_server/gate.php?url=http://gallery/ и http://my_server/gate.php?url=http://gallery/&num=2.

Тк мы не знаем сколько точно будет картинок на галере, то в список тумб можно добавить и например http://my_server/gate.php?url=http://gallery/&num=123 (те номер несуществующий) - просто скрипт не сможет его сграбить и пропустит.

Вариант 2: замена на стадии импорта

Допустим у нас есть import set http://sponsor/dump.php который выдает дамп вида

url|thumb_url|desc

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

Делаем гейт - вариант 2:

  • гейт получает урл фида, грабит его, обрабатывает каждую строку как галеру и добавляет поле с картинками для кастом галеры, те в данном случае гейт выдает дамп сразу в виде url|thumb_url|desc|image_list
  • мы добавляем в импорт сет сразу gate.php?url=http://sponsor/dump.php

Вариант 3: импорт с использованием XPath

Например, у нас есть новый туб который дает урлы вида http://tube/gallery.html, экспорта у него нет, мы сграбить оттуда flv_url и flv_thumb_url и сделать из них свои кастом галеры.

  • Если не в курсе что такое xpath - надо почитать, самообразование это полезно
  • открываем ваш любимый браузер - developer tools
  • открываем страницу, находим нужный элемент и делаем Copy - XPath
  • получаем что-то вроде /html/body/div[3]/section/div[1]/div/div[1]/div[2]/a[2] , к текущему моменту, если вы читали первый пункт, вы уже понимаете что это путь к элементу страницу. Таким образом скрипт будет знать где на странице находится нужный вам элемент. Вам нужен конечно не сам элемент, а его значение например /html/body/div[3]/section/div[1]/div/div[1]/div[2]/a[2]/@href если это ссылка или @src если картинка и тп
  • добавляем как паттерн url|flv_url|flt_thumb_url , отмечая те поля в которых надо вытянуть Xpath как XPath:/…. в нашем варианте получается что-то вроде
http://tube/gallery.html|XPath://html/body/div[3]/section/div[1]/div/div[1]/div[2]/a[2]/@href|XPath://html/head/meta[5]/@content

если вставить эту строку в импорт появиться кнопка Test Xpath. Если на нее нажать, то скрипт вытянет урл галеры и вычислит указанные поля. Это надо для проверки того, что вы верно прописали xpath.

Таким образом можно добавить сколько угодно урлов вида

  
http://tubesite.com/gallery.html|XPath://html/body/div[3]/section/div[1]/div/div[1]/div[2]/a[2]/@href|XPath://html/head/meta[5]/@content
http://tubesite.com/gallery222.html|XPath://html/body/div[3]/section/div[1]/div/div[1]/div[2]/a[2]/@href|XPath://html/head/meta[5]/@content
http://tubesite.com/gallery333.html|XPath://html/body/div[3]/section/div[1]/div/div[1]/div[2]/a[2]/@href|XPath://html/head/meta[5]/@content

и таким образом галеры будут добавлены. Но это конечно не очень красиво. Поэтому можно добавить Import Replacements где

url contains = tubesite.com
replace FLV Url = XPath://html/body/div[3]/section/div[1]/div/div[1]/div[2]/a[2]/@href

Таким образом можно будет импортировать просто http://tubesite.com/gallery.html а скрипт уже будет заменять для этого сайта нужные поля при импорте.

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

Вариант 4: ааааа, все сложно, я ничего не хочу читать и разбираться

Если вы не хотите делать самостоятельно вы всегда можете заплатить и работу сделают за вас. Сделать гейт или скопировать xpath в браузере сможет любой школьник. Если не хотите обращаться к школьникам - обращайтесь к суппорту с конретными сайтами. Ориентировочная цена - $100 за сайт.

Lazy load, load on scroll, pinterest and so on

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

Выглядит это так: условно темплейт index в котором 50 тумб

<thumb num=1-50>
<a href='/...'><img src='<!--THUMB_URL-->'></a>
</thumb>

В темплейт мы добавляем например jquery.wookmark (не единственный вариант конечно) как на http://demo.smartcj.com/scroll/

по достижении конца страницы он должен подгрузить дополнительный контент, для этого мы указываем откуда

var P_BASE = '/?force_template=index_scroll_ajax&page=';

как видно подгружается темплейт index_scroll_ajax и указывается &page=.. Каждый раз по достижении конца страницы jquery.wookmark будет подгружать этот урл меняя номер страницы

Темплейт index_scroll_ajax где мы выводим по 10 тумб

<thumb num=1-10>
<a href='/...'><img src='<!--THUMB_URL-->'></a>
</thumb>

Duplicate test thumbs

Проблема проявляется на базе где еще тумбы вообще не набрали цтр\показы: открываем страницу 1, после этого страницу 2 (той же выборки) и видим повторяющиеся тумбы. Происходит следующее:

Например у нас на странице 3 позиции для тумб (упрощаем для примера), а тумб всего 9, те на 3 страницы. тестовая позиция -1 на страницу, 1 тестовая 2 отротированных тумбы. На странице 1: берем 2 тумбы по цтр, тк у всех цтр 0 получаются тумбы 1 и 2. Берем первую тестовую - 3. Получается 1 2 3.

Страница 2 - берем со сдвигом на страницу , те следующие 3 по цтр, но опять же тк цтр не то это получаются 4 5 подряд. И теперь надо одна тестовая - смотрим с самого начала , а у тумбы 1 нет показов, она тестовая еще. Получается 4 5 1. Отсюда и повтор.

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

Fast Navigation

Если у вас большая база то имеет смысл заменить <pagination> на просто <!–PREV_PAGE–> <!–NEXT_PAGE–>

Разница в том, что если у нас есть навигация, нам надо сначала посчитать сколько всего галер по конкретному запросу, это определнная нагрузка на базу.

Если же у нас только ссылки на следующую\предыдущую страницы то ничего считать не надо в базе.

Обратите внимание, что в этом случае таг total_items будет показывать просто кол-во галер на текущей странице.

User Thumbs

Допустим у вас в импорте много тумб, но трафа что бы их отротировать все недостаточно (так бывает в большинстве случаев). Но хотелось бы оставить все тумбы для ролинга тумб. Для этого в импорте есть вариант с User Thumbs - смысл его в том, что указанные тумбы скачиваются, применяется кроп профайл, но в базе их нет, они сохраняются только на диске в каталог /scj/thumbs/user_thumbs/.

Те мы можем импортить как URL|THUMB_URL|USER_THUMBS

Есть ньюанс - если в импорте нет возможности сделать 2 поля в тумбами, то можно импортить просто как URL|USER_THUMBS и How Many Thumbs from each gallery ?= Х. Таким образом все тумбы из этого поля будут сохранены на диск, а Х тумб будут добавлены в базу для ротации.

Таким образом база не растет и не надо ротировать лишние тумбы.

При этом надо понимать, что скрипт ничего не знает про тумбы которые сохранены в user_thumbs, поэтому для роллинга тумб у вас есть 2 варианта. Либо для каждой галеры кол-во тумб должно быть одинаковым, либо при роллинге скрипт должен делать preload тумб для роллинга и таким образом понимать сколько их там всего.

В темплейте урл к каталогу с юзер тумбами для данной галеры можно получить тагом

<!--USER_THUMBS_FOLDER-->

Filter request parameters

Например, у вас сайт на английском и есть форма поиска, куда люди вписывают поисковые запросы на сайте. Лог поисковых запросов выводится где-то на сайте. Часть людей пытаются искать например на русском и это выводится в логах запросов, а вы не хотели бы что б бы это было видно. Можно неугодные символы фильтровать на этапе запроса.

Добавляем в common.php

if (isset($_GET['search'])) $_GET['search'] = preg_replace('|[^a-z,0-9,\s]|is','',$_GET['search']);

и это будут только латинские символы

Так же есть опция “Log empty search queries ” и если по запросу ничео не найдено то логгить его не будет.

Multiniche trade

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

Входящий редирект на нишевую страницу - скрипт может редиректить траффик с трейдера сразу нужную нишу у вас на сайте (redirects).

Отправка клика на нишемвую страницу трейдера - если трейдер не можетавтоматически редиректить ваши хиты на нужную старницу, можно самостоятельно настроить такой редирект, хотя это несоклько сложнее, чем просто включить опцию. Для начала надо, что б при клике скрипт понимал с какой группой он имеет дело, те добавить к ауте &group=… . Тут 2 варианта:

  1. редактируем темпелйты и делаем линки вида /gallery/asd/index.html?12x12x1234&group=ИМЯ ГРУППЫ (подставляя соотв таг в каждом из темпелйтов)
  2. либо включить опцию (trade_by_groups) и определять группу по реферу

далее в настройках каждого терйдера можно задать Special Urls для каждой группы. Те если для группы А у трейдера указан урл http://trader/a/ и в параметрах аута определило что текущая группа А, то к трейдеру пошлет не на http://trader/, а на http://trader/a/

Note про что забывают при разборе этих функций

Трейдер 1 в группе А, однако я вижу в рефах трейдера 1 рефы с моего сайта с категории B - трейдит не по группам ! Обычно топ трейдеров составляется общий, а не по группам и этот топ инклудится на всех страницах сайта. Те на странице B так же будет топ ВСЕХ трейдеров, даже тех которые могут быть только в группе A. Toplist

Кроме этого если в группе A например 2 трейдера, серфер побывал на обоих, то при сл клике его будет слать на всех трейдеров. Те если в группе нет активных трейдеров, на которых серфер не был - шлет на всех.

Performance

Ротация предполагает наличие большого кол-ва страниц.

Вот обычная ситуация: у вас 200к галер в 300 категорий, пусть в среднем по 7 страниц в категории, 3 варианта сортировка (ctr, data, duration) = 6300 возможных страниц + 200 000 страниц самих галер.

Понятно, что создавать по крону такое кол-во страниц как статику - бессмысленно, поэтому страницы создаются динамически и кешируются. Время кеша вы выставляете в конфиге. Чем меньше время кеша - тем больше страниц каждую секунду надо создавать скрипту. Те вы напрямую влияете на нагрузку на сервер.

Кроме этого есть тн “разогрев” сайта. Например, вы только все собрали и собираетесь пускать траф. Если влить сразу много трафа, например сразу же форсировать туда 5к - это 5к разойдутся по всем страницам и скрипту надо будет быстро создать все эти страницы, потому что вы только что собрали сайт и кеша на многие страницы нет. Поэтому при разгоне нового сайта дабы избежать излишней нагрузки на сервак важно разгонять понемногу. Те сначала например слить 1-2к за час, за это время будет создан кеш по осн страницам, а потом уже можно лить сколько надо.

Сколько сервак выдержит трафа: после того как создан кеш страницы отдаются условно мгновенно. Выглядит это так: 1 человек пришел на новый сайт на индекс, мы создали индексную страницу и положили ее в кеш на время указанное вами в конфиге. Все остальные посетители получат эту страницу из кеша практически не нагружаяя сервак. Даже если на эту страницу придет 1М пользователей за время кеша - они без проблем получат страницу.

Те если у нас условно 1 сайт то скажем 50к или 500к трафа - не имеет значения, потому что все равно нам надо создать практически одно и тоже кол-во страниц как для 50к, так и для 500к.

Но если у вас 50 сайтов по 10к трафа - по нагрузке это не одно и тоже что 1 сайт на 500к, потому что для 50 сайтов надо создать в 50 раз больше страниц, чем для одного (при одинаковых размерах базы, кол-ве категорий и тп).

Так же прямым образом влияет размер базы на нагрузку: если у вас 100к в базе то в зависимости от дизайна это будет пусть тех же 3000 страниц, 200к - 6000 страниц.

Переводы и слейв сайты: технически это как еще 1 сайт, тк что перевод, что слейв это другие описания или дизайн и тп, одним словом надо пересоздавать страницу. Есть одно “но” чем они немного отличаются от просто 2го сайта. 2 полностью разных сайта по 100к галер, это не тоже самое что мастер 100к галер + слейв, тк часть инфы у них совпадает, следовательно база может какую-то часть кешировать = меньше нагрузки.

Ответить на вопрос “сколько трафа выдержит сервак с конфигом Х” невозможно тк не ясно сколько это сайтов, какой диз и тд и тп., выясняется только опытным путем. Конечно, мы прилагаем все усилия что бы максимально оптимизировать скорость работы скрипта.

Тут стоит помнить о том, что сервак перегружается лавинообразно. Это значит что не будет такого что работает например сервак на 100% нагруженный и просто все начало немного тормозить. В какой-то момент запросы накапливаются и сервак падает. Проще всего это представить как вы раскручиваете двигатель машины, вот на 20% он работает, вот в красной зоне, работает во всю, а потом, если добавить еще, но не мощность падает от перегрузки, а двигатель клинит и он не работает совсем. Поэтому мониторинг серваков это важно.

Performance Log

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

Performance Log Writes performance info into logs/perfomance.log Adds some load at HDD as it writes each hit.

При включении он пишет в logs/perfomance.log, те создает небольшую доп нагрузку, поэтому без надобности оставлять включенным не стоит. Однако на какое-то время его можно включить что бы проверить текущее состояние.

Основной плюс в том, что позже в Maintenance -Logs вы можете посмотреть этот лог и скрипт автоматически сгруппирует показатели что бы вы могли видеть общую статистику, а не просто много текста. Названия полей там меняются по мере того, как дописывается этот лог, но в 99% случаев не составляет проблем понять что значит каждая запись. Если что-то не ясно - всегда можно спросить на форуме.

Custom gallery URL Refresh

Классический урл выглядит примерно как http://domain/gallery/asd.html что через реврайт получается как out.php?url=content&slug=asd, при этом скиминг берется из дефолтного или может быть задан в реврайте, главное что при рефреше страницы галеры может средиректить на трейдера.

Автоматически избежать этого невозможно тк рефреш - это когда браузер посылает точно такой же запрос и отличить на стороне скрипта никак нельзя.

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

https://stackoverflow.com/questions/18457797/how-to-know-whether-refresh-button-or-browser-back-button-is-clicked-in-firefox

вместо alert(“refresh button is clicked”); можно поставить свой код который будет редиректить например на http://domain/gallery_PERMANENT/asd.html , а в реврайтах добавить gallery_PERMANENT который будет делать урл с &p=100

Site Internationalisation (i18n)

Перевод сайта на другие языки.

Довольно просто сделать перевод меню сайта (те ссылок типа Most Popular, Order By date и прочее) на другие языки. Например у нас есть фраза “Самые популярные”. И несколько языков для которых эту фразу надо переводить.

Rotation - CMS - TPL Custom Vars создаем переменную most_popular, ее можно будет использовать в темплейте как <!–CUSTOM_VAR_MOST_POPULAR–> (это подписано прямо с созданной переменной). Там же можно указать перевод для языковых слейвов.

Case Sensitive URLs

По стандарту урлы - case sensitive, те большая или маленькая буква - имеет значение. Однако, большинство людей почему-то считает, что нет, поэтому урлы в базу попадают в разных вариантах, при этом возникают вопросы “почему я ищу http://domain/aaa и не находит? когда в базе запись http://domain/AAA. Что бы избежать этого по умолчанию в базе поле урла - case insensitive что б не было вопросов с поиском.

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

ALTER TABLE `rot_gallery_info` CHANGE `url` `url` VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL; 
ALTER TABLE `rot_gallery_info` CHANGE `source_url` `source_url` VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL; 

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

How to move thumbs

По умолчанию тумбы сохраняются в /scj/thumbs. Если вы хотите сменить место хранения тумб после того как добавили контент то надо

  1. физически переместить тумбы из scj/thumb в новое место
  2. сменить URL to thumbs в CJ settings - grabber settings

Full page cache

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

<thumb num=1-2>
<!--THUMB_URL--> 
</thumb>

<?php
echo "date: " . date("Y-m-d");
?>

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

/thumbs/img1.jpg
/thumbs/img2.jpg

<?php
echo "date: " . date("Y-m-d");
?>

при этом пхп код кешится в исходном виде. Те для каждого серфера этот пхп код будет выполняться.

В большинстве случаев это мелочи по нагрузке, однако при большом трафе, когда надо снизить нагрузку на проц, можно кешировать и пхп код, те страница будет закешена уже с выполненном виде, например

/thumbs/img1.jpg
/thumbs/img2.jpg

date: 2023-01-01

В большинстве случаев - это ок, тк результат выполнения кода одинаковый для всех серферов.

Однако бывают редкие ситуации когда в темплейте есть код, который должен быть выполнен для каждого юзера тк зависит например от текущего IP пользователя. Для этого есть опция

$config['full_page_cache'] = true;

В этом случае в темплейте можно использовать таг

<php_code no_cache=true>
<?php
echo "user IP: " . $_SERVER['REMOTE_ADDR'];
?>
</php_code>   

и именно этот код не будет закеширован.

Например темплейт

<thumb num=1-2>
<!--THUMB_URL--> 
</thumb>

<?php
echo "Rand: " . rand(0, 100);
?>

<php_code no_cache=true>
<?php
echo "user IP: " . $_SERVER['REMOTE_ADDR'];
?>
</php_code>   

будет закешен как

/thumbs/img1.jpg
/thumbs/img2.jpg

Rand: 22  (тут надо обратить внимание что этот пхп код закешен в выполненном виде)

<?php
echo "user IP: " . $_SERVER['REMOTE_ADDR'];   

// а тут пхп код в исходном виде и будет выполнен для каждого серфера

?>

Надо что надо обратить внимание при изменении темплейта под full_page_cache. Например, у вас код

<?php
$img_src_hash = md5($_SERVER['REMOTE_ADDR']);
?>

<img_src='get_img.php?hash=<?=$img_src_hash?>'

some more HTML

закешировать полностью мы не можем тк этот код должен быть разным для каждого серфера. Что бы хэш не кешировало хочется сделать

<php_code no_cache=true>
<?php
$img_src_hash = md5($_SERVER['REMOTE_ADDR']);
?>
</php_code>   


<img_src='get_img.php?hash=<?=$img_src_hash?>'

some more HTML

однако тут надо обратить внимание на то, что get_img.php?hash=<?=$img_src_hash?> запишется в кеш уже в выполненном виде, условно get_img.php?hash=322jjJ!…. , те ту часть, где надо выводить оперативные данные так же надо переносить внутрь и код должен быть

<php_code no_cache=true>
<?php
$img_src_hash = md5($_SERVER['REMOTE_ADDR']);
?>

<img_src='get_img.php?hash=<?=$img_src_hash?>'

</php_code>   


some more HTML

Вероятные ошибки

Нельзя включать <php_code no_cache=true> в другой блок <php_code no_cache=true>. Например,

<php_code no_cache=true>
<?php
$img_src_hash = md5($_SERVER['REMOTE_ADDR']);
?>

some HTML

<php_code no_cache=true>

Another code

</php_code>   

more HTML


</php_code>   


some more HTML

В этом случае это очевидно, но может быть вариант

<php_code no_cache=true>
<?php
$img_src_hash = md5($_SERVER['REMOTE_ADDR']);
?>

</php_code>   


<!--INCLUDE_TEMPLATE... 

some more HTML

в том темплейте который вы инклудите - так же есть <php_code no_cache=true>

ru/new_rotation_faq.txt · Last modified: 2023/01/19 11:10 by admin