Вышла версия 3.0.4
+ Исправлены ошибки
+ Немного ускорена работа приложения
Скиньте на мыло сайт. Повторить ошибку не удалось.
Hkey добавил 24.08.2011 в 14:41
Отправьте мне на мыло a.v.belousoff@gmail.com доступы. В течении 2-3 дней гляну.
Исправил, перекачайте
Такого рода запросы не появляются в облаке ссылок и в титлах ссылок. Однако, они могут появиться в альтах картинок, если их частотность довольно высока чтобы пройти отсев. Я считаю, что если их частота действительно велика, то следует упомянуть их один или несколько раз в альтах.
Класс для коррекции таких ошибок очень медленный.
Hkey добавил 22.08.2011 в 13:17
Вышла версия 3.0.3
1. Исправлены ошибки
2. Немного ускорено выполнение некоторых функций
3. Немного улучшен отсев дублей
Отключите тестовый режим. Ошибки этой не будет.
Новая версия 3.0.2
Если у вас возникла ошибка с 'р' то вам нужно отчистить базу и заново импортировать данные.
Hkey добавил 16.08.2011 в 11:45
Включить форсирование и включить игнорирование MySQL ping
Ваш сервер почему-то дает PHP коннект к MySQL с неправиольным паролем и юзером. Еще до того как выполняется первая строчка.
Они не автоматически генерят.
Алгоритм такой выбирается один ключ исходя из его частотности, длины и присутствия в других ключах. Затем он находит самый длинный ключ содержащий исходный и делает его исходным. Затем он дополняется спереди одним прилагательным, если это возможно и безопасно и сзади каким-то словом или словосочетанием, если это слово встречается сразу после последнего слова исходного титла во многих ключах. При добавлении прилагательного проверяется сочетаемость этих двух слов в ключевиках и второе слово не должно являться прилагательным, также проверяются псевдокорни всех слов на соответствие прилагательным.
Если самый длинный ключ содержащий самый частотный длинее дополненого, то возвращается он. Перед формированием фильтра все ключи проходят частотный фильтр, ключи с частотой меньше допустимой удаляются.
Если на уровне сервера включить, то все будет хорошо. Если на уровне CMS, то устаналивать HTRacer сложнее.
Что такое бинарный поиск? Допустим у нас есть упорядоченный массив из 1000 элементов. Нам нужно найти элемент массива имеющий какое-то значение, допустим 15. Мы можем его просто перебрать, совершить в среднем 500 шагов пока не найдем искомый элемент.
Однако наш массив упорядочен, нам достаточно 10ти шагов. Проверим элемент с номером 500, если он меньше 15 значит искомый элемент будет иметь индексы, от 1 до 499, если больше от 501 до 1000. В любом случае мы отсекаем 500 элементов. Допустим он меньше, проверяем 250 элемент... и так далее. В итоге нам потребуется не более Log2(1000)=10 шагов.
Допустим, у нас есть Массив из 1000 ключевиков и их весов на нужно выбрать один из его элементов с вероятностью выпадения пропорциональной его весу. Суммарный вес ключей мы знаем, допустим он равен 10.000. Чтобы решить задачу нам нужно сгенерировать случайную величину от 1 до 10.000. Допустим она равна 5.000. Потом перебрать массив, считая сумму весов уже пройденных элементов и найти такой элемент которые делает сумму весов элементов большей 5.000.
Однако, если в следующий раз нам нужно опять выбрать случайный элемент, мы можем запомнить для каждого элемента суммарный вес элементов до него и воспользоваться бинарным поиском.
Единственный более быстрый вариант это использовать индекс, содержащий размноженные ключи на их вес. Однако он будет занимать очень много памяти и линейно расти со временем.
Также можно в низ бинарного дерева поместить элементы с большим весом. Однако качественный прирост производительности это не даст. Да и это не критичный по производительности участок.
Число запросов это очень относительный параметр. Запросы же разные бывают.
DLE, если я не ошибаюсь часть данных хранит в файлах. DLE это очень специфическая CMS, предназначена чтобы делать варезники на слабых хостингах.
Уже упомянутый вами All in one SEO pack для WP использует 3-4 запроса.
На офсайте есть спец раздел премимум, гляньте туда.
Также где-то видел есть очень интересное исследование взяли самые посещаемые сайты по алексе и автоматом пробили их цмс. Самая популярная цмс на них, естественно, самопис. Затем WP, потом еще более грузная джумла.
Нет и я не планирую этого.
Я сомневаюсь что релевантность страницы донора внутренней ссылки играет какую-то роль. Для внешних ссылок такая роль есть, поскольку так можно отсеять покупные ссылки, однако о такого рода внутренних ссылках говорить глупо.
Внутренних ссылок минимум в десять раз больше чем внешних. Я считаю нерационально тратить ресурсы поисковика на расчет естественности внутренних ссылок.
Нет экспериментов подтверждающих вашу точку зрения.
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. Сохранять страницы целиком: Да
На большинстве сайтов можно включить кеширование только морды и общих данных.
Суппорт только по мылу. Скайп и 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.0.1
2. Добавлено несколько опций
3. Ускорена работа
4. Немного улучшена расстановка ссылок.
Подробнее распишу и отвечу на вопросы завтра.
