распределенность

Эта TDS распределенная т.к., как вы уже догадались, может располагатся на нескольких независимых друг от друга серверах, а точнее на 2-х. Все дело в том, что она состоит из 2-х частей:

1. модуль определения региона и ведения логов
2. модуль управления (главный) или сам интерфейс TDS

Помимо этого существует еще 3-я функциональная часть, которая располагается у клиента т.е. у нашего трафа.

минимальная нагрузка

Да, вы не ослышались, данная TDS практически не создает нагрузку на сервер БД, а на WEB-сервер нагрузка, небольше чем на простенький сайтик из тех, что размещают на narod.ru.

клиентская часть

Если вдруг кто-то, использовал lukmuTDs предыдущих версий, то он знает, что в ней все делится на схемы (schemas), цели (aims) и сайты (sites). В меню сайты задаются, по желанию, сайты откуда идет траф, в целях – куда пойдет траф, и в главном меню задаются сами схемы потока трафика, т.е. из какого сайта на какую цель/цели пойдет трафик, в каких количествах, какой браузер и регион.

Так вот, основная ресурсоемкая задача – определить какой схеме принадлежит запрос. В предыдущих версиях этим занималась TDS, в результате чего были постоянные обращения к БД.

Теперь все не так, после создания всех схем БД больше не нужна и обращений к ней от трафика не будет. Все дело в том, что теперь схему и цель определяет сам браузер т.е. трафик сам себя обрабатывает. А если подробнее, то выбор за трафик осуществляет JavaScript, который загружается в браузер.

Но, тогда возникает резонный вопрос – как генерируется JavaScript, вся информация о схемах записывается в БД, значит при генерации скрипта задействуется БД тем самым нагрузка на БД не снижается. А вот и нет, JS генерируется только один раз, после того как вы создали или изменили схему, сайт или цель. После этого JS кэшируется и когда трафик запрашивает JS, он выдается из кэша без какого-либо обращения к БД и минимальном участии PHP, что в данном случае равносильно запросу обычной статической HTML странички.

модуль определения региона

Этот модуль при больших объемах трафика (свыше 500 000 запросов) желательно разместить на отдельном хостинге, при меньших объемах можно оставить и на том же сервере что и главная часть.

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

Как видите здесь вообще нет БД, а все участие PHP описывается на 40 строчках, с учетом комментариев. Т.е. в данном случае нагрузка на сервер так же не далека от выдачи статической страницы.

основной интерфейс TDS. модуль управления

Интерфейсная часть по сравнению с прошлыми версиями потерпела серьезные изменения. Обращения к БД происходит только в 2-х случаях:

• при изменении схемы, сайта или цели
• при обновлении статистики

Для первого случая, все итак понятно – трафик стабильно идет, покупатели надежные, деньги капают – ничего менять не надо – обращений к БД нет.

Что касается статистики, то частоту ее обновления вы настраиваете сами. Поставите 1 час – про БД вообще забудите, поставите 30 сек – хостинг вас забанит. Короче, частота настраивается cron’ом т.к. скрипт обновления будет запускатся именно им, при гигантском трафе нормальныи будет 20-30 минут, если трафик не превышает 30-50к то можно поставить и 5 минут.

интерфейс

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

параллельность и объединение

Зайдем в меню схемы и увидим

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

В предыдущих версиях TDS перенаправляла трафик на цель обычным редиректом, сейчас же все не так. Как уже говорилось выше, во-первых теперь этим занимается не TDS, а JavaScript из кэша, а во-вторых теперь нет редиректов, а есть формирование HTML-страницы с таким количеством iframe’ов, какое заданно в схемах, а точнее сколько целей задано на конкретную схему.

процентное деление потока

Как видно на предыдущем скрине, теперь трафик можно разделять т.е. не паралельно пускать, а именно делить. Чтобы это понять надо либо прочитать про интерфейс предыдущих версий, либо читать далее.

Схема для запроса из потока выбирается в соответсвии с позицией схемы в меню т.е. представим:

1. идет запрос на сайт, где стоит ифрейм на TDS
2. TDS выдает из кэша JS
3. JS просматривает все схемы сверху вниз и выбирает схему с наивысшей позицией, которой удовлетворяют характеристики запроса (рефер, регион, браузер)

Допустим запрос из потока трафика не удовлетворил первой схеме, тогда он проверяется второй. Пусть он удовлетворил 2-й и если во 2-й схеме процент 100%, то на этом выбор закончен. Если же процент скажем 50%, в таком случае на помощь идет теория вероятности.

Сейчас я расскажу очень простой принцип, однако, не все знают что он носит имя метод Монте-Карло. Так вот, если процент отличен от сотни, то генерируется случайное число от 0 до 100 и если процент больше либо равен случайному числу, то трафик идет по выбранной схеме, в противном случае он будет дальше перебирать схемы. Именно поэтому рекомендуется в качестве последней схемы ставить например google.com-ALL-ALL-ALL-100%.

Так же в схемах есть управляющие кнопки:

• редактировать
• удалить
• поднять вверх
• остановить
• обнулить статистику

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

меню promo

Как и раньше в promo выдаются ссылки и криптованные ссылки на TDS т.е. те которые нужно вставить в захваченый сайт. Однако теперь ссылки делятся на 2 категории:

1. JAVASCRIPT LINKS
2. PHP LINKS

Такое разделение объясняется тем, что они ведут на разные обработчики трафика TDS. Так как lukmuTDs v1.1x может работать в 2-х режимах:

1. как раньше т.е. трафик обрабатывается TDS (PHP LINKS)
2. по-новому т.е. трафик обрабатывается JS из кэша (JAVASCRIPT LINKS)

Как и раньше ссылки представляются в 3-х видах:

1. естественный
2. закриптованный методом Packed
3. закриптованный методом Packed и облаченный в ASCII-коды, дабы не было никаких ковычек (часто нужна, когда ссылка на TDS вставляется не в файл, а в БД)

На дне страницы есть еще форма, куда можно вбить свою ссылку и оттуда она выйдет закриптованной и облаченной в ASCII.

установка и конфигурация

установка

Здесь я рассмотрю установку на 2 сервера, установка на 1 сервер происходит аналогично.

1. кидаем на первый сервер (geo) скрипт geo.php и папку logs
2. выставляем права 0777 на logs и на файл, внутри папки (по умолчанию kju_log)
3. все остальное кидаем на главный сервер с TDS
4. дамп БД импортируем из файла с дампом (lukmutdsv1.11.sql)
5. выставляем права на папку cache 0777

конфигурация

GEO-сервер

Отворяем файл geo.php и видим в начале файла:

//config
$key="key_which_2_auth_on_geo";
$statfile="logs/kju_log";
//===================

$key – ключ, по которому основной модуль TDS будет синхронизироватся с GEO. Вбиваем туда бессмысленные набор букв и цифр.

$statfile – путь до файла-лога.

основной модуль TDS

Открываем config.php и видим:

define('inc_dir',$_SERVER['DOCUMENT_ROOT']."/includes/");
define('ua_pass',md5("this_is_random_symbols")); //user-agent pass
define('uauth',false); // user-agent auth on/off
//js-cookies
define('ltds2c','this_is_random_symbols');
define('uniqc','this_is_random_symbols_too');
//geo
define('geo_location','http://path2.site.with.geo.com/geo.php');
define('geo_key','key_which_2_auth_on_geo');

Константа ua_pass – ключ авторизации по header’у браузера, ее можно выключить если в константе uauth выставить false (по умолчанию так и стоит).
Константы категории js-cookie – рудимент от версии 1.10 (данная версия 1.11), однако его все равно надо заполнить какими-нибудь символами.
geo_location – путь до geo.php, geo_key – ключ для сбора статистика, указываем то что забили в geo.php.

Теперь открываем includes/db_config.php и настраиваем доступ к БД:

$db_host="localhost";
$db_user="tds_db_user";
$db_pass="tds_db_pass";
$db_name="tds_db_name";
$sol="a_lot_of_random_symbols";
$sol_pass="a_lot_of_random_symbols_too";
$db_type="mysql";
$db_host="localhost";

Заполняем пользователя, пароль, имя и хост БД. Затем придумываем соли.

Теперь осталось только поставить в cron’е запуск скрипта getstat.php и частоту его запуска.

TDS готова. Заходим на сайт с TDS и регистрируемся, после чего заходим в TDS.

Скачать lukmuTDs v1.11.

P.S. а ведь была еще и lukmuTDs v1.1. У нее статистика считалась по AJAX’ому отстуку, но как показала практика такая стата не реалистична т.к. не смотря на то что ajax-вый запрос отправлялся на хост с которого был загружен JS-скрипт (обычная метода обхода ограничения xmlhttprequest на тот же домен, что и страница) не многие браузеры все же отправляют запрос.

патч для lukmuTDs v1.11

Скачать: http://www.sendspace.com/file/jp749m
Исправлена ошибка в работе getstat.php, когда запускается от cron’а. В config.php введен новый параметр – полный путь к директории TDS.

lukmuTDs v.1.111

Скачать: http://www.sendspace.com/file/bgv6ak

Исправлена ошибка в обновление последнего визита с сайта.