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

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

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

Hkey не могли бы Вы по умолчанию такую фичу прикрутить, а то рельно жрет ресурсы!☝

Поскольку запрашивать данные (SELECT) тут приходится намного чаще, чем обновлять (UPDATE/INSERT), то:

1) храним в БД: урл странцы, ключ перехода с ПС, количество переходов

2) при переходе с ПС:

INSERT INTO table (url,key,cnt) VALUES ($url,$key,1) ON DUPLICATE KEY UPDATE c=c+1;

3) при выборе ключа для страницы:

select key, (cnt / (select sum(t1.cnt) from table t1 where t1.url = t2.url)) * 100 as pr
from table t2
where t2.url = '$url'
order by pr desc

Понятное дело, что вместо подзапроса имеет смысл сумму сразу получать и потом делить на константу во втором запросе. Или даже при апдейте table обновлять в другой таблице (url, sum_cnt) сумму - тогда еще проще.

Но даже без оптимизаций у меня на таблице с 10000 записями никаких тормозов не возникло.

По умолчанию не получится. Скрипт работает НА ЛЮБОЙ ЦМС, а каждая ЦМС имеет свою логику работы. Поэтому на каждом сайте делается все индивидуально. При чем кешируется все в memcached

Hkey, отличная тема. ваш скрипт кладет мой mYSQL, и это на выделенном сервере. 0_o

Какая у него предельная посещаемость? Поставил на тысячник... Сейчас отключит и ребутаю машину...

Почитайте внимательно всю ветку. У меня скрипт встал только после того, как автор его немного подправил под мой шаблон. Слова авторы: "у меня не стандартный шаблон на джумле". Не у всех в кривых руках дело - не обобщайте. Скрипт тоже не со всеми CMS безпроблемно работает.

50 метров для скрипта - ничто. :) У меня рост базы в день был 25 метров.

А ВЫ случайно не под ЦМС ДЛЕ кешировали?

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

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

INSERT INTO table (url,key,cnt) VALUES ($url,$key,1) ON DUPLICATE KEY UPDATE c=c+1;

select key, (cnt / (select sum(t1.cnt) from table t1 where t1.url = t2.url)) * 100 as pr
from table t2
where t2.url = '$url'
order by pr desc

1. У вас вставка инсерт + апдейт, что в разы медленее инсерт. Но это мелочи.

2. При каждой загрузке страницы мы должны выбрать в среднем по тридцать титлов ссылок на другие страницы. Если конечно кеша нет. Т.е. мы должны выполнить вашу функцию 30 раз.

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

Почувствуйте разницу при LOG2(16)=4 LOG2(256)=8 LOG2(1024)=10. На копирование тех запросов, которые вы не выбираете теряется время и прочие мелочи.

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

Hkey добавил 04.05.2011 в 23:17

1. Яху давно появилось. Месяц как точно. В целеособразности Бинг не уверен (какой у него % трафика)

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