Живая связь двух скриптов **BAS**

[Fox]

@artihorror На счёт -1 спасибо, не знал. А на счёт скриптов и css, попробуй *.css и *.js .

[artihorror]

@Fox работает, но слишком много экшенов)0) погоняю отпишу о том как повлияло.

[artihorror]

@Fox танцы с бубном вокруг запретов помогли снизить нагрузку на процессор до 3-3.7% вместо 7-12%
Для блокировки всех изображений хватает *img;
Из минусов: от копания в коде страницы убежать не удалось. *сss, *js блочат все под чистую и для отображения капч или важных всплывающих окон приходится искать и разрешать их запросы. Только для рекапчи их 4 - а это 4 экшена, в проекте появляются лишние действия и функции.

[DrPrime]

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

[Zenodrot]

@artihorror said in Живая связь двух скриптов **BAS**:

@Fox said in Живая связь двух скриптов **BAS**:

@artihorror said in Живая связь двух скриптов **BAS**:

@Fox 8х2.5 Это в смысле восьмиядерный проц с частотой 2.5 гигагерца?

именно такой.

по обнулению переменных имеет смысл только если ложишь в нее что нибудь весом в несколько десятков мб. Пришлось раз обрабатывать басом текстовик весом 8гб, озу забивалась моментально и только обнуление спасало. А мелочь в сотню кб, даже если все 300 потоков не особо влияет. отпечаток весит 160 кб в среднем, выгружая его освободишь 45 мб рамы в 300 потоков.
Интересно как снизить нагрузку на процессор, какие действия нагружают его. Выше писали что обращение к файловой системе сильно влияет на процессор - отчасти так, но влияние мизер. Храню куки в текстовиках , при обращении нагрузка потока на проц с 0.1% повышается до 0.2% и то на мгновение. Но при загрузке страниц может нагрузить до 7-12% с пропуском кадров в 500. Фича по отключению скриптов и css, запрет загрузки картинок и еще пара плюшек как у зенки (не помню что еще там отключается у браузера) неплохо бы так улучшило производительность

80 потоков, запускаются с интервалом в 3 сек дабы распределить нагрузку. пики в момент начала загрузки страниц 40-45 потоков. при работе на странице нагрузка падает до 40-50%, при следующей загрузке страницы процессор снова потеет.

на проц более всего влияет вычислительные операции, регулярки, обшение между переменными, обработка кода в браузере, скриптов и т.п,в идеале нужно сводить на минимум операции в шабе иногда одна грамотно построяная операция, заменит 10 лишних движений.
Я уже давно отказался от комбайнов, клепаю по минимуму но много разных шаблонов ИМХО их и править удобнее.

[DrPrime]

@Zenodrot said in Живая связь двух скриптов **BAS**:

перации в шабе иногда одна грамотно построяная операция, заменит 10 лишних движений.
Я уже давно отказался от комбайнов, клепаю по минимуму но много разных шаблонов ИМХО их и править удобнее.

самая большая нагрузка на проц во время открытия браузера, поэтому рекомендуется при большом количестве потоков ставить паузы между запусками.
Например у меня на виртуалке с 2*2ггц одновременный запуск 7 потоков вешает машину, с паузой в 1 секунду между стартом открытия браузеров - 30-40 одновременно работающих потоков, дальше уже упор в память.

По поводу памяти - с переходом на базу проблемы с памятью намного уменьшились, но есть нюанс. Если использовать базу как ресурс, то вся таблица будет храниться в памяти как и в случае с файлами, да и обновлять данные не удобно, так как потом приходится перегружать ресурс, что влияет на проц, да и на работу скрипта в целом.

Проблему решил, что в ресурс ложиться только колонка с моими id`шниками,
в скрипте я получаю этот id через парсить строку, вторым параметром там же получаю настоящий id в базе, потом просто через получить запись с фильтром по моему id получаю актуальные данные

[Zenodrot]

@DrPrime said in Живая связь двух скриптов **BAS**:

что хорошо, это то, что в памяти считывание и запись во много в раз быстрее чем с ХДД
что есть хороший прирост к производительности, главное ее сильно объемами инфы не грузить ну тут уже подгонять все под железо ибо кто то на 2 гигах сидит а кто то на 64 +

[artihorror]

@Fox @Zenodrot @DrPrime какие запросы нужно разрешить для корректной работы рекапчи? пока что так, но с ней появились проблемы.

все ошибки связаны с капчей, остальное отрабатывает на ура. производительность просто каеф, хоть все 300 пускай:3

[DrPrime]

@artihorror разреши что то типа *google* , поэкспериментируй с этим

[Zenodrot]

@artihorror солидарен с @DrPrime
гугл тянет за собой необходимые скрипты, МБ те скипты нужны для нормальной обработки
это нужно дебажить сидеть пол дня чтобы узнать какие точно
там всякие аналитические, поведенческие скипты, (они находяться на поддоменах) если им доступ закрыт он начинает тебе люто ненавидить

[artihorror]

@DrPrime *google* и *gstatic* решили проблему, спасибо

[denanotherday]

@Fox А если использовать одну и ту - же переменную для разных целей, если она не используется после первой цели.

[Fox]

@denanotherday Да, но не везде это приемлемо. Возможно где то дальше в логике скрипта тебе понадобятся данные из этой переменной. Да и работать с одной переменной в разных местах непрактично, можно просто забыть что в ней должно лежать.. Я уже молчу, если что нибудь не сработает, то весь скрипт дальше начнёт работать с данными из совершенно другого узла..

Мы как то проверяли, стоит ли очищать переменные, или это ни на что не влияет..

@artihorror said in Живая связь двух скриптов **BAS**:

по обнулению переменных имеет смысл только если ложишь в нее что нибудь весом в несколько десятков мб. Пришлось раз обрабатывать басом текстовик весом 8гб, озу забивалась моментально и только обнуление спасало. А мелочь в сотню кб, даже если все 300 потоков не особо влияет. отпечаток весит 160 кб в среднем, выгружая его освободишь 45 мб рамы в 300 потоков.

[denanotherday]

@Fox Был скрипт, когда я использовал разные переменные для одного действия (SAVED_TEXT_A, SAVED_TEXT_B и тд.), хотя можно было одну: то есть последующие, вложенные очищают предидущие. Нагрузка после ремикса уменьшилась.

[Fox]

@denanotherday Я и говорю, если вопрос стоит остро, то облегчать надо всё поголовно :D

Я тут ещё заметил, что если объявлять переменные простым:

var test = 123
а не
VAR_TEST = 123

То переменную test не будет видно в инспекторе переменных и при выборе из списка используемых переменных тоже. Это удобно, когда есть множество промежуточных переменных, которые могут засорять поиск.

[denanotherday]

@Fox Актуальны все способы.

[denanotherday]

Вышел новый apdate 20.5.1 !

[artihorror]

@denanotherday самый действенный способ это работа на запросах

[denanotherday]

@artihorror проблема с информацией по хттп, стрим недопонимаю, может есть простые скрипты с примерами.

[artihorror]

@denanotherday не встречал к сожалению примеров проще чем в стриме. Только практика нужна