Отключите все лишнее на целевой странице если она одна, это реально сделать - например скрипты всяких фейсбуков, сторонней аналитики и так далее. Обычно сервесы используют много сторонних скриптов, которые не влияют на работу сайта, но сильно нагружают проц.
Смотрите как идет распределение нагрузки - возможно оно не сплашное, а пиками - тогда можно попробовать запускать потоки более равномерно. Чтоб избегать этих пиков.
Чаще всего можно отрисовку снизить вплоть до 10 (ну 20) .... На загрузку проца, это как раз сильно влияет.
Если сервер свой и без видюхи, то стоит поставить в него видюху.
50 в нынешних условиях для баса с браузером, достаточно много. Можно попробовать разбить на несколько копий баса по 25 например.
Можно использовать рам диск для работы с профилями - но это уже продвинутый уровень.
Чекер почт: производительность и ограничения
-
@tet-vivi said in Чекер почт: производительность и ограничения:
@unifier imap модуль в бас сырой
некоторые используют сторонние варианты(например кто то на node.js или на php или на гет запросах)В чём именно он "сырой", можно по подробнее?
@unifier said in Чекер почт: производительность и ограничения:
@tet-vivi однако мне до сих пор не понятно, почему на миллионе итераций программа останавливается
А вы установите параметр "Тип запуска" в "Повторять", сохраните проект и откройте его в текстовом редакторе:

и вы увидите, что при выборе этого режима стоит 1 миллион повторений, то есть конечное число.
Что бы ваш скрипт работал бесконечно, выберете значение параметра "Тип запуска" в "Особый" и установите количество успешных и неудачных выполнений в
-1 -
@unifier said in Чекер почт: производительность и ограничения:
@Fox спасибо, сейчас попробую. А что насчет производительности?
попробуйте запускать несколько копий скрипта одновременно (только обязательно из разных директорий)
-
@unifier said in Чекер почт: производительность и ограничения:
@Fox в нескольких инстансах баса?
Если вы используете нескомпилированные скрипты, то да
-
@Fox да, использую нескомпилированные. Однако еще вопрос: у меня при обработке миллиона около 550К собственно ошибки с неверным логином/паролем почты, а остальные почти 450 тысяч - это ошибки прокси. Как можно сделать так, чтобы после ошибки прокси проверка аккаунта запускалась еще раз?
Заранее проверять прокси не вариант - они автообновляемые по ссылке, а в БАСе, в отличие от приваткипера, функции автоперезапуска при ошибке прокси нет
-
@unifier said in Чекер почт: производительность и ограничения:
@Fox да, использую нескомпилированные. Однако еще вопрос: у меня при обработке миллиона около 550К собственно ошибки с неверным логином/паролем почты, а остальные почти 450 тысяч - это ошибки прокси. Как можно сделать так, чтобы после ошибки прокси проверка аккаунта запускалась еще раз?
Заранее проверять прокси не вариант - они автообновляемые по ссылке, а в БАСе, в отличие от приваткипера, функции автоперезапуска при ошибке прокси нет
Сделайте количество успешных выполнений 1, а неудачных, к примеру, 100. В случае с ошибкой логина\пароля завершайте поток успешно действием "Success", а в случае ошибки прокси, завершайте поток ошибкой
-
@unifier said in Чекер почт: производительность и ограничения:
@Fox у ресурса аккаунта количество успешных выполнений? Попробую, спасибо. Но как тогда в отчете увидеть количество гудов?
У вас успешно поток будет завершаться только в одном случае. Если скрипт более сложный, то можете создать счётчик из глобальной переменной. И да, брут почтовых аккаунтов - плохое дело
-
@unifier said in Чекер почт: производительность и ограничения:
@Fox в таком случае в ресурсе 'accounts' надо поставить жадный алгоритм или нет?
Нет, не обязательно