Программа для автоматической регистрации в каталогах - Smile SEO Tools

У меня так же. Думаю это из-за того, что программа пересчитывает кол-во символов в каждом названии, описании, т.к. указано допустимое кол-во символов.

Господа разработчики!

Когда планируется исправление бага с последним зависшим активным потоком?

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

Анализатор бэков в сст довольно хорошо сделан, мне нравится.

Только вот поисковики выбрали Вы немножко не те.

Яша бэки с английского не показывает, гугл вообще ничерта не показывает.

Мне кажется, стоит добавить просмотр бэков по яху, он довольно хорошо показывает.

Нет никаких ограничений на "минимально необходимую скорость доступа". Если у Вас низкая скорость соединения с сетью, советую просто использовать меньшее количество потоков в работе и увеличить значения таймаутов в окне настройки программы. Грубо говоря, вся доступная ширина канала будет разделена между всеми приложениями, та его часть, которая "достанется" SST будет ею поделена между всеми активными потоками. Если поток за время, указанное в настройках таймаутов не сможет соединиться с сервером, где расположен какой-либо сайт или не сможет за это время получить очередную порцию данных, сработает аварийное завершение работы потока и, соответственно, будет указан статус "не возможно соединиться с сервером".

В зависимости от выполняемых задач и указаных настроек программа может работать с разным успехом, например, при проверке "битых ссылок" в 1000 потоков, с таймаутами в 100 милисекунд, при канале 32 kbps, скорее всего, программа покажет что "не работают" 99,9% проверяемых ссылок. Достаточные значения можно выявить только опытным путем, хотя бы потому, что в абсолютном большинстве случаев Ваш провайдер указывает лишь максимально возможную скорость подключения, во всех случаях провайдер не гарантирует (да и не может гарантировать) какую-либо конкретную скорость связи с отдельно взятым сервером.

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

Удалите те проекты, работы с которыми Вы завершили и не планируете продолжать, удалите те каталоги, которые Вы не используете и не собираетесь использовать, запустите процедуру оптимизации базы данных (после этого база данных не станет расти, скорее всего, в течение длительного времени (в зависимости от интенсивности работы)), выполните процедуру резервного копирования базы данных и восстановите резервную копию (после этого, база данных будет занимать минимально возможное для хранения введенного объема данных пространство).

Это не естественно, база данных будет расти только в случае постоянного ее пополнения, в случае же, если Вы удаляете данные и периодически запускаете процедуру оптимизации БД, ее размер если и будет увеличиваться (в случае, если данных будет загружаться больше, нежели будет удаляться) то значительно более скромными темпами.

В силу большей стабильности самой операционной системы, SST будет стабильнее работать под Win2000 (желательно SP4), желательно устанавливать последнюю версию FireBird (http://firebirdsql.org/index.php?op=files&id=engine_200)

Кардинальных отличий в работе не будет, но, в большинстве случаев, скорость работы системы в целом и, в частности, SST, на Win2k выше, нежели на WinXP.

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

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

Регулярно это делаю, ошибок практически нет... Если возможно, пришлите кусочек базы (экспорт в XML) где присутствуют каталоги, при авторегистрации в которых, возникают ошибки.

Цена на нашу программу ниже, чем на PagePromoter. Это такой маркетинговый ход.

Опишите подробнее, где и при каких условиях программа зависает. Желательно в письме на support@smile-group.ru.

Эту ошибку мы устраним к следующему обновлению, постараемся успеть доделать его на этой неделе. На данный момент попробуйте эту базу разложить на несколько папок каталогов и проводить анализ в каждой папке в отдельности.

Не могли бы Вы объяснить (в названиях функции программы:)) про какую именно функцию идет речь? Анализ бэков в той или иной форме есть во многих функциях.

Просмотр перечня обратных ссылок есть только по Яндекс и Гугл, действительно не хватает Яху и МСН

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

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

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

Дмитрий, вопрос на самом деле серьёзный, необходимо организовать процедуру так называемой свертки и обрезания базы. В любой серьезной прикладной программе (Н/р 1С :) ) такие функции реализованы, там обрезаются операции и сворачивается движение. В SST же можно например предусмотреть очистку проиндексированных страниц (INDEXEDPAGES) свертку SITEPOSITIONS, и подумать, что можно сделать с SITEREGISTRATIONS это явно одно из узких мест в организации БД. Может быть стоит например сделать ключем CATALOG+SITE зачем хранить историю неудачных регистраций если она нигде в проге не показывается? Там и так много инфы, например 5000 каталогов * 200 сайтов это уже лимон записей!!! А ещё и двойные.

ОК, постараемся в ближайшее время реализовать.

Давайте я не буду полностью отвечать на вопрос, скажу лишь, что связь между "таблицами" сайтов и каталогов в AllSubmitter'е очень и очень призрачна. Хорошо это или плохо - вопрос не ко мне, я считаю, что это не верно. При таком подходе сложно, долго и не эффективно выполнение многих выборок, например, отображение каталогов, где ни один сайт не был зарегистрирован. В то время, как подход реализованный в SST имеет лишь один минус - объем базы данных, а этот параметр, согласитесь, в реалиях сегодняшнего дня значит совсем не много. Построение "виртуальной БД" - может быть и выход, но мне кажется, место на жестком диске на порядки дешевле объема оперативной памяти. В любом случае, большинство занимаемого базой пространства тратится на хранение каталогов и их схем распознавания.

Мы к следующему релизу его еще упростим :) Но если хотите, крикните "Довольно" и все золото...

Обязательно придумаем способ уменьшить "текучку" данных.

Представьте такую ситуацию, Вы добавили 10 каталогов, распознали 8 из них, 2 удалили. Из 10 распознанных (предположим, что они имели по 6 полей в форме) удалили 3, т.к. посчитали их не нужными (ну например, "регистрация в каталоге временно приостановлена"). В оставшихся 8 Вы зарегистрировали 5 сайтов, потом удалили еще один каталог...

После всех этих манипуляций в базе останется

2 (удаленные каталоги) + 3 (каталоги удаленные будучи уже распознанными) + 3*6 (схема распознавания 3 удаленных каталогов) + 5 (записи о регистрации сайтов в каталоге, удаленном последним) = 28 записей, которые потенциально расцениваются как не нужные. Программа их лишь помечает как удаленные, но физического удаления из БД не происходит. Почему программа их не удаляет? Возможно я параноик, возможно это привычка осталась после разработки различного рода учетных систем для предприятий, но я считаю, что всегда должна оставаться возможность откатить удаления записей. После запуска процедуры оптимизации БД, эти данные будут удалены, место, занимаемое ими будет зарезервировано FireBird'ом для создания новых записей в этой же базе. Таким образом, рост БД на некоторое время остановится. В случае, если Вы снимете резервную копию, а потом восстановите ее - база будет занимать "минимально возможное" пространство на диске.

Резюме - почаще запускайте процедуру оптимизации БД, а мы тем временем придумаем какой-либо механизм сбережения места на HDD.

Да, обязательно реализуем подобную функцию.

История регистраций ведется вне зависимости от статуса регистрации. К ней Вы можете получить доступ с закладки "История регистраций" справочника "Сайты". Там же можно получить отчет о регистрации.

Скорее всего сделаем в настройках сайта еще одну опцию - ведение истории регистраций (не вести, только успешные, полный учет).

когда закроете проблему с автораспознованием и поиском одинаковых форм? - все это + пакетная регистрация у меня не работает

Я уже разбил базу на папки по 1,5 - 2 тыс. каталогов - не помогло