@UserTrue
Когда искал по форуму, часто встречал ответы этого пользователя. Если найдется минутка, поделитесь опытом. Пока выделил два возможных решения замены curl http. Может есть еще варианты? Какой вариант для вас лучше?
Более 100 потоков BAS задыхается.
-
Господа, имеем обычную задачу get запрос на ip адрес, получаем контент, регуляркой забираем значение, выводим в лог, при 100-200 потоках вроде идет нормально, пробывал увеличивать потоки до 500 -1000 bas начинает зависать и сильно тормозить приходиться выбивать его через закрытие процесса, так как его окно повисает намертво при этом процессор, диск, память и канал заняты не выше 30 %, в чем проблема?
-
Ну так а ты что хотел, либа используй запросы, либа сервак нужен мощьнее. иначе не как
-
@Eva Он же написал, что get запросы использует ))
-
@BabloUser Бывает, что 100 потоков работают эффективней и быстрей, чем 1000. Можешь попробовать не выводить в лог. Заметил, что когда большой объем в лог идет бас подвисает
-
@Denis_krsk да заметил, запись в лог пишется же в фаил, там нагрузка на хард,
к слову, дело не в серваке, железо топое стоит, канал гигабитный, анологичные софты на тех же запросах летаю на 1000 потоках. дело именно в басе не могу заюзать скрипты в овер много потоках, и от этого становиться грустно. Проблема глобальная, нужно рапортовать, ибо серьезные люди работа с серьезным количеством потоков. Где именно срабатывает эффект узкого горлышка, не могу выявить, поэтому и запостил сюда, может кто-то как то решал такую траблу. А сказать что нужно уходить на свой код это не дело, мне нравиться BAS по этому и рапортую. 100 потоков против 1000 они кажутся как бы быстрее выполняются это да но сравнить сторонние чекеры-мекеры сделанные школьниками на делфи бас сильно проигрывает по скорости. И это не дело господа.12 лямов доменов чекаю на 200 потоках 3и сутки и плачу...
мысль всегда была как бы отключить запись в лог элементарные sucess и fail и может из за этого тупняк.
-
@BabloUser Заменяй регулярки, они кушают много ресурсов. Ещё для проверки попробуй сделать работу в 100 потоков и запустить 10 скриптов. Возможно дело в среде.
-
просто создание потока потребляет приличное количество ресурсов, если пустой скрипт ничего кроме ждания(случайное время) не даелающий в 1000 потоков еще может завершится, то 10000 потоков отедает ядро моего и5 через край и хавает 5 гигов оперативки, дальше я его прибил ибо быть беде
upd: и не случайное врем тоже(тоже 5 гигов) -
@ruzne потребление реcурсов у меня не выходит за предел 30 % по всем ресурсам цп, ram, чтение запись харда я не пробывал до 10 к потоков мне бы 1000 всего )
согласись это не дело скрипт по факту ничего не делает и в каком то месте потребляет ресурс я так и не понял где это узкое место у него на чем он валиться. -
@BabloUser
и не стоит забывать про js, каждый поток - функция(и кст не одна), каждая функция объект, объект - структурированные данные, довольно сложные, которые нужно хранить, так что про то что он ничего не делает говорить нельзя
я думал дело в четверге
ничего не знаю, но возможно существуют ограничения на количества соединений операционной системы например или еще чего -
@ruzne это понятно что js но суть в том что вычислительная операция не грузит процесор что дает понять что задача успевает обрабатываться, дело точно не в четверге это возможно пятница для тех кто работает на 10 потоках они начинают с пятницы и до понедельника а моя задача тут и сейчас. Если есть ограничение на сокеты тут парень включай голову и думай еще раз почему анологичный софт, те же запросы шлет и лихо поднимает 1000 + соединений без единого пука.
-
@BabloUser
да я думаю perl/lwp, ничего не помешало мне как запустить его из бас так и вернуть результат в зад, штаричок
для всякого нужно выбирать правильный инструмент, я например сегодня 5 шкантов забивал в отверстия плоскогубцами, но если бы мне нужно было бы заколотить их сотню, я бы поднялся на пару этажей выше и взял киянку. -
@ruzne может ты лютый строитель но ты невнимателен выше для тебя написано предлагать уходить с баса на код это не суть данного поста, пока тут только два адекватных ответа от FOX и Denis_krsk от тебя лишь изошла в чистом виде хуцпа про гвозди и дни недели.
Интересно как ты прокомментируешь заявленое разработчиком на промо странице.
"Очень быстрый и оптимизированный http клиент (до 2000 потоков)
Увеличьте скорость ваших скриптов с помощью http-клиента."правильный инструмент говоришь?
-
Я делал похожий фидбек о производительности в многопотоке.
Тебе стоит последовательно рассказать какие действия выполняются в скрипте, это то с чего нужно начать разбирать проблему.
О логировании - это действительно грузит цп, я выключал вывод в лог и результаты, это немного помогло с зависаниями.Сходу могу предложить такие варианты для тестов
- поменять время работы потока (если сейчас поток отрабатывает за 10 минут то сделать так что бы он отрабатывал за 1 минуту и наоборот);
- разбить один скрипт с 1к потоков на 4 копии по 250 потоков.
-
-
@venom777 в самом первом комменте последовательность. У тебя не похожее у меня ресурсов с лихвой остается если на 1000 потоков выкрутить. У меня вообше нет проблем с производительностью и нехваткой ресурсов я уже тут язык пообил об этом. Трабла в том что бас ЗАВИСАЕТ на обычном GET запросе на 1000 потоках ПРИ ЭТОМ ВСЕ РЕСУРСЫ ЖЕЛЕЗА ЗАНЯТЫ МАКСИМУМ НА 30%
"разбить один скрипт с 1к потоков на 4 копии по 250 потоков"
пока решил свою проблему запуском несколько экземпляров одновременно по 200 потоков, но это не дело...
-
@BabloUser
не могу отрицать что действительно среда
это же как надо чтобы гвоздь от шканта не отличить? все же просто, гвозьди забиваются микроскопом, в крайнем случае кулькулятором.
будет ли мое предположение верным если я представлю что данные для чека берутся из от кудато(базы данных или допустим файла)
12 миллионов врятли поместтся в ресурсе значит это база данных и если она то встроенная раз необходимо использовать исключительно бас ну или чтение из файла, я пот например ранее пытался почитать басом файл на 30ГБ, бас у меня заканчивался вместе с оперативной памятью.
для простоты допустим все-таки внутренняя база данных как и у меня на 200К+ записей
и логикак опять же, допустим такая же как и у меня - из базы берется строка, чтото происходит(гет-запрос + простая регулярка или xpath), строка в базе изменяется\дописывается/перезаписывается.
я думаю то тогда бутылковое горлышка в поиске\чтении\записи в базу.
аргументы такие - имел по выше описаной схеме, причем данные обрабатывал в три этапа, трижды искал, трижды полуал и столько же перезаписывал, при том процесс бас 3-5% на процессор немного оперативки, совсем висит, процесс базы 25-30% процессора.
решил уменьшить количество действий с базой данных, ну и раз это то в три раза, логика посредине усложнилось, обращений к базе данных на еденицу времени уменьшилось.
итак: не то бы что не весит, так подвисает конечно, но загрузка всего на 100% со всех сторон, ну дак ладно там 150 браузеров. окно программы отзывчивое и вообще замечательное. подвисает как раз в тот момент когда большинство потоков переходит в такой режим что сложная логика по средине отсекается браузер не используется и происходят частые обращения к базе данных. общяя нагрузка на системе падает а окно баса вывешивается.
вопрос как оптимизировать работу с базой данных при обработке большого количества записей, я вот понимаю что если я бы брал с базы данные большими страницами а не построчно было бы пошустрее, а как добовлять и главное модифицировать записи в больщем количестве. -
https://community.bablosoft.com/topic/949/часто-задаваемые-вопросы
Что делать если основной интерфейс БАС подвисает?
http://community.bablosoft.com/post/16933
