Перелинковка занимает час! 700 статей

Сделал я так как показано в ролике по перелинковке. 700 статей программа перелинковывала около часа. Компьютер не слабый.
1. Почему это занимает так много времени и нельзя ли сделать этот процесс быстрее?
2. Можно придумать кнопку принудительной остановки процесса? Так как если я не хочу ждать час, я бы остановил, изменил настройки и запустил бы с менее сложными настройками. А так приходится или ждать или через ctr+alt+del все отключать и терять изменения…

admin в своем сообщении писал(а):

RonVisal в своем сообщении писал(а):Добрый день. Подскажите, какую zebroid должен давать нагрузку на процессор при анализе статей на наличие ключей для перелинковки? У меня выше 13% нагрузки от его процесса в диспетчере задач не поднимается, а проект достаточно большой для перелинковки (~17000 ключей с масками, на ~5000 статей). Вот и думаю, не стоит ли каких-то ограничителей по нагрузке? При полной нагрузке бы все гораздо шустрее обработалось, наверное. А так, за 12 часов только 30% прогресс.

Сколько в настройках программы выставлено в параметре «Использовать ядер процессора»?

Все таки, если нажать «Анализировать», то указанное число ядер не задействуются — максимальная нагрузка ЦП 13%. Если жать сразу «Перелинковать», то прогресс бар движется достаточно шустро, используется уже 60% ЦП. В настройках указал 7 ядер из 8.

Тоже столкнулся с долгой перелинковкой.

admin, подскажите, при обычной перелинковке, во время работы инструмента, учитываются ограничения на число вхождений и ссылок со страницы?

По идее, если со страницы поставлено предельное число ссылок, — она должна исключаться из поиска подходящей страницы для ссылки, если достигнуто ограничение на число вхождений — поиск по вхождению также прекращается. Это должно приводить к ускорению перелинковки со временем. Однако судя по прогрессбару ускорения не видно. Проект большой (8к статей, по 20к, 8 ядер, первый процент прошел за 25 минут, через 2,5 часа — 4%), может можно чуть ускорить?

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

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

Чтобы перелинковать 700 статей используя 700 правил — нужно выполнить поиск вхождения ключевого слова в статью примерно 500 тыс. раз.

При перелинковке 700 статей и 700 правил при последовательной обработке страниц/правил должно уменьшаться число проверяемых страниц/правил, т.е. в конце должны остаться единицы правил не достигших предела по вхождениям и единицы не обработанных статей не достигших предела по числу исходящих ссылок. И число поисков должно быть в пределах 350*350 122,5 тыс., а не 500 тыс. Возможно, программа использует более сложную логику, для более равномерного распределения ссылок, но на большом проекте это часто не нужно.

Это должно приводить к ускорению перелинковки со временем.

Должно, ближе к концу. А вы делаете вывод на основании 4%. Извините, но ваши наблюдения не имеют никакой основы, чтобы делать подобные выводы.

Насколько я понимаю из работы плагинов, программа много времени тратит на открытие статьи (получение её текста)

Вы ошибаетесь

При перелинковке 700 статей и 700 правил при последовательной обработке страниц/правил должно уменьшаться число проверяемых страниц/правил, т.е. в конце должны остаться единицы правил не достигших предела по вхождениям и единицы не обработанных статей не достигших предела по числу исходящих ссылок.

Интересно вы в простой пример без каких либо скрытых условий добавили ограничения на количество ссылок и еще по этим неизвестным числам посчитали конечный результат. К тому же, как я понимаю, вы рассматриваете идеальную ситуацию — во всех текстах есть какие-то ключевые слова и после прохождения статьи счётчик каких-то из ключей гарантировано увеличивается.

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

Насколько я понимаю из работы плагинов, программа много времени тратит на открытие статьи (получение её текста)
Вы ошибаетесь

Это заключение не ошибочно, сделано на основе плагина, который объединяет записи по названию. Исходный плагин мог работать часами на большом проекте (может и сейчас так, не проверял), а когда я его переписал чтобы все названия статей один раз загонялись в массив php и более не запрашивались ни разу — все ускорилось в сотни раз. Т.е. получение данных статьи все равно ресурсоемкая задача, даже если речь идет лишь о заголовке, а текст тем более будет еще дольше доставаться (в плагине цикл в цикле, как наверняка и при перелинковке, и любая задержка оказывается значительной).

Это заключение не ошибочно, сделано на основе плагина, который объединяет записи по названию. Исходный плагин мог работать часами на большом проекте (может и сейчас так, не проверял), а когда я его переписал чтобы все названия статей один раз загонялись в массив php и более не запрашивались ни разу — все ускорилось в сотни раз. Т.е. получение данных статьи все равно ресурсоемкая задача, даже если речь идет лишь о заголовке, а текст тем более будет еще дольше доставаться (в плагине цикл в цикле, как наверняка и при перелинковке, и любая задержка оказывается значительной).

Дело не в том, что программа «много времени тратит на открытие статьи », а в том, что это всё работает (взаимодействие php и программы) через обертку и соответсвенно работа через лишнее звено будет в любом случае медленнее чем напрямую с памятью сервера. Это как если бы вам нужно было брать яблока из корзины: в одном случае вам нужно каждый раз просить Васю дать яблоко, а в другом — корзина возле вас. Ускорить Васю не получится.

Реализовано в Zebroid 6 BETA 10.