Стандартная практика - слать прямо на корень домена те

http://mycj.com/, 

скрипт берет домен трэйдера из рефера.

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

http://yourdomain.com/?id=trader.com

, где trader.com - это домен трейдера.

В сетингах есть понятие скиминга 101. Ясно что скимить больше 100% невозможно. 101 означает “скиминг равен дефолтному”. Дефолтный задается там же в сетингах. Те если дефолтный 60, а у норефа стоит 101 - значит у норефа будет так же 60 скиминг. А вот если поставить что то отличное от 101 - уже будет свой, персональный.

В скиминге можно указывать дополнительные параметры в виде skim#options, где options это var=value&var2=value=2 и так далее. В данный момент это сделано для Tube switch rules но может пригодится и в будущем.

Если у вас включен tube_embeded_switch_rules то первый клик должен уходить на спонсора. Это удобно, но если серфер пришел к вам напрямую с поисковика, то вам хотелось бы оставить его себе. Или например если ссылка на галеру у вас находится на другом сайте и переход оттуда - вам так же хотелось бы оставить у себя на сайте. те для определенных случаев вам хотелось бы выключить опцию tube_embeded_switch_rules. Для этого указываем ским например

100#tube_embed_switch_rules=off

В этом случае будет 100% на контент, tube_embed_switch_rules=off - переход на спонсора выключен.

Если вам надо что бы правило действовало только на первый клик, то можно указать ским как

100#tube_embed_switch_rules=off,100

те tube_embed_switch_rules выключен только для первого клика.

По умолчанию Ским указанный в урле имеет приоритет над всеми остальными вариантами. Если ским в урле не указан - проверяются персональные сетинги трейдеров. Если и тут ским не указан - используется дефолтный ским из сетингов.(CJSettings - Content Settings - Default skimming)

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

Можно выставить ским на каждый клик. Например, 100,60 значит что первый клик будет ским 100, 2й клик - ским 60. Обратите внимание, что последняя цифра повторяется. Те 3, 4й и тп будут 60. Если надо иначе - надо перечислять столько раз, сколько надо, те 100,60,100,60,100,60,100,60 и тп

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

100,trader.com,60,sell,50

2й клик пойдет на трейдера, 4й на продажу

Так же можно указывать некоторые параметры например

100#skip_sell=true,50

тут надо обратить внимание на #skip_sell=true, те на первом клике продажи трафа не будет, даже если она настроена в traffic rules - traffic sell

Во всех урлах трейдеров, продажи трафа, редиректа и тп можно пользоваться переменными окружения, а именно $_GET и $_SERVER . Например, продажа трафа, у вас стоит урл http://broker.com/, вы хотите трекать продажу как то , можно сделать например http://broker.com/?from={SERVER_HTTP_HOST} и будет передавать имя текущего домена. Удобно при копировании настроек на другие домены.

Или например хотите передавать с какой страницы клик: out.php?url=http://gallery.com/?from={GET_slug} где slug - это переменная из урла страницы, на которой произошел клик.

Пример с реврайтом У вас урл http://domain/gallery/cool_gallery.html - это реврайт. Реальный урл - http://domain/scj/cgi/out.php?url=content&slug=cool_gallery (дальше могут быть еще параметры в зависимости от вашего реврайта), тут GET параметры url и slug.

Вы продаете траф на http://broker.com/, по каким-то причинам вы хотите передать брокеру slug. Для этого меняем урл брокера на http://broker.com/?broker_parameter_for_slug={GET_slug} при клике {GET_slug} будет заменен на cool_gallery и клик уйдет на урл http://broker.com/?broker_parameter_for_slug=cool_gallery

Показывает соотношение между кликами которые в реальности ушли на галеры к кликам которые ушли на трейд. Real Skimming может отличаться от установленного скиминга как в большую так и в меньшую сторону. Например, если у вас топ трейдеров - это 100% ским на трейдеров, соответственно если у вас например дефолтный ским 50 и есть топ трейдеров со скимом 100, то реальный ским будет например 40. Тоже самое актуально и в обратную сторону. Например если у вас на индексе тумбы категорий, по которым серфер 100% уходит на урл (в данном случа это страница соотв категории), то Real Skimming будет больше 50.

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

Что бы первый клик уходил всегда на контент надо поставить ским например 100,50 - это значит первый клик ским 100 2й и следующие - 50

базы находятся в scj/includes/config.php.

если вы покупаете траффик на подлив (например на трафикхолдер) то для проверки его качества добавьте условного трейдера podliv.com и сделайте его неактивным (Active - No). И после этого сливайте траффик с параметром /?id=podliv.com.

Многие покупают траф для подлива, часто методом подбора - сегодня купили этого немного, сегодня этого немного.

Есть хороший вариант небольшой автоматизации данного процесса. Покупайте траф БЕЗ id=, те просто шлите на http://your_domain.com/

В Settings - Processed Data - Add Notrade as Inactive Traders

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

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

Восстановить пароль никак, можно только поменять, для этого надо сделать следующее:

Вариант 1, если у вас обычная авторизация, те вы не жали на “Switch to multiaccess” в Setting - Password

1. переименовать /scj/admin/.htaccess в /scj/admin/htaccess
2. открыть админку (сейчас у вас не будет спрашивать пароль)
3. поменять пароль
4. переименовать /scj/admin/htaccess обратно в /scj/admin/.htaccess

Это если у вас апач. Если nginx то он не читает .htaccess, все прописано в конфиге nginx. Вы можете либо переписать .htpasswd с того сайта где знаете пароль, либо временно убрать авторизацию в nginx (попросите админа это сделать если не знаете как), выставить новый пароль и снова включить авторизацию в nginx.

Вариант 2, если жали на “Switch to multiaccess ”

1. в каталоге /scj/admin/ создать файл reset.php следующего содержания

2.  <?php
   require('../includes/prepare.php');
   db_query("update admins set password = MD5('admin') where login = 'admin' ");
   echo 'Done'; 

3. открыть в браузере /scj/admin/reset.php
4. удалить reset.php

Ошибки Вы нажали на “Switch to multiaccess”, переименовали .htaccess - теперь не проходит пароль никакой.

тут 2 варианта.

1. Каталог закрыт например nginx и пароль стоит там.

Проверка - открываем /scj/admin/test.php - если спрашивает пароль - значит оно.

Решение - просите админа убрать эту авторизацию.

2. Хост работает через php_fpm

Проверка - делаем файл scj/admin/123.php следующего содержания

<?
   if (isset($_SERVER['PHP_AUTH_USER'])) {
      print_r($_SERVER);
   } else {
   
      header('WWW-Authenticate: Basic realm="SmartCJ Admin area."');
      header('HTTP/1.0 401 Unauthorized');
      echo 'Access Restricted';
      exit;

   }

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

Решение: http://smartcj.com/wiki/doku.php?id=ru:password#php-fpm_castcgi_multiaccess_problem

Либо отключить мультиавторизацию

1. в каталоге /scj/admin/ создать файл reset.php следующего содержания

2.  <?php
   require('../includes/prepare.php');
   db_query("update settings set value = '' where name = 'scj_admin_auth' ");
   echo 'Done'; 

3. открыть в браузере /scj/admin/reset.php
4. удалить reset.php

Что бы сделать ресет списка надо:

1. в каталоге /scj/admin/ создать файл reset.php следующего содержания

2.  <?php
   require('../includes/prepare.php');
   db_query("UPDATE settings SET value = '' WHERE name = 'admin_limit_ip' ");
   echo 'Done'; 

3. открыть в браузере /scj/admin/reset.php
4. удалить reset.php

A. добавть трейдера, сделать его активным, выставить ratio = 0, Eliglible for exout hits = No

A. Maintanance → Import Traders : есть импорт из наиболее популярных скриптов, если из вашего нет - дайте мне знать, добавим.

A. Теоретически это % серферов трейдера, которые добавили ваш сайт в букмарки. Считаем сл. образом: когда приходит серфер мы ему ставим куку на неделю со значением трейдера. Если серфер приходит _без_рефа_ и у него стоит эта кука, мы предполагаем что при предыдущем визите он добавил нас в букмарки.

Для простых линков на галеры или внутренние страницы сайта:

Допустим у нас есть следующий линк

<a href="/somepage.html">Link Desc</a>

мы добавляем небольшой JS в страницу

<script type=“text/javascript”>

function scj_click(out_param, url) {
	var a = new Image;
	a.src="out.php?"+out_param+"="+url;
	return true;
}
</script>

а в саму линку добавляем следующий код

<a href="/somepage.html" onClick="return scj_click('url', this.href);">Link Desc</a>

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

<a href="http://trader.com/" onClick="return scj_click('member', 'trader.com');">Link Desc</a>
где trader.com - это домен трейдера.

Надо зайти в шел (ssh) и дать сл команду

mysqldump -uLOGIN -pPASS DBNAME > dump.sql

где LOGIN, PASS and DBNAME соотв. ваши данные доступа к мускл. После этого, дабы было меньше скачивать, можно упаковать полученный файл.

gzip dump.sql

Загрузить бекап

mysql -uLOGIN -pPASS DBNAME < dump.sql  

Проще всего :

1. проапдейтить на старом серваке до последнего апа
2. поставить с 0 на новом
3. перенести дамп мускл
4. скопировать сами тумбы

Если вам все же нравится копирование, то

1. скопировать с пермишенами
2. проверить пути и пароли в scj/admin/.htaccess, common.php, includes/config.php

Master - Slave

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

keywords: перенос скрипта

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

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

• includes/config.php
• все common.php
• admin/.htaccess
• rewrites - если у вас Apache то htaccess, если nginx то в его конфиге

Тестовое решение для фильтрации читового трафа при продаже. Фильтруем по наличию JS и загрузке картинок. Если JS нет - будем слать 100% на урл (гали).

1. Настраиваем User Vars “Определить % серферов без JS и картинок”, user.php ставит куку user_var (можно сделать другой вариант)
2. CJ Settings - other settings - Traffic Check : Cheat Hit - cookie doesnt exists - пишем user_var. Теперь, если у юзера не сработал JS в п.1 , значит не будет куки, если нет куки - считаем как чит клик
3. В сетингах Sys. Traders - cheat_clicks - ставим персональный ским 100 - значит все читклики всегда на гали
4. Traffic Sell ставим продажу _только_ с trade кликов. Учитывая что продажа будет только с трейд кликов - на трейд станет уходить немного меньше хитов, возможно надо будет уменьшить общий ским.

Если вам дают список ИП с читом, а вы не можете найти их - скорее всего причина в том, что по дефолту скрипт хранит данные за последние 24 часа. Это время можно увеличить в сетингах Keep Links, hours

Например, у нас есть страницы niche_page1.html and niche_page2.html, которые мы бы хотели ротировать только для определенных трейдеров. Делается это так:

• создаем файл например trader.php на корне домена

<?
$pages = array(
	'/usr/home/domain.com/niche_page1.html',
	'/usr/home/domain.com/niche_page2.html',
);

include($pages[rand(0, count($pages)-1)]);

• прописываем ПУТЬ (!!!) к trader.php как персональную страницу трейдера

Это 2 отдельные системы управления качеством траффика. Quality settings - это скидки для определенных стран. Например, клики для страны А считаются с дискаунтом 50%, это значит что 2 клика будут засчитаны как 1. Значит будет меньше прода, меньше задолженность, трейдер получит меньше возврат.

Trade by country - это возможность трейдеру слать теже страны (по качеству), что и он шлет нам.

Те если включены обе системы то трейдеру условно будет возвращать Китай да еще и меньше чем он нам прислал.

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

Да, безресетный топ это практический классический сидж. Для ресетных топов существует удобная фича для определения времени, когда надо форсить этот топ. В едит трейдера Other Settings - Site type надо выставить Toplist и скрипт будет проверять раз в сутки общее кол-во хитов на топе с целью определить время ресета. Все замеченные ресеты пишутся там же в едит, а так же видны в trade когда вы наводите мышь на домен трейдера (в попапе).

Вебинсталл: Обычно взломы происходят с веба через скрипты где не проводится проверка входных данных. При этом обычно делают вебшел - заливают скрипт в каталог, в который может писать вебсервер. Вебсервер обычно может писать в каталог, который имеет овнера сам вебсервер либо пермишены на запись (0777). Если скрипт ставится с веба все файлы и каталоги получают овнера = вебсервер. Минус этого в том, что если где-то сломают то мало того что шел могут положить в любой каталог скрипта, так еще и могут подменить out.php например и забирать часть трафа себе, а владелец сайта об этом не будет и подозревать. Если ставить скрипт из шела, то файлы и каталоги получают овнера = юзер и соответственно с веба их изменить нельзя.

Апдейты и рут: попытка нести хорошее в люди :) Если вы спросите у любого админа он вам скажет, что правильное поведение - никогда не ходить на сервак от рута. Ходят от юзера всегда, если надо пермишены рута делают su (sudo). Чем это плохо в конкретном нашем случае: если скрипт становится от рута, а крон от юзера - крон не сможет менять файлы (тк овнер рут). Если поставлено от рута и крон от рута, то все работает хорошо. Но тут есть проблема: если в скрипте найдут дырку, а от этого никто не застрахован, злоумышленник получит в руки скрипт, который запускается от рута, а значит сможет внедрить руткит - программа которая позволит управлять вообще всем серваком так, что не будет заметно не только самому овнеру сервака, но и зачастую админу.

Ин\аут не работают с базой, дабы нагрузка на мускл никак не отражалась на трейде, и каждую минуту крон обрабатывает клики за минуту и кладет их в базу, обсчитывает трейдеров и прочее.

Крон можно запускать как угодно редко, хоть раз в день При запуске крон делает следующее:

• расчитывает приоритеты трейдеров ( те если раз в день то будет расчет раз в день и тд)
• за 1 запуск создается тумба для 1 трейдера
• создается топлист трейдеров

В целом ничего необратимого не происходит, можно ставить как угодно, если что-то не будет работать - можно написать в суппорт или просто поставить чаще крон.

Вопрос из разряда “сколько коробочек влезет в машину?” это на 100% зависит от веса коробочек, их размера и желания максимально оптимально их там распихивать.

Например, сайт это и 1 индексная страница, которую можно закешить и отдавать с огромной скоростью

10М галер в базе с 3 вида сортировки , 500 категорий, 100к тагов, поиск фильтрация, 10 кастом переменных и тп - это тоже 1 сайт.

Оставить поиск на mysql - одна нагрузка, не лениться настроить сфинкс - другая нагрузка и тд.

Скрипт делает бекап автоматически раз в сутки, сохраняет последние 3 дня и удаляет старые.

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

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

Из общий рекомендаций: 1. ставить бекап на время когда нагрузка наименьшая 2. делать бекапы по очереди, что бы в один момент времени работал только 1 mysqldump 3. делать бекап физически на другой винт относительно того где находятся сами базы.

У notrade может быть очень высокая прода, те много кликов при малом количестве инов.

Вопрос заключается в том, что часто в notrade клики попадают хиты сделанные через переводчик гугла. Ситуация получается примрено следующая:

• юзер пришел от от трейдера, мы запомнили что условно ИП 123.123.123.123 от трейдера asd.com
• на индексе (или категории, в целом не важно) браузер у юзера видит что сайт на английском, при этом юзер например из Индии, и предлагает начать переводить сайт
• юзер соглашается - с этого момента весь траффик начинает приходить с googleusercontent.com и IP гугла

Как тут видно в этот момент мы получаем 2 проблемы:

1. notrade показывает нереальную продуктивность
2. появляется ошибка в проде трейдеров

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

Что бы этого избежать надо в код добавить

<meta name="google" value="notranslate">

Судя по документации гугла это должно помочь.

Как считать траффик от фидеров:

1. самый простой варинат - создаем трейдера условно feeder.com и шлем как http://domain.com/?id=feeder.com? вся стат по траффику видна у трейдера feeder.com

2. Траф приходит из разных источников и они меняются. Такой траффик по дефолту считается в notrade. Но можно его автоматически делить. В сеттингах “Add Notrade as Inactive Feeder Traders” и каждый домен будет добавлен как новый фидер.

Тут есть 2 варианта:

- as separate trader - каждый будет как отдельный трейдер, но тогда в основном экране trade появиться очнеь много трейдеров и это уже не особенно удобно - as subfeeder - тут надо слать http://domain.com/?id=feeder.com (feeder.com надо предварительно создать), тогда все рефы со своей стат будут видно в статистике feeder.com как subfeeders

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

Например, траф приходит как http://domain.com/?site_id=12345

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

if (isset($_GET['site_id'])) {
   $_SERVER['HTTP_REFERER'] = 'http://feeder-' . $_GET['site_id'] . '.com/';
}

те реф в этом случае будет http://feeder_12345.com/ и легко понять откуда этот траффик. При этом если в урле больше параметров то реф можно сформировать так, что бы учесть эти все параметры, условно

$_SERVER['HTTP_REFERER'] = 'http://feeder-' . $_GET['site_id'] . '-' .  $_GET['some_other_parameter'] . '.com/';

создав такой реф, что б по нему было ясно откуда пришел траффик

Есть интересный вариант проверки качества трафа с использованием речапчи от гугла. Суть в том, что гугл пишет какой % трафа он считает нормальным, не ботовым.

1. Идем на https://developers.google.com/recaptcha, регаемся и получаем Recaptcha V3 Site key Recaptcha V3 Secret key

2. вписываем эти значения в Rotation - Settings - Social

3. на любой странице, но в 99% это конечно будет индекс и страница категории добавляем код

<script src="https://code.jquery.com/jquery-3.4.1.min.js"></script>
<script src="https://www.google.com/recaptcha/api.js?render=<!--TUBE_RECAPTCHA_SITE_KEY-->"></script>

<script>
req_flag = false;
recaptcha_code = '';


if ('<!--RECAPTCHA_MAX_RATE-->') {
    if (Math.random() > '<!--RECAPTCHA_MAX_RATE-->') req_flag = true;
}


grecaptcha.ready(function() {
    grecaptcha.execute('<!--TUBE_RECAPTCHA_SITE_KEY-->', {action: 'index_page'}).then(function(token) {
       recaptcha_code = token;
    });
});


$(document).ready(function(){
	$('.gallery_link').each(function() {
		$(this).click(function(){
		    if (req_flag || recaptcha_code === '') return;
		    req_flag = true;

        	$.post('/',
	        {
                'action': 'check_recaptcha',
                'recaptcha_code': recaptcha_code,
    	    },
	        function (data) {
	  	        
	        }
	        );
		    
		});
	});


});



</script>

на линках на галеры или категории добавляем class='gallery_link' как в примере ниже

<thumb num=1-10>
<a class='gallery_link' href='/gallery/<!--GALLERY_SLUG-->/index.html'> <!--GALLERY_ID--> </a> <br>
</thumb>

можно конечно gallery_link заменить на что угодно, смысл в том что в JS мы вешаем событие по определению чита на эти линки $('.gallery_link').each(function() {

4. в админке идем в Settings - layouts - и включаем колонку Google Recaptcha

Все, теперь можно видеть процент хорошего трафа в Trade - колонка recaptcha

Одна из частых проблем - это непонимание (или невнимательность ?) разницы между УРЛом и Путем.

URL - это нечто вида http://domain.com/blabla/, те расположение файла в интернете.

PATH - это расположение файла на диске.

Рассмотрим простой пример: на диске сервера каталог с вашими доменами обычно находится примерно как /home/user/domain.com/. Допустим там же лежит файл 1.html. Путь к нему /home/user/domain.com/1.html УРЛ к этому же файлу http://domain.com/1.html

Периодически возникают вопросы по относительным и абсолютным путям. Относительный путь - это путь относительно текущего положения в системе, оно может менятся. Путь вида /home/user/domain.com/1.html (тут / в начале пути указывает на корень файловой системы) - это абсолютный путь, он не меняется.

Это выражается например в ротаторе, где для сорханения тумб 2 параметра: URL to data and PATH to data. Вы хотите что б были не в каталоге scj (урл до тумб получается http://domain/scj/thumbs/1/2.jpg) , а в /thumbs что б путь получался http://domain/thumbs/1/2.jpg У вас домен в /home/user/domain.com/.

• ПУТЬ к сохранению тумб - это /home/user/domain.com/thumbs/
• УРЛ - http://domain.com/thumbs или просто /thumbs

Первая ветка скрипта (1.X) больше не развивается и в 2016 году мы полностью перешли на ветку 2. Если у вас есть скрипт версии 1, то что бы перейти на версию 2 надо

1. поставить скрипт версии 2 на тот же домен (но в другую папку), где и версия 1 (понадобится отдельная база)
2. проапдейтить версию 1 до последней доступной версии
3. в шеле зайти в scj/bin и запустить php scj_1to2_db_converter.php

Скрипт спросит данные где расположена версия 1 и скопирует оттуда все данные.

Не забудьте, что если у вас есть свой код в common.php то его так же надо скопировать.

Из-за изменений в IonCube теперь для каждой версии пхп надо готовить отдельный файл, те написанное под 5й пхп не будет работать на 7м и тд.

Когда вы инсталите скрипт то он определяет какая у вас версия пхп и скачивает файлы под вашу версию. Если потом вы смените версию пхп то будет писать что скачанные файлы расчитаны на другую версию пхп (ту на которой был инсталл).

Суть что надо сделать: заменить все пхп файлы скрипта на файлы для нужной версии.

Варианты как это сделать:

1. самый простой:

• делаем бекап
• обновляем пхп
• ставим скрипт с 0, он скачивает файлы под нужную версию
• поднимаем бекап

2. для любителей копировать файлы

• ставим на 1 домен версию под нужную версию пхп
• копируем *.php файлы на остальные домены (кроме common.php and config.php)

3. если доменов много с трафом

• делаем 2 версии пхп, дефолтная - старая, условно 5
• ставим 7й пхп
• делаем копию доменов, но на 7м пхп, туда инсталлим все как было и переключаем на новую версию по доменно

Все данные хранятся в базе, поэтому

1. инсталлим скрипт на новый домен
2. копируем бекап на новый домен и восстанавливаем
3. Settings - CJ Pages меняем на актуальный путь

Все.

Пункт просто запускает команду optimize для базы, в большнстве случаев это имеет смысл для MyISAM таблиц, подробнее и официально можно прочесть по ссылке https://dev.mysql.com/doc/refman/8.0/en/optimize-table.html

Truncate удаляет все данные из таблицы.

Скрипт может собирать статистику по вашим трейдерам с SimilarWeb. Для этого надо получить бесплатно API key

• бесплатно регистрируемся на similarweb
• идем в меню Account - API - Generated Keys
• создаем новый ключ и вписываем его в Settings - Anticheat - Similarweb Api Key

1. В папку scj кладем .htaccess

RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^123\.255\.123\.255
RewriteCond %{REMOTE_ADDR} !^xxx\.xxx\.xxx\.xxx
RewriteRule ^(.*)$ - [L,R=404]

и оно будет выдавать всем, кроме указанных ИП - 404.

Если вы юзаете nginx - это прописывается в его конфиг.

Тут важно прописать сюда и ИП вашего серваке, иначе Global Admin не сможет собирать статистику.

2. Если тумбы у вас по дефолту были в scj/thumbs то надо либо физически их вынести в нужное вам место, либо сделать симлинку. Если вы знаете, что такое симлинка то без проблем сделаете самостоятельно, если не знаете, что это такое - лучше физически перенесите.

После этого надо что б скрипт был в курсе того, куда вы перенесли

- быстро: в базе в rot_galleries таблице поменять урл, если не знаете как в базе поменять, лучше вариант 2 - медленее - list thumbs - massedit - меняем часть урла тумб. Как обычно лишним не будет сделать бекап.

После этого в Rotation → Setting → Graber Settings есть поля: URL to data и PATH to data URL, соотво-но, меняем на /имя_новой_папки PATH - на /home/_path_to_domain/имя_новой_папки

Допустим у нас есть параметр

&url=http://gallery

но мы хотим как-то хитро зашифровать параметр. Для этого надо:

1. в темплейте у нас например

&url=/gallery/<!--GALLERY_SLUG-->/index.html

это надо заменить на

&url=<?=your_super_function('/gallery/<!--GALLERY_SLUG-->/index.html');?>

2. в результате ваша функция как-то зашифрует указанный текст и получится допустим

&url=sdfskldfkejhfklewhfklwerhfklwerhf

3. в коммон надо для скрипта расшифровать то что вы сделали, например

if (isset($_GET['url'])) $_GET['url'] = your_decode_function($_GET['url']);

Все.

В общей стат и стат каждого трейдера есть список урлов на которые приходит траф.

В этом в целом заключается вся раздача трафика.

Трейдеры получают приоритет по расчету Trade Formula. А так же по форсам (например 1 fast force прибавляет 10000 к приоритету что бы трейдер оказался выше по приоритету).

Крон раз в минуту расставляет трейдеров по приоритету в список outlist (settings - out settings). При каждом клике на аут мы пошлем на трейдера с соответствии с вероятностью в outlist.

Выводы которые надо понять:

1. если трейдер на первой позиции outlist (и по приоритету) - не факт что он получит первый же клик 2. если у вас в outlist 10 позиций, то в конкретную минуту хиты получают топ 10 трейдеров по приоритету 3. если вы поставили форсов больше чем позиций в листе, то они буду отданы по очереди, а не все сразу (и конечно форсов не должно быть больше чем трафика)

При перемещении по сайту можно следить на какие линки приходит траф, для этого добавляем в линк &page_track=..

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

• Включите в CJ Settings - Add debug comments, будет видна дополнительная информация про каждый клик.
• если надо протестировать правила для определенной страны в common.php для своего IP можно добавить

  if ($_SERVER['REMOTE_ADDR'] == 'your IP') {
     $_SERVER['GEOIP_COUNTRY_CODE'] = 'country_code!';
  }

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

Что можно отключить что б снизить нагрузку на сервер? Краткий ответ - отключить можно все. Все что вы можете отключить в админке - так же можно снова включить, если что-то будет не так.

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

Если есть желание смотреть дальше чем “мне админ сказал” и вы можете проверить базовые вещи на серваке, то имеет смысл читать дальше.

Нагрузку на сервер можно сравнить с ситуацией когда по одной трубе вода затекает в бассейн, а по другой уходит. Не бывает “нагрузка 120% но сервер держится!”. Либо поступает меньше воды, чем может уйти и все хорошо, либо бассейн начинает наполняться и через какое-то время переполнится. В зависимости от емкости бассейна можно какое-то время лить больше воды, чем уходит, но до определенного предела и условно если подавать 150% от пропускной способности трубы, то бассейн переполниться через минуту, а при 101% - через час.

Что такое переполнение бассейна, пример ближе к реальности:

На серваке работает apache (вебсервер), mysql и сервер отдает файлы (статику). 50% памяти - кеш статики 20% - апач 30% - mysql

Например, mysql может обрабатывать 100 запросов в минуту.

Если давать 110 то запросы будут становиться в очередь, в памяти будет выделяться место где хранить данные запроса. Из-за этого mysql займет например 60% памяти, а для статики останется 20%. Из-за того что статика не кешится - сервер начинает больше читать с диска, занимая производительность диска. Из-за этого mysql, который так же работает с диском, падает по производительности с 100 до 90 запросов, получается очередь формируется уже с превышением не 10%, а грубо 20% (90 сейчас максимальная, а мы все так же даем 110).

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

Поэтому “все было хорошо, а только добавил всего чуть чуть” - приводит не к тому что все “чуть чуть медленее работает из-за перегруза”, а перегруз приводит к падению всего (резкой деградации производительности всего)

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

Базово скрипт состоит из 2х частей

1. вебчасть, которая формирует страницы сайта доставая инфу из базы
2. то что выполняется по crontab (раз в минуту или реже)

Начнем с веб части.

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

1. Процессор: если в топе по нагрузке висит вебсервер (условно апач, nginx, php-fcgi and so on), те все что формирует страницу сайта и показывает ее серферу, то скорее всего у вас есть что-то тяжелое в темплейте. how_it_works

Кратко: темплейт обрабатывается в 2 шага. Сначала заменяются таги скрипта, на актуальные данные, условно <!–ALT–> заменяется на актуальный текст. Потом выполняется темплейт как пхп что б выполнить ваш пхп код.

После шага 1 темплейт кешится what_is_cache, это значит что если в темплейте нет пхп кода, а есть условно только <!–ALT–> то при запросе той же страницы сервер сразу достанет готовый html из кеша. Это очень быстро.

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

mysql: если в топе mysql, то вероятно не оптимизирован какой-то из запросов. Из того что есть тияжелое в скрипте: это максосы <thumb order=rand потому что rand - очень тяжелая операция для mysql (в скрипте есть easy_rand который немного решает проблему)

Либо поиск: mysql ищет намного медленее чем sphinx (надо переходить на mysql fulltext or sphinx)

В целом надо зайти в mysql и проверить какие запросы висят в топе, может быть там есть rand() или like % - тогда это случаи выше. Если этого нет, то обращайтесь - будем смотреть плотнее, надо сразу mysql root and ssh access.

2. Память и Диск - связаны, что и логично: если вам надо отдавать файл header.jpg на каждый запрос, то вы его либо кешируете в памяти и отдаете вообще не обращаясь к диску, либо каждый раз читаете с диска. Чтение с диска примерно в 1000 раз сложнее.

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

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

Если траф приходит только на главную страницу, то нам важно загрузить в память html + всю статику этой страницы, что б отдавать сразу не обращаясь к диску. Если приходит на все 100 галер, то важно держать базу в памяти, что б формировать страницы не обращаясь к диску.

Например, вы выбрали загрузить всю базу в память, но у вас траф приходит только на пару страниц. Из-за базы не хватает памяти кешить статику = вебсервер (апач nignx) постоянно читают с диска, и сайт открывается, но медленно грузится.

Понятно что эти параметры не переключаются из скрипта. Тут как обычно есть 2 варианта: либо вы тратите время что б разобраться в своей ситуации и настроить оптимально сколько mysql может занять памяти, либо заливаете проблему деньгами, те просто берете сервак где больше памяти и все влезает в память.

2. crontab

По крону (те периодически) скрипт делает несколько действий:

• cron.php - пересчитывает статистику трейдеров (кому сколько должен, приоритеты), делает тумбы трейдеров, бекапы, отключает включает трейдеров и тп.
• rotation.php - апдейтит статистику тумб в базе
• gallery_grabber & gallery_checker - грубит тумбы и проверяет что галеры доступны.

Можно ли их запускать не каждую минуту - можно хоть раз в день, но логично что если вы запустите rotation.php раз в день то весь день тумбы будут в том же положении на странице. cron.php - приоритеты трейдеров поменяются 1 раз и тп.

Из всего этого следует вопрос: сколько сайтов потянет сервер такой-то … ? Это вопрос из разряда “сколько коробочек влезет в машину?” это на 100% зависит от веса коробочек, их размера и желания максимально оптимально их там распихивать.

Как работает кеширование в интернет

+------------------+
|  Пользователь   |
+------------------+
         |
         v
+------------------+
|     Браузер     |
+------------------+
         |
         |  
         v
+----------------------------------+
|        Кэш браузера              | если тут закеширвоать страницу то ни сервер 
+----------------------------------+ ни скрипт никогда не узнают что 
         |                           пользователь открывал URL  
         v
+----------------------------------+
|        CDN                       | Аналогично и тут, запрос еще не дошел до сервера
+----------------------------------+
         |
         |  
         v
+----------------------------------+
|     Веб-сервер                   |
|   (Apache / Nginx)               |   Веб-сервер может закешировать страницу полностью 
+----------------------------------+   и скрипт не узнает что было  обращение к странице
         |        \
         |         \ обращение
         |          v
         |   +--------------------+
         |   |  Серверный кэш     |
         |   | (файлы / Redis)   |
         |   +--------------------+
         |
         |  
         v
+----------------------------------+
|     Скрипт / Приложение          |  тут скрипт уже знает что было обращение 
+----------------------------------+
         |        \
         |         \ обращение
         |          v
         |   +--------------------+
         |   |   Кэш данных       |
         |   | Redis \ memcache   |
         |   +--------------------+
         |
         v
+------------------+
|   База данных    |
+------------------+

Как браузер получает страницу и где в интернете появляется кэш

Когда пользователь вводит адрес сайта в браузере, кажется, что браузер «просто идёт на сервер и получает страницу». На самом деле браузер старается не ходить на сервер, если это возможно.

Вся система интернета устроена так, чтобы:

• получить ответ как можно быстрее
• пройти как можно меньшее расстояние
• задействовать как можно меньше серверов

Для этого используются кэши.

Шаг 1. Браузер и кэш браузера

После ввода адреса браузер сначала проверяет: «А у меня уже есть эта страница?»

Браузер может хранить:

• готовую HTML-страницу
• стили
• JS скрипты
• изображения

Если нужные данные уже есть в кэше браузера:

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

Это самый быстрый вариант.

Шаг 2. DNS — поиск адреса сервера

Если браузеру всё-таки нужно идти в интернет, сначала он должен понять:

«Куда идти?»

Для этого используется DNS. DNS переводит имя сайта в IP-адрес

Шаг 3. CDN — сервер ближе к пользователю

После DNS запрос идёт не обязательно сразу на основной сервер сайта.

Между браузером и сервером может находиться CDN — сеть серверов в разных странах.

Пример: основной сервер находится в Европе, пользователь — в Южной Америке

Если всегда обращаться в Европу:

• сигналу нужно пройти большое расстояние
• страница будет загружаться медленно

CDN работает так:

• первый запрос идёт на основной сервер
• ответ сохраняется на сервере CDN ближе к пользователю
• следующие пользователи получают страницу быстрее

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

• если CDN отдаёт ответ из кэша, запрос не доходит до основного сервера
• скрипт ничего не узнаёт о пользователе

Шаг 4. Веб-сервер (Apache / Nginx)

Если CDN не смог отдать страницу, запрос приходит на веб-сервер. Веб-сервер — это программа, которая принимает HTTP-запросы.

У веб-сервера есть выбор:

• отдать готовую страницу (если он откуда то знает что надо отдать)
• передать запрос дальше в скрипт

Если у веб-сервера есть готовый ответ:

• он сразу возвращает страницу
• скрипт не запускается
• скрипт не знает, что был запрос
• Apache может передать запрос скрипту 1 раз и закешировать ответ

Важный момент: что такое серверный кэш. Серверный кэш — это не часть веб-сервера и не часть скрипта.

Это:

• отдельное хранилище
• файлы, память или Redis
• грубо это как отдельная коробка в которую могут складывать данные кто угодно кто работает на сервере

Еще раз для понимания. В серверный кеш могут писать:

• веб-сервер
• скрипт
• оба одновременно

Шаг 5. Скрипт (приложение)

Если запрос дошёл до скрипта:

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

Скрипт формирует страницу из данных.

Важно: кэшироваться может не только вся страница, но и отдельные данные.

Пример:

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

Тогда: название сайта можно взять из базы 1 раз и сохранить в кеше, а дата формируется заново каждый раз

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

Шаг 6. База данных

Если данных нет ни в каком кэше:

• скрипт обращается к базе
• база читает данные (тут варианты - если хватает памяти Mysql держит данные в памяти, если не хватает - читает с диска)
• страница полностью формируется заново

Что из этого всего надо понять

• если запрос не дошел до скрипта - скрипт про него просто не узнает
• page cache, Redis, memcache, серверный кеш и еще куча слов - это не важно, это просто название “коробочек” куда складываются данные. Важно только в каком пункте и что именно вы кешируете

Как используется память под кеш

• базово данные хранятся в файлах
• база данных (mysql) может данные держать в памяти если хватает памяти и достаточно выделено в конфиге mysql
• redis (и любой другой кеш) так же как и база стараются хранить данные в памяти но если не хватает - скидывает в файл