Сообщений в теме: 17

[Svetlanka]

Доброе время суток!
При длительной непрерывной работе SilkTest с IE6 с какого-то момента открываемые страницы Browser'ом перестают нормально отображаться, вместо содержимого появляется черный экран, или загружается только часть содержимого.По наблюдениям, видно было, что GDI objects к этому моменту приблизились к 10000.
Товарищи, знатоки, и не очень, может кто сталкивался с подобной проблемой?
Подскажите, как быть в данной ситуации?

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

Заранее благодарю!

[KaNoN]

А не проверяли, может страницы просто долго подгружаются? В этом случае нужно просто поставить ожидание догрузки страницы. Это делается посредством

Browser.WaitForReady()

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

[Genka]

попробуйте изменить параметр в реестре

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\GDIProcessHandleQuota

он по умолчанию = 10000
хотя не факт, что поможет, но попробовать стОит

поиск в инете говорит, что хотя этот параметр как раз служит для увеличения максимального количества GDI объектов, все равно проблемы появляются при достижении 10000

возможно, что в последних версиях винды это исправлено

[Genka]

а, ну и ссылочка вдогонку

http://support.micro...kb;en-us;327699

[Svetlanka]

KaNoN, было бы все слишком просто, если б она не догружалась, однако Browser реально начинает работать нештатно.
Genka, спасибо за ссылочку. Попробую применить.

[KaNoN]

Да, и поскольку это веб-приложение, то в нем можно несколько ограничить количество распознаваемых объектов. В частности как правило HtmlHidden, HtmlMeta, XMLNode объекты в большинстве случаев не нужны, поэтому их распознавание можно отключить в диалоге настройки расширений. Так что это один из способов уменьшить количество используемых GDI объектов, что тоже может помочь в решении данной проблемы.

[Genka]

Не думаю, что это поможет, ведь количество GDI объектов, которые используются Explorer'ом не зависят от того, распознаем мы их в Силктесте или нет.

Это проблема именно Эксплорера. По ссылке, которую я привел выше, можно выяснить, что увеличить их количество можно с 10000 до 18000.

Т.е. все равно через какое-то время придется перезапускать эксплорер или еще что-то придумывать

[KaNoN]

А ну так если это проблемы эксплорера, то при чем тут СилкТест?
Более того, Эксплорер вообще неплохо бы перезапускать при старте каждого тесткейса. Я так стабильно делаю, так как каждый тесткейс стартует из некоторого начального состояния (зря что ли аппстейты придуманы?).

[vass]

Более того, Эксплорер вообще неплохо бы перезапускать при старте каждого тесткейса.

+1. Вообще по опыту работы с експлорером и всякими ajax - лучше всего тесткейс начинать из положения "все процессы iexplore.exe убиты, потом запущен один експлорер с базовым конкретным урлом (хотя бы about:blank)".
Ибо там эксплорер может заглючить, зависнуть, долго запускаться - что приводит к непредсказуемому поведению...

[KaNoN]

Вообще по опыту работы с експлорером и всякими ajax - лучше всего тесткейс начинать из положения "все процессы iexplore.exe убиты, потом запущен один експлорер с базовым конкретным урлом (хотя бы about:blank)".

Ээээ, может чуть переформулировать насчет процессов? Например, "все окна браузера закрыты" вместо "все процессы iexplore.exe убиты", а то найдутся любители килять процессы напрямую, а это может обернуться рядом нездоровых ситуаций с расширениями. Помнится одно время мы рубили подсистемы одного немаленького клиент-серверного приложения через встроенный таск-менеджер, после чего были проблемы с ActiveX-объектами. С браузерами подобная неприятность тоже имела место, может носила не столь систематический характер.

[vass]

А вот если браузер завис - то его только килять. Или руками что-то решать (что не есть позитивно).
Разумеется мы не изверги - сначала всем окнам предлагается Close() а только потом "кто не спрятался - я не виноват" .
(кстати, если помнишь, в том немаленьком клиент-сервере всем тоже предлагается сначала по доброму закрыться, и только потом отстреливают несознательных )

[KaNoN]

Повешенный браузер сильно картины не портит, на него Силк реагирует только когда надо будет по-новой позакрывать все окна браузеров. Если вспомнить тот немаленький клиент-сервер, то там для одного из его модулей была веб-версия, для которой я в свое время проводил нагрузочное тестирование (причем на чужом серваке, что вызывало частые звонки от вышестоящего руководства ). Так вот браузер тогда вешался раз через 3 на каждой машине ( из 20-ти ). Следующий аппстейт устранял это безобразие. Можно даже не спрашивать у него Close(). Я просто жал на браузере Alt-F4 (закрыв предварительно модальные окна поверх). Если не закрылся сразу, ну и черт с ним, закроется потом.

Беда в килянии процесса для браузера заключается в следующем:
1) Internet Explorer - это не единственный возможный браузер (есть еще Netscape, FireFox и еще чего-то), так что нужно дополнительно учитывать весь набор используемых браузеров (а точнее их имен процессов).
2) Киляние браузера может аффектить не только слет расширений, но и неприятности посерьезнее, вплоть до повешенья Агента (особенно если для браузера потом некоторые настройки выставляются динамически) или даже системы.

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

[vass]

подвисший эксплорер (да и любое другое окно), который "отвесится" через полчаса и зааффектит хороший ТК = это уже потенциально аварийная ситуация. Насчет других браузеров - в процессах все равны (ищи и киляй firefox.exe и т.д.). Напиши хороший аппстейт один раз и не парь голову.
Конечно может асинхронная отсылка Alt-F4 поможет больному, но я бы не откладывал дело в долгий ящик. Тем более, что зря работающий клиент зря загружает сервер.
Ну а насчет Агента - его тоже можно перестартовать, если что

[KaNoN]

подвисший эксплорер (да и любое другое окно), который "отвесится" через полчаса и зааффектит хороший ТК = это уже потенциально аварийная ситуация

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

Насчет других браузеров - в процессах все равны (ищи и киляй firefox.exe и т.д.). Напиши хороший аппстейт один раз и не парь голову.

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

Ну а насчет Агента - его тоже можно перестартовать, если что

Да да да, мы так ActiveX-ы реанимировали на том немаленьком клиент-сервере
Хм ... никогда не пробовал, но вот стало интересно, а если агент запущен удаленно, его можно будет прибить и запустить на той же машине? Не будет каких-либо неприятностей?

[vass]

Хм ... никогда не пробовал, но вот стало интересно, а если агент запущен удаленно, его можно будет прибить и запустить на той же машине? Не будет каких-либо неприятностей?

можно. причем - автоматически. Лишь бы на удаленной машине тулы (для поиска и убиения процессов) работали. Единственно - нужно чтобы у агентов были все время разные номера портов (в принципе можно диапазоны забронировать).

[KaNoN]

Это типа, чтобы на удаленке было запущено 2 Агента и как только прибивают одного, то потом переключаемся на 2-й и стартуем нового Агента?

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

[vass]

увы. Если код достаточно простой (всего-то : переключение между двумя агентами), а они выравнивают себе извилины - значит извилины такие были изначально.
Во-вторых : а фигли лазить в стабильно работающий аппстейт ?

[KaNoN]

увы. Если код достаточно простой (всего-то : переключение между двумя агентами), а они выравнивают себе извилины - значит извилины такие были изначально.

Может быть и извилины изначально прямые. Но сама операция не совсем-таки проста и понятна с первого же взгляда. Эти агенты должны быть запущены сразу. Затем, переключение между Агентами - это не такая уже и частая операция, чтобы с ней быть знакомым в той же мере, как например, с функцией Print. Интенсивность использования заметно различается.

Во-вторых : а фигли лазить в стабильно работающий аппстейт ?

Если аппстейт чего-то не так сделает на стороне заказчика, то заказчик туда и полезет первым. При этом этот аппстейт мог бы быть вполне стабильно работающим на нашей стороне, поскольку окружение в котором работаем мы может отличаться от окружения, в котором запускает скрипты заказчик. Причем различия могут касаться не только различных настроек, но и способа запуска. Например, мы пишем скрипты, которые работают локально, а заказчик решил это запускать на удаленной машине ( причем об этом он вряд ли предупредит вообще ). Вот в этом случае окажется, что что-то придется подкрутить. И будет очень хорошо, если до этого кто-то со стороны заказчика ничего не подкручивал.