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

[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 клиент.

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