@frontend_coder Проверяй количество элементов в ресурсе, если 0 - закрывай поток с ошибкой без перезапуска потока.
spoiler
@bablouser Здесь есть 2 момента, которые можно оптимизировать.
Создание отдельного потока для хттп клиента. Я сделаю так, чтобы он не создавался, а запросы работали через curl_multi_perform.
Использование регулярных выражений. Вы можете значительно повысить производительность уже сейчас если будете использовать xpath из модуля http клиент.
Что вы можете попробовать еще - это не пересоздавать поток, так как ресурсы тратятся еще и на это.
Если у вас большой скрипт с множеством запросов, то это будет и так работать, потоки будут пересоздаваться редко.
Если вы для тестирования помещаете в проект всего лишь одно действие, то потоки будут пересоздаваться постоянно, что создаст дополнительную нагрузку.
На видео показана работа в 1000 потоков, интерфейс не тормозит.
https://www.youtube.com/watch?v=FTygVfSyqoM
@bablouser знакомая ситуация. для начала мне помогло обернуть все в
while (true)
дабы все перезапуски потоков, и каляки маляки в лог не юзались от слова совсем, а вместо фэйла и успеха юзался переход к метке в начале. (ток надо notreuse на все ресурсы поставить).в онаплике сделал глобальную переменную и добавил задержу перед циклом
if ([[GLOBAL:VAR]] < 100) {
sleep(thread_number() * 1000 - 1000)
[[GLOBAL:VAR]] = [[GLOBAL:VAR]] + 1
}
в итоге полетело
@artihorror сделал аналогично, да вариант вполне летабельный, зависания пропали на 50 % жить можно ) скрипт стал работать быстрее
каляки маляки теперь не выводятся в лог что радует глаз )
@support said in Более 100 потоков BAS задыхается.:
@bablouser Здесь есть 2 момента, которые можно оптимизировать.
Создание отдельного потока для хттп клиента. Я сделаю так, чтобы он не создавался, а запросы работали через curl_multi_perform.
Использование регулярных выражений. Вы можете значительно повысить производительность уже сейчас если будете использовать xpath из модуля http клиент.
Не подскажите как реализовать первый вариант?