User Tools

Site Tools

Translations of this page:

ru:new_rotation_faq

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

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

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

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

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

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

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

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

и все, вы уже используете современную версию мемкеш. Вы можете это использовать даже с версией 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 минут
  • вы прибили кеш

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

  • до 46 была проблема при удалении большого кол-ва тумб, например у спонсора 10к тумб, вы удаляете спона, скрипт пыдается это удалить сразу, но не успевает - получается таймаут. Это усугубляется если надо удалить не просто тумбы, а кастом гали.
  • начиная с 46 тумбы удаляются по крону. Те когда вы жмете в админке “удалить” тумбы не удаляются мгновенно, а переходят в статус 'Marked for deletion', раз в 10 минут крон смотрит есть ли такие и удаляет
  • если надо удалить “прямо сейчас” - запускаем rot.php с параметром process_deleted=true
  • cd /PATH_TO_/scj/bin/; env HTTP_HOST=yourdomain.com php rot.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к загрузок страницы.

Изначально у 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 turn a slave into a master

  1. Делаем дамп базы мастера
  2. Отсоединяем нужный слейв от мастера
  3. Заливаем туда этот дамп из пункта 1
  4. Смотрим в rot_linked_db номер слейва, который мы отсоединяем(Х)
  5. Удаляем все rot_gallery_stats кроме данного номера
  6. Удаляем rot_gallery_stats, а rot_gallery_statsХ переименовываем в rot_gallery_stats
  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. Для этого и есть статус “Штфсешму” - это значит галера будет видна по прямому урлу, но тумбы этой галеры не будут в ротации. те попасть на нее можно будет только по прямому урлу. Этот статус можно выставить в импорт сете, который удаляет галереи.

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

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

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

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

Для версии 1.* рекомендуется следующий вариант:

Например у нас есть задача импортировать много тысяч галерей, достаточно много что бы они не влезали в просто импорт (например сервер не успевает пройти их все по таймауту или размер POST ограничен и тп.). В Import Set так же добавить большой нельзя тк импортсет предполагает видеть какие-то апдейты, а не 100 000 новых галер постоянно. Одна из причин ограничений в ImportSets в том и заключалась, что люди добавляли массу импортсетов по 100к галер, которыя парсились постоянно все 100к * соклько там было импортсетов таких , это все проверялось в базе и таким образом создавало нагрузку на сервак.

Дабы импортировать большой файл равномерно и хорошо для сервака надо:

  • Создать и залить на сервак файл cut.php следующего содержимого
<?php

error_reporting(E_ALL & ~E_NOTICE);

if (!$_GET['file']) die("\n You have to pass file=... parameter in URL");
if (!file_exists($_GET['file'])) die("\n File {$_GET['file']} does NOT exists. Check path. ");
if (!is_writeable($_GET['file'])) die("\n File {$_GET['file']} is NOT writeable. Set 666 permissions. ");

if (!file_exists('./tmp.file') or !is_writeable('./tmp.file')) die("\n File tmp.file does not exists OR is NOT writeable. Set 666 permissions. ");

echo passthru("head -n500 {$_GET['file']} ");
if (!$_GET['test']) exec("tail -n +500 {$_GET['file']} > tmp.file; cp tmp.file {$_GET['file']} ");
  • Залить туда же дамп и поставить 666 на этот файл
  • Залить туда же пустой файл tmp.file и так же 666 на него
  • Добавить ImportSet с урлом http://yourdomain/path_to/cut.php?file=имя_файла_дампа&test=true
  • Нажать Test и распределить поля как надо.
  • cut.php выдает по 500 строк из большого дампа и урезает файл на эти же 500 строк. Таким образом каждый раз когда импортсет будет запрашивать новые строки - он будет получать по 500 строк, равномерно добавляя их в базу.
  • Наличие &test=true надо дабы в момент теста файл не обрезался на 500 строк. После тестирования &test=true надо убрать из урла те урл станет http://yourdomain/path_to/cut.php?file=имя_файла_дампа

Все.

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

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_%D0%B2_%D1%82%D0%B5%D0%BC%D0%BF%D0%BB%D0%B5%D0%B9%D1%82%D0%B0%D1%85

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 в браузере сможет любой школьник. Если не хотите обращаться к школьникам - обращайтесь к суппорту с конретными сайтами. Ориентировочная цена - $40 за сайт.

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

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

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

Вот обычная ситуация: у вас 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 страниц.

И еще немного цифр: на данный момент максимальное что есть это на одном серваке 31 сайт с общим кол-вом галер 1.5М, соответствий галера - категория 5М, тумбы на этом же серваке, сервак отдает в пике 280мбит.

Site Internationalisation (i18n)

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

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

1. Делаем кастом темплейт например languages в котором будет код слов

<?php 
$my_keywords['en'] = array(
  'most_popular' => 'Most popular',
  'order_by_date' => 'Order By Date',
  и так далее
);
$my_keywords['ru'] = array(
  'most_popular' => 'Самые популярные',
  'order_by_date' => 'Сортировать по дате',
  и так далее
);

$my_keywords['de'] = array(
  'most_popular' => 'Populärste',
  'order_by_date' => 'Sortiert nach Datum',
  и так далее
);

и так далее сколько угодно языков

далее 2 варианта подставления языка: 

по языку браузера

if (strstr($_SERVER['HTTP_ACCEPT_LANGUAGE'], 'ru')) {
  $lang = $my_keywords['ru'];
} elseif (strstr($_SERVER['HTTP_ACCEPT_LANGUAGE'], 'de')) {
  $lang = $my_keywords['de'];
} else $lang = $my_keywords['en'];

или по geo_ip

if ($_SERVER['GEOIP_COUNTRY_CODE'] =='RU') {
  $lang = $my_keywords['ru'];
} elseif ($_SERVER['GEOIP_COUNTRY_CODE'] =='DE') {
  $lang = $my_keywords['de'];
} else $lang = $my_keywords['en'];


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

и в конце темпелйта

if ($_GET['force_lng'] and isset($my_keywords[$_GET['force_lng']])) {
  setcookie('force_lng', $_GET['force_lng'], time() + 86400);
  $lang = $my_keywords[$_GET['force_lng']];
} elseif ($_COOKIE['force_lng'] and isset($my_keywords[$_COOKIE['force_lng']])){
  $lang = $my_keywords[$_COOKIE['force_lng']];
} else $lang = $my_keywords['en'];

Все, конец темплейта :)

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

<!--INCLUDE_TEMPLATE_languages-->

3. В темпелейтах соответствующие слова заменяем на переменные, например

Most popular меняем на <?=$lang['most_popular']?>
Order By Date меняем на <?=$lang['order_by_date']?>
и так далее

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

4. даем юзеру возможность переключить язык “насильно”

для этого ставим линку вида

http://domain/?force_lng=de (и тп нужных язык в зависимости от массива ваших языков в $my_keywords['de'])

Все.

ru/new_rotation_faq.txt · Last modified: 2018/10/30 11:36 by admin