Нет фактов доказывающих, что тематичность линковки влияет на ее эффективность. Более того, тематичность линковки "смазывает" эффект перераспределения веса в пользу основных посадочных страниц.
Облако для разделов нужно в целях юзабилити и его уникализации.
Hkey добавил 06.05.2011 в 22:04
да, поправил
Логично, что если вы в роботс.тхт закрыли урл, то на него переходы не идут и в облаке его не будет.
Вышла новая версия 2.3.3
Изменения
Скачать обновление можно по тому-же адресу введя тот-же серийный номер.
Обновлять нужно просто переписав файлы.
Пароль на админку нужно задать заново.
После обновления удалите кеш.
P.S. В этой версии есть все возможные оптимизации по скорости, которые можно произвести с сохранением "честности" расчетов. В теории эта версия должна тянуть все что угодно. Но если будут тормоза на некоторых, особо крупных сайтах, то попробуйте отключить запоминание переходов и оптимизировать таблицы и в любом случае отпишитесь мне на мыло.
Hkey добавил 06.05.2011 в 20:02
Настройки не выбивает при обновлнении. Настройки хранятся в auto_config.php его нет в обновлении он динамически создается (auto_config0.php есть в обновлении, но он не исполняется)
Пароль сбрасывается только при установке этой версии, поскольку его сохранение изменено.
Апдейт намного медленее инсерта
Хорошо, но линейность природы вашего кода это не убирает. Вы их должны отсортировать по значению (а не по индексируемой колонке) это больше чем линейная сложность. Я думал что вы с сортировкой просто ошиблись и не стал прикапываться. Еще и расчет значения вероятности имеет линейную сложность.
Hkey добавил 05.05.2011 в 00:04
На моем тысячнике он уже месяца 4 стоит. Сервер не выделенный, ничего не ложит ни одного письма не приходило о превышении лимита. Сайт не тормозит. Возможно причина в другом.
Hkey добавил 05.05.2011 в 00:09
Во первых это не парсилка. HTracer ничего не парсит.
Во вторых весом и внутренним ссылочным переоптимизировать нельзя.
В третьих не наблюдал переоптимизацию альтами картинок. На нее влияет тест и титл страницы.
В четвертых если переоптимизация происходит, то позиции ухудшаются -> трафик понижается -> вес запроса понижается -> число альтов уменьшается -> уровень переоптимизации снижается -> позиции улучшаются -> .... -> снова переоптимизация.
Он так будет прыгать туда-сюда и со временем остановиться где-то на середине. Ну это чисто в теории, таких ситуаций не видел.
Я ответил вам зависит от ситуации. По поводу ситуации с переоптимизацией я ответил.
В следующем апе этого не потребуется.
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 prfrom table t2where 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. Да только большинство имен собственных не будет поднято в верхний регистр.
1. Вы ошибаетесь gzip сжатие замедляет сайт, но уменьшает расходуемый трафик. На части CMS можно поставить HTracer чтобы было gzip сжатие и он работал.
2. По поводу кеша, в новом апе. Кеш будет занимать намного меньше места.
Hkey добавил 04.05.2011 в 14:37
Запоминание переходов можно деактивировать.
В следующем апе скрипт будет быстрее и кеш будет занимать в разы меньше места.
Логично, что если изменений на сайте нет, то прироста трафика не должно быть :)
Не помню, на мыло напишите.
Hkey добавил 04.05.2011 в 14:47
Не в буквально смысле, конечно. Он записывает импортированные переходы так-же и обычные. Это называется общностью хранения информации. Не цепляйтесь к словам.
Ваша демагогия мне уже порядком надоела. Как мы выяснили, вы не разбираетесь ни в программировании ни в SEO ни в MySQL. При этом вы высказываете свое мнение о работе того, в чем вы не совершенно не разбираетесь.
Более того, вы не хотите признать свою неправоту.
Этого не требуется. Я Вам задал очень простую задачку из самых основ SQL/MySQL. Любой разбирающийся в вопросе человек сказал бы сразу, что задача нерешаемая.
В принципе не нужно даже знать SQL/MySQL или программирование. Простая логика: когда у нас отдельно не записываются переходы, нужно считать вероятность выпадения ключа, а для этого нужно просуммировать все значения, а чтобы просуммировать все значения нужно их считать. Что займет время.
Жду от вас публичного признания неправоты. Публично кидаться не разбираясь в теме вы можете, теперь посмотрим хватит ли у Вас сил признать свою ошибку.
P.S. По поводу облака, походу, вы установили на разные БД админку HTracer и HTracer на сайте. Либо используете разные префиксы таблиц.
Hkey добавил 04.05.2011 в 15:29
Под прыгающими запросами вы имели ввиду переоптимизацию?
Попрошу не выражаться, а если выразились, то обоснуйте.
При импорте заходов имитируются переходы. Если вы думаете, что вы лучше меня понимаете структуре БД, программировании и прочем... То решите поставленную задачу:
P.S. Если вы все-таки разберетесь почему переходы, записываются в разные строки БД, я жду от вас публичного признания в вашей не правоте. Если вы решите эту задачу без записи переходов в отдельные строки и при этом не снижая производительность, то я признаюсь что я был не прав.
Вы оказывается не разбираетесь не только в программировании...
Чтобы изменения на странице вступили в силу в Яндексе, страница должна переиндексироваться роботом Яндекса и должен произойти апдейт текстовой базы. Апдейт, в Яше, обычно, ставит в поиск индекс недельной или двухнедельной давности.
Если вы умудрились установить причинно-следственную между Апдейтами Яндекса и шаблонами smarty, то утренний бодум самое мягкое из возможных предположений которые я бы мог высказать.
Логично, что не будут. Написали бы в суппорт я бы помог.
Переход это один заход пользователя. По одному запросу может перейти несколько пользователей. Для вас это новость?:)
Вы сами говорили, что вы не программист, поэтому, не задавайте вопросов, ответ на который не сможете переварить. Если в двух словах это структура БД - оптимизация по скорости.
Попробуйте быстро получить случайный ключ для страницы с URL=$URL, причем вероятность выпадения ключа должна быть пропорциональна числу переходов по этому ключу.
P.S. У вас ужасная пунктуация.
