@Topper предложение по улучшению логики работы. Если есть возможность оптимизируй отправку заданий при пакетной генерации, к примеру спарсилась текстовка для первого дора, тут же отправляем парсится задание для второго дора и только потом начинаем скачивать запаковывать/распаковывать текстовку, потому что в некоторых случаях скачка/закачка и запаковка/распаковка длится по 20минут и больше, за это время апарсер уже спарсил бы какую то часть нового задания. Экономия времени очень заметная получится.
ну так пусть парсятся, линкапарсер может запомнить 5-10 имен заданий. обработал первое, начал скачивать второе. Я думаю параллельно две задачи(обработка готового текста и заливка новых заданий) это не такая уж и сложная задача для такого кодера ка Топпер.
А у кого-нибудь возникала ошибка при генерации: 8d205b63.2.21.Single website generation.Prepare started.Preprocessing..Static vars set.Template 'WP-education-hub' loaded.Categories loaded.Categories ready.Keys read_START.Themed-cats:No.Key loaded.Keys mixed.Keys take limited.Keys:998.Keys arrays created. Posts calculated.Making map.Maps ready.Generation started.Static vars set.Output folder emptied.Text loading..Algo#2. LO:Algo#2. ArgumentException: Text files are not found in selected subdir:false
@Topper Еще предложение добавить в Linkaparser опцию удалять результирующие файлы текстовки меньше определенного объема. Пусть лучше останется меньше файлов но с нормальным объемом текстовки чем куча файлов по 20-40 байт с текстом из 10 слов
Тут дело в том что за счет кучи маленьких файлов очень медленно все сохраняется и чистится =( @Topper давай как нибудь ускорим софт, пусть по одному запросу в один файл все складывается, а не в 10 разных, или еще какие то варианты может можно сделать.
Присоединяюсь, чистка и сохранение файлов отнимает львиную долю времени в процессе, мне тоже кажется что как то логичние было бы вообще сохранять чищенное по типу 1кей- 1 файл, да и вообще иметь возможность получить нужное количество строк - к примеру мне надо 25 строк чищенного текста на страницу - сохранили его и всё, переходим к следующему кею.
Хорошо, давайте сделаем как вам кажется правильней. Плюсы: действительно не будет много файлов, можно будет не папки на ключ юзать, а файл на ключ. И в нем все. Минус: макрос APARTICLE перестанет работать , так как щас каждый файл - это каждый отдельный сайт - отдельная статья
Как вариант сделать переключающиеся режимы, и допустим для APARTICLE сделать отдельную папку, если нужны статьи целиком то пожалуйста, нужны тексты кучей, включай другой режим.
Оптимальный вариант. И переключения не нужны - пандора видит макрос APARTICLE и идет за статьей в соответствующую папку
Переключающиеся режимы - лишний гемор для меня и пользователей. Опять же куча файлов никуда не денется. Давайте просто выпилим APARTICLE макрос, он вообще кому-то нужен? Кстати если все переделывать то на этот раз без миграции, только с нуля все парсить по новому раскладу. Я в прошлый раз миграций наелся на годы вперед. Да, это есть в планах
Topper, ну я незнаю за остальных товарищей, но лично я макрос APARTICLE так и непользую вообще, а что касаемо миграций - имхо вообще удаляю спаршенное после каждой пакетки, диск нерезиновый, невижу смысла создавать коллекцию из текстовки, легче свежего при необходимости спарсить.
