Пара гвоздей в гроб html browser-based приложений

[f_evgeny]

tengiz, вспоминается что на VAX вообще не было ограничения по стеку. То есть он и аллокировался по необходимости (по page faults), и рос не обязательно непрерывно физически (но конечно непрерывно в физическом адресном пространстве).

А то что я видел столько threads... похоже это было от SQL servers... Очевидно те ребята которые писали SQL server знали про мегабайт

Вообще я не знал о таком ограничении. А в Пингвинах как с этим ?

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

[Gennadiy]

А что за проблемы такие?
У меня не то что бы проблем не было, но к чему то что грязным хаком назвать можно не приводило.

У нас наверно разные понятия о том что называть "грязным хаком". Я например засовывание данных в hidden text box с читаю таковым.

[geek7]

evgeny, какие отдельные модули ? какие удобства многопользовательской работы ?
Это отдельные модули которые данные друг к другу тащат через сотни перемнных в Session.

Dmitry67, Вам просто неповезло с программистами

[tengiz]

Вообще я не знал о таком ограничении. А в Пингвинах как с этим ?

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

[tengiz]

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

[A. Fig Lee]

в общем, гвозди какието ржавые - не лезут.

[Strannik223]

А что за проблемы такие?
У меня не то что бы проблем не было, но к чему то что грязным хаком назвать можно не приводило.

У нас наверно разные понятия о том что называть "грязным хаком". Я например засовывание данных в hidden text box с читаю таковым. :wink:

Ага, один случай кажется вспомнил.
Была у меня страничка, на которой надо было редактировать custom fields, которые находились в некоторых зависимостях с другими элементами системы, они могли быть разных типов, некоторые типы были композитными, то есть состояли из перечислений.
Одним словом когда я реализовал 25% функционала на hidden fields & JavaScript Array, я понял что уйду на пенсию раньше чем допишу это кровавое мессиво.
И тогда я сделал смелый финт ушами. Написал Xml Schema описывающую все данные и связи между ними, и передал на клиент все в оном Hidden field. На клиенте в OnLoad() я создавал XmlDocument и парсил этот hidden. В результате любые действия с данными, включаю модификацию выражались в паре простых и понятных XPath.

[tengiz]

tengiz, вспоминается что на VAX вообще не было ограничения по стеку. То есть он и аллокировался по необходимости (по page faults), и рос не обязательно непрерывно физически (но конечно непрерывно в физическом адресном пространстве).

Это ничем не отличается ни от мастдай, ни от пингвина. Только мастдай и пингвин могуть иметь много стеков в одном адресном пространстве размером 4GB, а VAX - не мог. Так как VAX-процесс не был многопоточным, то ему нужен был всего один стек на процесс. Поэтому у VAX физическая память + подкачка заканчивались намного раньше, чем виртуальные адреса. У мастдай и пингвина, особенно когда на машине много физической памяти, часто бывает наборот - физическая память ещё есть, а поток создать нельзя. Просто потому, что для его стека в адресном пространстве больше нет незанятого непрерывного региона подходящего размера.

[Big Cheese]

Я сейчас зашел на сервер, он показывает в спокойном состоянии 1300 threads. В Военное время я видел до 5000-6000 threads...

Видимо, SQL Server (речь ведь идет о нем?) использует меньший размер стека.

Дмитрий, не поделитесь соображениями, чем обосновано такое громадное количество серверных потоков? Это default settings для SQL Server'а или это Вы сами настраивали? Мне, например, не очевидно, каким образом сервер с 5000 threads будут работать быстрее, чем, например, с 100-200? Если, конечно, большинство из них не ждет 90% временм на блокировках. Любопытно бы было посмотреть, например, сколько Ваш сервер делает context switches/sec под нагрузкой.

[f_evgeny]

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

Я писал про процессы и про физические страницы.

[Dmitry67]

Почему много threads не знаю
У нас много процессов на сервере, в том числе 4 sql server (знаю что это плохо, устал повторять нашим админам)
Context switches во время теста доходило до 30K в секунду
Правда по моему жто был IIS

Заглянул к себе на лаптом, 442 threads
442Mb только на стек ?

[f_evgeny]

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

Только у пингвина необязательно писать на потоках.

[tengiz]

Я писал про процессы и про физические страницы.

Ну так вопрос бы специфически про стек и про ограничение на максимальное количество потоков со стеком умолчального размера, разве нет? Боюсь, что я не вижу связи этого вопроса с тем, что Вы писали. Оно, конечно, близко, но не то.

[tengiz]

Только у пингвина необязательно писать на потоках.

Here we go again... - но нет, я в эти вязкие дискуссии непонятно о чём больше не влезаю.

[f_evgeny]

Только у пингвина необязательно писать на потоках.

Here we go again... - но нет, я в эти вязкие дискуссии непонятно о чём больше не влезаю.

Вы сказали, я ответил. Для меня разница ясна, для Вас, думаю тоже.
Тут недавно я провел серию тестов Windows/Apache/IIS vs Linux/Apache, которые только подтвердили мои взгляды насчет того, как должны отличаться приложения, написанные для этих платформ.
Кстати, Тенгиз, я наблюдал интересный эффект на W2K, Вы можете его объяснить? При нагрузке вебсервера, работающего на платформе w2k (неважно IIS, или Apache) и запускающего CGI, при загрузке процессора 100% на K6-600 через каждые секунд 10-20 (пишу по памяти) возникают паузы в обработке с падением нагрузки до 0% и сдлительностью до 1-3 с.
При работе на PIII-733x2, падений до нуля нет, но на графике таск менеджера видны "зубчики" до процентов 50%. Интересно, что это такое?

[Dmitry67]

Зубчики я списывал на garbage collection
Только они в другую сторону и приводят к повышению CPU

[tengiz]

При нагрузке вебсервера, работающего на платформе w2k (неважно IIS, или Apache) и запускающего CGI, при загрузке процессора 100% на K6-600 через каждые секунд 10-20 (пишу по памяти) возникают паузы в обработке с падением нагрузки до 0% и сдлительностью до 1-3 с.
При работе на PIII-733x2, падений до нуля нет, но на графике таск менеджера видны "зубчики" до процентов 50%. Интересно, что это такое?

Нет, к сожалению я так не могу сказать - нужно смотреть на дюжину perfmon счётчиков, чтобы что-то правдоподобное предположить. У Windows нет никаких причин делать что-либо подобное, если приложение написано аккуратно и проектируется с расчётом на длительную и устойчивую пиковую нагрузку. Например, при 8-часовом прогоне монстровых TPC-C тестов практически при 100% нагрузке всех процессоров и при практически полном насыщении подсистемы ввода вывода никаких "зубчиков" я не наблюдал. Несколько тысяч транзакций в секунду пролетают стабильно и гладко после недолгой начальной фазы "устаканивания".

[f_evgeny]

При нагрузке вебсервера, работающего на платформе w2k (неважно IIS, или Apache) и запускающего CGI, при загрузке процессора 100% на K6-600 через каждые секунд 10-20 (пишу по памяти) возникают паузы в обработке с падением нагрузки до 0% и сдлительностью до 1-3 с.
При работе на PIII-733x2, падений до нуля нет, но на графике таск менеджера видны "зубчики" до процентов 50%. Интересно, что это такое?

Нет, к сожалению я так не могу сказать - нужно смотреть на дюжину perfmon счётчиков, чтобы что-то правдоподобное предположить. У Windows нет никаких причин делать что-либо подобное, если приложение написано аккуратно и проектируется с расчётом на длительную и устойчивую пиковую нагрузку. Например, при 8-часовом прогоне монстровых TPC-C тестов практически при 100% нагрузке всех процессоров и при практически полном насыщении подсистемы ввода вывода никаких "зубчиков" я не наблюдал. Несколько тысяч транзакций в секунду пролетают стабильно и гладко после недолгой начальной фазы "устаканивания".

Недавно то же самое я делал с MySQL, там ничего подобного нет.
Поскольку:
а) Эффект наблюдался на трех различных приложениях (Apache 1.x, Apache 2.x, IIS) и на различных платформах.
б) На четвертом приложении (MySQL) эффект не наблюдался.
Разница в режимах работы между а) и б) - та, что в случае а) происходило открытие/закрытие соединений, в случае б) - все запросы шли по одному соединению.
Подозрение падает на закрытие/открытие сокетов. Что думаете?

[Big Cheese]

Почему много threads не знаю
У нас много процессов на сервере, в том числе 4 sql server (знаю что это плохо, устал повторять нашим админам)
Context switches во время теста доходило до 30K в секунду
Правда по моему жто был IIS

Т.е. у Вас 6К threads всего в системе, а не в одном процессе? Тогда, конечно, другой разговор. Хотя 30К context switches все равно как-то многовато...

Заглянул к себе на лаптом, 442 threads
442Mb только на стек ?

Опять же - 442 threads в _одном_ процессе? А так -да, 442MB _адресного_пространства_. Тенгиз же весьма подробно расписал механику этого дела

[Dmitry67]

f_evgeny
А у Вас есть connection pooling ?
А если нет... а может это торомза со стороны DNS ? При установлении коннекции идет определение по имени сервера... тут все и встает

Big Cheese
Нет, всего на лаптопе
В task manager?Performance там где Handles/Threads/processes

[Big Cheese]

Big Cheese
Нет, всего на лаптопе
В task manager?Performance там где Handles/Threads/processes

В task manager'е Handles/Threads - system wide. Я пользуюсь Process Explorer от SysInternals - очень удобная утилитка.

[Dmitry67]

EXE -> WEB -> снова EXE
Воистину,

Никогда не догоняйте
Устремившихся вперед.
Через пять минут, ругаясь,
Побегут они обратно,
И тогда, толпу возглавив,
Вы помчитесь впереди.
(c) Остер

[Palych]

EXE -> WEB -> снова EXE

Eto pro vash project, ili voobsche?

[Dmitry67]

Вообще

[Palych]

Вообще

Я думаю - не все так просто.
Я вижу следующие требования к современному распределенному приложению.

1. Наличие серверной части (middleware), которая выполняет основную работу по виниманию данных и их обработке (вопрос как хранить данные оставляем за скобками).
На выходе данные должны быть представлены полно, но без излишеств в ХМЛ, или другом древовидном формате. Без етого компонента реализация понастоящему масштабируемого приложения физически невозможна.

2. Далее надо предоставить клиенту возможность работать с етими данными через гибкий, функциональный и угобный ГУЙ. Причем желательно предоставить выбор уровня детализации етого гуя (толстый клиент, браузер, мобила). Правда в мне трудно с ходу придумать приложение, для которого бы понадобулись все уровни детализации, но наверное такие есть...
Здесь намечаются 2 пути:
2.1 Продолжение дела HTML, раздутие его до чего-то типа XUL, чтобы меть возможнисть описывать мощные гуи чисто декларативно. Однако опыт показывает что без кода на стороне клиента не обойтись.
А там где код - встает вопрос на чем его писать? Язык должен быть переносимым, чтобы не мучаться с многообразием клиентов, и в то же время достаточно еффективным на всех платформах. XUL позволяет выбирать язык для клиентской части, но по большомы с чету ето не помогает, а превращает приложение в лоскутное одеяло, особенно когда надо синхронизировать изменения в серверной и клиентской части кода.
2.2 Написание самого обычного гуевого приложения и запуск его на клиенте. Для обеспечения переносимости можно просто иметь версии под разные платформы, выжимая максимум из каждой из них, или иметь виртуальную машину на манер ява.

3. Чтобы избавить клиента от необходимости устанавливать софт на звоем компьютере, необходим механизм доставки кода с сервера на клиента и поддержки актуальной версии Вобщем то что делает Java Web Start.