Более 100 потоков BAS задыхается.

[BabloUser]

@ruzne потребление реcурсов у меня не выходит за предел 30 % по всем ресурсам цп, ram, чтение запись харда я не пробывал до 10 к потоков мне бы 1000 всего )
согласись это не дело скрипт по факту ничего не делает и в каком то месте потребляет ресурс я так и не понял где это узкое место у него на чем он валиться.

[ruzne]

@BabloUser
и не стоит забывать про js, каждый поток - функция(и кст не одна), каждая функция объект, объект - структурированные данные, довольно сложные, которые нужно хранить, так что про то что он ничего не делает говорить нельзя
я думал дело в четверге
ничего не знаю, но возможно существуют ограничения на количества соединений операционной системы например или еще чего

[BabloUser]

@ruzne это понятно что js но суть в том что вычислительная операция не грузит процесор что дает понять что задача успевает обрабатываться, дело точно не в четверге это возможно пятница для тех кто работает на 10 потоках они начинают с пятницы и до понедельника а моя задача тут и сейчас. Если есть ограничение на сокеты тут парень включай голову и думай еще раз почему анологичный софт, те же запросы шлет и лихо поднимает 1000 + соединений без единого пука.

[ruzne]

@BabloUser
да я думаю perl/lwp, ничего не помешало мне как запустить его из бас так и вернуть результат в зад, штаричок
для всякого нужно выбирать правильный инструмент, я например сегодня 5 шкантов забивал в отверстия плоскогубцами, но если бы мне нужно было бы заколотить их сотню, я бы поднялся на пару этажей выше и взял киянку.

[BabloUser]

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

Интересно как ты прокомментируешь заявленое разработчиком на промо странице.

"Очень быстрый и оптимизированный http клиент (до 2000 потоков)
Увеличьте скорость ваших скриптов с помощью http-клиента."

правильный инструмент говоришь?

[venom777]

Я делал похожий фидбек о производительности в многопотоке.

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

Сходу могу предложить такие варианты для тестов

• поменять время работы потока (если сейчас поток отрабатывает за 10 минут то сделать так что бы он отрабатывал за 1 минуту и наоборот);
• разбить один скрипт с 1к потоков на 4 копии по 250 потоков.

[DrPrime]

Дело в оптимизации скрипта.
Я свободно запускаю 2к потоков на запросах, и дажн с node js в каждом потоке.
Попробуйте запускать потоки пачками, может поможет

[BabloUser]

@DrPrime а можешь скинуть простой любой пример на запросах который у тебя запускается и нормально отрабатывает на 2 к потоках.

[BabloUser]

@venom777 в самом первом комменте последовательность. У тебя не похожее у меня ресурсов с лихвой остается если на 1000 потоков выкрутить. У меня вообше нет проблем с производительностью и нехваткой ресурсов я уже тут язык пообил об этом. Трабла в том что бас ЗАВИСАЕТ на обычном GET запросе на 1000 потоках ПРИ ЭТОМ ВСЕ РЕСУРСЫ ЖЕЛЕЗА ЗАНЯТЫ МАКСИМУМ НА 30%

"разбить один скрипт с 1к потоков на 4 копии по 250 потоков"

пока решил свою проблему запуском несколько экземпляров одновременно по 200 потоков, но это не дело...

[ruzne]

@BabloUser
не могу отрицать что действительно среда
это же как надо чтобы гвоздь от шканта не отличить? все же просто, гвозьди забиваются микроскопом, в крайнем случае кулькулятором.
будет ли мое предположение верным если я представлю что данные для чека берутся из от кудато(базы данных или допустим файла)
12 миллионов врятли поместтся в ресурсе значит это база данных и если она то встроенная раз необходимо использовать исключительно бас ну или чтение из файла, я пот например ранее пытался почитать басом файл на 30ГБ, бас у меня заканчивался вместе с оперативной памятью.
для простоты допустим все-таки внутренняя база данных как и у меня на 200К+ записей
и логикак опять же, допустим такая же как и у меня - из базы берется строка, чтото происходит(гет-запрос + простая регулярка или xpath), строка в базе изменяется\дописывается/перезаписывается.
я думаю то тогда бутылковое горлышка в поиске\чтении\записи в базу.
аргументы такие - имел по выше описаной схеме, причем данные обрабатывал в три этапа, трижды искал, трижды полуал и столько же перезаписывал, при том процесс бас 3-5% на процессор немного оперативки, совсем висит, процесс базы 25-30% процессора.
решил уменьшить количество действий с базой данных, ну и раз это то в три раза, логика посредине усложнилось, обращений к базе данных на еденицу времени уменьшилось.
итак: не то бы что не весит, так подвисает конечно, но загрузка всего на 100% со всех сторон, ну дак ладно там 150 браузеров. окно программы отзывчивое и вообще замечательное. подвисает как раз в тот момент когда большинство потоков переходит в такой режим что сложная логика по средине отсекается браузер не используется и происходят частые обращения к базе данных. общяя нагрузка на системе падает а окно баса вывешивается.
вопрос как оптимизировать работу с базой данных при обработке большого количества записей, я вот понимаю что если я бы брал с базы данные большими страницами а не построчно было бы пошустрее, а как добовлять и главное модифицировать записи в больщем количестве.

[support]

@bablouser

https://community.bablosoft.com/topic/949/часто-задаваемые-вопросы

Что делать если основной интерфейс БАС подвисает?
http://community.bablosoft.com/post/16933

[support]

@bablouser Здесь есть 2 момента, которые можно оптимизировать.

1. Создание отдельного потока для хттп клиента. Я сделаю так, чтобы он не создавался, а запросы работали через curl_multi_perform.

2. Использование регулярных выражений. Вы можете значительно повысить производительность уже сейчас если будете использовать xpath из модуля http клиент.

[support]

Что вы можете попробовать еще - это не пересоздавать поток, так как ресурсы тратятся еще и на это.
Если у вас большой скрипт с множеством запросов, то это будет и так работать, потоки будут пересоздаваться редко.
Если вы для тестирования помещаете в проект всего лишь одно действие, то потоки будут пересоздаваться постоянно, что создаст дополнительную нагрузку.
На видео показана работа в 1000 потоков, интерфейс не тормозит.
https://www.youtube.com/watch?v=FTygVfSyqoM

[artihorror]

@bablouser знакомая ситуация. для начала мне помогло обернуть все в

while (true)

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

if ([[GLOBAL:VAR]] < 100) {
    sleep(thread_number() * 1000 - 1000)
    [[GLOBAL:VAR]] = [[GLOBAL:VAR]] + 1
} 

в итоге полетело

[BabloUser]

@artihorror сделал аналогично, да вариант вполне летабельный, зависания пропали на 50 % жить можно ) скрипт стал работать быстрее
каляки маляки теперь не выводятся в лог что радует глаз )

[Phoenix]

@denis_krsk 100 потоков вероятнее работают быстрее чем 1000.... Что то другое хотели сказать?

[BabloUser]

@support да именно, интерфейс тормозил из за перезапусков так как поток отрабатывал за 5 сек, закинул все теперь в цикл. Полет нормальный.

[vndes43ta]

@support said in Более 100 потоков BAS задыхается.:

@bablouser Здесь есть 2 момента, которые можно оптимизировать.

1. Создание отдельного потока для хттп клиента. Я сделаю так, чтобы он не создавался, а запросы работали через curl_multi_perform.

2. Использование регулярных выражений. Вы можете значительно повысить производительность уже сейчас если будете использовать xpath из модуля http клиент.

Не подскажите как реализовать первый вариант?