HTracer 2.0 - скрипт для автопродвижения сайтв

Ставлю на dle 9.2, место под букву якобы есть, а буквы нету...

И еще когда перехожу по запросу на сайт в хедере выскакивает такая ошибка

Warning: Division by zero in /home/ххххх/domains/хххххх.ru/public_html/HTracer/HTracer.php on line 3043

Суппорт только по мылу. Скайп и ICQ отвлекают.

Hkey добавил 12.08.2011 в 21:44

Кеш обновляется постепенно, поскольку он не сразу и собирается.

Hkey добавил 12.08.2011 в 21:45

На мыло напишите. Такую проблему не смог повторить.

Hkey добавил 12.08.2011 в 23:12

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

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

Мета кейвордс учитывается Яндексом. У них так на сайте написано. Также он учитываеться роботами систем контекстной рекламы, что увеличивает при его правильном заполнении релевантность объявлений.

99% содержание метакейрдс генерируемом HTracer есть на странице, поскольку если бы какого-то ключа не было бы, то по нему не было бы переходов.

Автоматически метакейвордс не генерирует ни один из движков известных мне.

Если запросов мало, то на самый частотный. Если много, то выберется некая комбинация.

например,

квартиры посуточно

квартиры посуточно в Одессе

недорогие квартиры

Превратиться в "Недорогие квартиры посуточно в Одессе". Хотя все зависит от частотности запросов.

Нет сделано все совершенно иначе.

Третья версия чтобы сгенерировать альты, метакейвордс, титлы использует только один запрос к MySQL (один простой запрос на все эти три возможности). Просто выбираются все ключи для текущей страницы с их весами. Результаты запроса запоминаются. Для того, чтобы далее выбирать альты быстрее формируется массив специального вида.

Чтобы выбрать один ключевик пропорционально его весу с вероятностью пропорциональной числу переходов по нему, используется модификация бинарного поиска, которая выбирает его крайне быстро, за логарифмическое время. Например, из 1000 ключей один выберется максимум за 10 шагов, а из 1 000 000 за 20 шагов.

Титлы ссылок выбираются другим способом, но при быстром разборе используется один запрос к БД, чтобы выбрать все титлы ссылок (при настройке "быстрый разбор").

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

В итоге мы получаем 4ре запроса на генерацию всей страницы. CMS в среднем используют где-то 20 запросов. Результаты санитаризации строк, большинства фильтров хрянятся в БД.

Мне встречалось только два таких движка, но они легко исправлялись.

Более того дубли в этих движках не полные.

Мигание не будет из-за особой вариации рандома. При F5 он не мигает.

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

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

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

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

Общая буферизация вывода позволяет освободить память еще до начала передачи данных.

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

Подключение HTracer происходит через общую буферизацию вывода. В этом случае GZIP сжатие просто увеличивает нагрузку на сервер, не давая бонуса в освобождении памяти. Более того она почти не снижает скорость загрузки данных клиентом, поскольку основной объем данных не HTML, а картинки, css и js-файлы.

Кто ставил версию 3,1 - как с косяками? Все никак не решусь обновиться, а сервак грузится.... Не охота все опять положить...

Нет и я не планирую этого.

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

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

Нет экспериментов подтверждающих вашу точку зрения.

Hkey добавил 13.08.2011 в 00:09

Новые опции

1. Добавлена возможность отключения автовалидации. Отключение ускоряет работу приложения.

2. Добавлена опция только ночных апдейтов. При включении ее апдейты будут происходить только ночью. С часа ночи до 6 утра по времени сервера.

3. Добавлена опция кешировать только морду и общие данные. В этом случае кеш будет иметь около 10 страниц. Почти равносильно отключению кеша, но производительность будет где-то 1.5 раза выше чем при полном его отключении.

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

При включенном MySQL и настройках:

1. Разбор HTML: быстрый(php 5)

2. ГЗИП сжатие кеша: нет

3. Кешировать страницы целиком

4. Актуальность кеша: 5 дней

5. Сохранять страницы целиком: Да

На большинстве сайтов можно включить кеширование только морды и общих данных.

Вы что шутите? DLE в дефолтной конфигурации и тот же WP с плагином All-in-One SEO pack точно генерят. Уверен, что многие другие с нужными плагинами генерят...

Это хорошо. Только интересен вопрос анализа морфологии. Как вы гарантируете, что тайтл получится "человекочитабельным"?

Я не об этом мигании говорил, еще не хватало, чтобы по F5 что-то менялось, я как раз об этом:

Кстати какие именно данные? Все что-ли, в том числе тайтл, тайтлы ссылок, альты, кейвордсы?

Согласен, в том то и вопрос, не посчитают ли поисковики эти манипуляции как сео-спам.

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

Скорость работы сервера и скорость работы сайта - улавливаете разницу? Я же написал:

Да, нагрузка на процессор при включенном gzip-сжатии резко возрастает (особенно если выбрать неоправдано высокий уровень сжатия - например 9), но зато при этом страницы отдаются очень быстро из-за их маленького объема и линейной передачи в виде одного файла - практически летают, что несомненно является положительным фактором не только для конечного пользователя, а и ранжирования.

Ну и я так и не понял, работает ли ваш скрипт с включенным gzip-сжатием. Кстати включаю его на уровне веб-сервера (nginx), то есть конечно не хотелось бы отключать его для конкретного хоста только для того, чтобы работал ваш скрипт.

Почему-то вспомнилось сразу про забор :) - там тоже написано...

Что-то очень сложно.

Нельзя ли просто на основе рандома с коррекцией по вероятности (частотность) высчитывать номер анкора из скажем отсортированного списка. Все ж намного проще, о каких 10-и шагах вы говорите, о каком поиске - там он не нужен - задача ж не заключается в абсолютной точности, здесь же вероятность - а значит результат все равно случайный, просто случайность смещается на основе вероятности. Покажите на конкретном примере вашу задачу, что вы пытаетесь вычислить - может мы коллективными усилиями проще придумаем.

Уже напрашивается вопрос, а что же происходит при "Медленном разборе" :) - неужели на каждый титл по запросу. То есть пусть в среднем имеем 30 внутренних ссылок на другие страницы - так что 30 дополнительных запросов к БД?

Это очень много! Нельзя ли записывать все вычисления в 1 таблицу БД и потом делать 1 запрос. Денормализуйте БД, зачем доставать какие-то "недоданные", которые еще надо долго и мучительно просчитывать, храните сразу результаты. Неужели это невозможно реализовать - подумайте над этим.

Ну почти согласен, только я бы не говорил в среднем - это почти максимум, столько делает тот же WP, например этот форум vbulletin - внизу этой страницы "Page generated in 0.11626 seconds with 15 queries". DLE для генерации внутренней страницы делает от 2 до 5! По моему с кешированием только 2 запроса.

Далее, CMS которые занимаются таким извращением (я про 20 запросов) абсолютно не предназначены под большой траф, если вы с этим не согласны - покажите мне сайт на WP с большой посещаемостью...

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

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

Обновился так 3.0 (с исправлениями что постили) --> 3.0.1

По нагрузке сказать ничего не могу (посещалка маленькая), некорректно стало работать облако (вместо пяти (параметр 5/15) выводится 15 ссылок) временно отключил. Засек время загрузки страницы, оно уменьшилось на 0,2 seconds

Одной?

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

Кстати чем измеряли то?

Проверял здесь одну страницу, более менее нагруженную

Подтверждаю.

Есть такое - на новом сайте с 0 установил скрипт свежескачанный.

Сделал пару переходов с Яндекса - в базу попали ключи без буквы Р.

Добавил вывод облака - как на старых сайтах:

";

echo get_keys_cloud();

echo"

Получаю

а ниже - облако ссылок и опять же без Р.

Блин, а где взять новую версию то, если я владелец старой и давненько не следил за обновлением? На сайте нашел только версию 2.5.1.

И что значит ошибка "Access denied for user 'apache'@'localhost' (using password: NO)", точнее что нужно сделать, что бы ее не было?

Полная ошибка выглядит так

"CreateTables_1

Access denied for user 'apache'@'localhost' (using password: NO)

CREATE TABLE if not exists `ht_search_query` ( `ID` INT NOT NULL AUTO_INCREMENT PRIMARY KEY , `URL_CS` VARCHAR(100) NOT NULL , #МД5 УРЛа на который пришел юзер `Page_Type` INT NOT NULL , #Тип страницы (пост,метка,категория, морда) `Ref_ID` INT NOT NULL , #ID поста,метки или категории `Query` TEXT CHARACTER SET utf8 NOT NULL , #Запрос `SE` VARCHAR(100) NOT NULL , #Название поисковой системы `SE_URL` TEXT NOT NULL , #УРЛ поисковой системы с которого пришел юсер `URL` TEXT NOT NULL , #УРЛ на блоге на который пришел юзер INDEX ( `URL_CS` , `Page_Type` , `Ref_ID`,`SE`) ) ENGINE = MYISAM CHARACTER SET utf8 COLLATE utf8_general_ci;"