2 vdimas

автор писал:Когда ты научишься отвечать по-существу?

А что тебе отвечать по существу. Чем больше ты постишь, тем больше чуши в твоих постах.

автор писал:Существует ошибочное расхожее мнение, что если мы имеем только один объект - ADODB.Connection, но которым пользуются одновременно несколько открытых рекордсетов, то значит и реальный конекшн к базе только один. Чушь. Сколько открытых рекордсетов с приаттаченным коннекшеном, столько реальных конекшенов и открыто.

Вот еще один пример полной чуши. Не переноси то, что городит Access при работе с сиквелом (а именно беспорядочное открыти/закрытие коннектов), с нормально разработанным приложением, которое работает через один коннект. Ты чуствуется ни разу не видел нормальных приложений, работающих через один коннект. Более того, для реализации некоторых фичей в своих проектах я еще и пуллинг соединений отключал. Как инструмент для разработки рыбы Access еще потянет. Но серьезный проект ему не позубам.

2 tygra

Книгу таки придеться писать. :-)

Так, давненько я сюда не заглядывал.

2 vdimas

автор писал::) ты вообще хоть иногда в доки заглядываешь?

Disconnect Your Client Cursor from the Connection for R/O and Long-Use Scenarios
Disconnected Recordset objects are supported by the client cursor engine. Use this feature when you are performing a time-consuming operation that doesn't require expensive database resources to be held open. If you need to, you can later reconnect the Recordset to the connection to perform updates.

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

автор писал:насколько я понял, вы обращаетесь к базе из того же треда, в котором у вас работает основное GUI??? Да еще держите ПОСТОЯННО один глобальный конекшн открытым? Тогда все вопросы к вам немедленно снимаются, извините, конечно, но мы разговариваем на разных языках :)

Да, а что здесь не так. И почему это мы разговариваем на разных языках.


автор писал:Блин, ну меня умиляет это все У МЕНЯ ЕСТЬ ПОСТОЯННО ПОДКЛЮЧЕННЫЙ ОДИН КОННЕКТ, СМОТРИТЕ КАК Я КРУТ. мдя-я-я...

Ну если это ты так понял, то это твои проблемы.

автор писал:а при долгих запросах у нас приложение-то замирает и даже не прорисовывается...

Эт почему еще. ProcessMessage еще никто не отменял. И что значит долгие запросы. Может просто не надо таки запросы писать или уметь их оптимизировать.

автор писал:а грид мы показать не можем, пока к нему все запрошенные данные не придут. А все запросы исполняем только последовательно, один за другим. :)

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


автор писал:Видел такого, написанного именно на дельфи, вот так в лоб, предостаточно. Блин, один глобальный постоянно подключенный коннекшн. Ты еще в книгу это включи, для оболванивания населения.

Ты мне напомнил моего препада по вышке. Он нам так объяснял понятие не полной математической индукции. Вот идет бабка по улице и видит пьяный пацан валяется и делает вывод. Вот же, а, вся молодежь спилась. Вот и у тебя так получается.

автор писал:Мне даже трудно представить себе конфигурацию сервера, который бы выдержал более 2 тыс одновременно подключенных таких, с позволения сказать, "программ".

Представить очень легко, если знать, какие ресурсы сервера занимает одно открытое соединение. 64 Кб, если не ошибаюс. И что, это что по твоему нагрузка для сервера.

автор писал:Насчет задержек во время постоянных процедур подключения/отключения. Экспериментально установлено, что если с некоторой базой (именно базой внути инстанса сервака) работает только ОДИН пользователь, то после отключения на некоторое продолжительное время (точно не замерял, что-то около минуты-две), повторное соединие происходит с задержкой (2-3 сек).
Если же с ЭТОЙ базой работает одновременно несколько пользователей, то повторные подключения выполняются мгновенно, по крайней мере, субъективно не заметны оператору.

Ну так работает именно тот самый пуллинг.

автор писал:Оператор может заполнять один документ произвольное количество времени, и к чему все это время держать конект активным?

А он что у тебя текст в него набивает, что на время заполнения ему ни один справочник не нужен , читай коннект к базе.

автор писал:В 1999-м к моему SQL 7.0-серваку на Celeron-333 256M подключались сотни клиентов и спокойно работали. Кстати, вначале я тоже держал один коннект постоянно открытым. Пока работают десяток-другой клиентов - это не заметно. Но когда больше...

Атлично работает и больше...

автор писал:Вдогонку, насчет Access. Как раз-таки Access предоставляет пользователю ОДИН ГЛОБАЛЬНЫЙ объект, совместимый по интерфейс с ADODB.Connection, но он заточен спецами по MS SQL таким образом, что клиентское приложение "щадит" ресурсы сервера.

Какой объект, что значит совместимый по интерфейсу. Что у него заточено, что щадит. Давайка вместо чтения рекламного проспекта конкретно с цифирьками.

автор писал:Но конечно, все это полная чушь, пришел Тигра (pkarklin) и показал разработчикам MS SQL как правильно писать клиентские приложения для ИХ SQL Server.
Научи их, Тигра, научи... а то несчастные разработали MS SQL и сами не поняли, чего там они разработали.

А ты что, думал там боги сидят.

автор писал:А если стоит задача сократить отрезок времени до ОКОНЧАНИЯ всего проекта, и совершенно фиолетово, когда появится ПЕРВАЯ форма? Понимаешь, от дельфийских компонент заколебешься наследоваться. Т.е. довольно трудоемко компонент писать (относительно простого наследования ради переопределения, скажем, какой-нить мелочи). А я могу наследоваться легко и непринужденно буквально за каждой мелочью. Могу вообще все основные операции в базовые классы запрятать (напр. по работе с сервером). 90% приложения работает само по себе и управляется метаданными. Ручками только всякие drag&drop-ы и прочие неординарности. Для довольно сильного изменения поведения в некотором моменте, встречающемся во всем приложении достаточно "подкрутить" только в одном месте. "Управляемость кода". Слышал такое понятие? Оно напрочь отсутствует там, где формы "рисуются" мышкой, потому как чтобы сделать такую мелочь, как поменять цвет фона или шрифт у всех меток, необходимо прошерстить все 300 и более форм, присутствующие в приложении. :)

Ну вот, теперь ты нам прописные истины втираешь, как надо проекты делать, используя возможности ООП.


автор писал:девочка набивает накладную, скорость - зверская, она "мельтешит" своими пальчиками по гриду, меняет количество в строках. При переходе на следующую строку, текущую это необходимо сохранить в базе, т.к. в моей проге отображаются среди прочих еще остатки с учетом того, что другая такая же девочка именно в этот момент тоже выписывает одноименную позицию. При решении задачи "в лоб", т.е. на событии смены строки - посылаем обновления, работать было невозможно, если одновременно работало ОЧЕНЬ много людей, кто-то вводит документы, кто-то отчеты печатает. Так вот, при интенсивной многопользовательской работе каждая строка сохраняется где-то 0.5-1.5 сек, что ни в какие ворота не лезет, т.к. девочка способна набивать 2-3 строки в секунду (а розничные накладные бывают по 2000 строк - скорость набора крайне важна). Так и что делать? Можно ту же задачу решить ассинхронными вызовами, а можно использовать дополнительный тред. При использовании дополнительного треда (и наличии отлаженного фреймворка :) ), вариант с доп. тредом обходится в 3-4 раза меньшим числом строк кода, да еще практически не нуждается в отладке, т.к. представляет из себя "обычный человеческий алгоритм".

Это что ж за система, что запись сохраняется 1.5 секунды. А уж про то, что надо разносить формирование отчетов и OLTP, тут даже и говорить нечего. И объясни мне пожалуйста, почему ты решил, что основные тормаза те самые секунды вносит именно последовательная обработка запросов клиентом. Может все-таки с сервреной частью что-то не в порядке.

Я не пытаюсь охаить все, что вами сделано. Но опыт работы позваляет сделать вывод, что основной путь ускорения работы - это оптимизация именно серверной части - а не геморой с многопотоковостью, IMHO. И нужна она в очень редких случаях. А если вставка записей занимает стока времени, то надо в первую очередь серверную часть смотреть и как с ней работаешь.


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

Ну что ж давай пообсуждаем. А зачем мне кэшировать 100 000 записей справочника продукции. Ты представляешь, что это будет стоит клиенту. И эта популяция всяких гридов, комбобоксов. Она что, медленно идет, что ты их по тредам распихиваешь? Какие объемы записей там у тебя. Почему ты за трафик то так переживаешь?

2 vdimas

автор писал:плюс к этому считаем память на каждый открытый рекордсет (гриды на формах) и умножаем это на количество открытых форм (к середине рабочего дня у каждой девочки может быть открыто их около 20-ти, ну не любят они формы закрывать) и умножаем на сотни клиентов
т.е. + (64k (конект) + 24k*2 (среднее кол-во гридов на форме) * 20(форм) ) * 600(клиентов) = > 0.5 Gb только на служебную инфу
а памяти всего 256M (было поначалу, потом 512)

А с чего это ты мил друг считаешь память под открытые рекодсеты на клиенте?! 8-) Ты что, с серверными курсорами работаешь? После получения запрошенных данных с сервера никаких ресурсов кроме коннекта клиентское приложение не использует, скока бы рекордсетов не было открыто.

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

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

автор писал:уже ответил выше, голая вставка одновременно работающих десятков чел не занимает ничего. мою систему мне заказали на тот момент потому, что вариант 1С на SQL перепроводил большую накладную (300-1000 строк) за минуты (1-5), а больше 30-ти клиентов вообще работать толком не могли. В моей системе перепроводка выполняется за секунды (1-10 в зависимости от нагруженности сервака, в среднем 2-4 сек), а когда работает только 1 клиент, то вообще глазу ничего не заметно (повторяюсь)

Я имел ввиду не голую вставку, а сохранение новой записи той же товарной накладной, при выполнении которой срабатывает ряд триггеров и хп, обеспечивающих бизнеслогику работы системы. А потом, уж больно не подходящую систему ты выбрал для сравнения со своей - 1с.


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

Да уж теперь до меня доходит, раз у тебя что на клиенте, что на серваке конфигурации одинаковые - значит сиквел мы используем как хранилише таблиц. Иначе бы (достаточно мощный сервер, по современным ценам $10K за noname сборку) не было такой необходимости в танцах с бубнами над клиентским приложением. И раз по твоим словам производительность системы сильно отличается в зависимости от числа работающих пользователей (прям как в 1с), значит так оно и есть.

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

Сейчас на складах у нас досих пор трудятся 100 пни с 16 метрами памяти. Представляю, если б я в своей задачи кэшировал справочники продукции (около 100 000 записей) и контрагентов (около 20 000 записей) на клиенте. А решается все с помошью форм выбора из справочника по образцу. В ответ на критерии отбора пользователей на сервере вызывается соответствующая хп, которая и возвращает ограниченный набор данных.

автор писал:тогда это была сетка поделенная на сегменты, большинство из них - на 10Mb, (серверный - на 100Mb) да и небыстрая (по нынешним временам) конфигурация сервера отрицательно относилась к большому трафику.

О каком трафике вааще можно говорить в правильно спроектированной архитектуре клиент/сервер. У нас 100 тока от сервера до первого свича, дальше 10, через мост вааще аркнет (если помнишь на 2,5). А часть клиентов вообще работает через VIP канал шириной 128к. И клиентов (всего) уже давно ни одна сотня. Средняя загрузка 100 на сервере 3%. А у тебя откудато большой трафик нарисовался. Опять это меня заставляет сделать вывод, что система то построена ой как не оптимально.

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

Я и не пытась спорить, а пытаюсь высказать свои мысли. :-)

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

Вот такие вот, они, мои мысли. А, теперь о выводах. Основной, да и единственный главный, пожалуй. Нельзя рассуждать о способах организации клиентских приложений в отрыве от серверной части системы. Причем имеено гармотное проектировани и разработка последней отнимает гараздо больше времени. Зато результат будет гараздо ощутимей, чем геморой с мультитридом в клиентской части. Моя система охватывает практически все сферы деятельности крупного машиностроительного предприятия, и нигде, повторяю, нигде, мне не понадобилось ассинхронка. Причем не потому, что я этого не умею, а просто не вижу, в решении каких задач она бы мне помогла. Все серъезные аналитические отчеты давно вынесены из OLTP системы и варяться на отдельном серваке (OLAP). Именно принцип разделения OLTP и OLAP систем позволяет решать задачи построения отчетов без нагрузки на операционную часть. А объемы анализируються не малые (несколько лет). А те данные, которые нужны для работы операционной части (ну теже скалдские остатки) доступны в любой момент в предрасчитаном виде, так что никаких проблем ни с трафиком, ни с задержками на выполение запросов не возникает. Если есть желание еще обсудить детали, то можно продолжить. Хотя все равно каждый останется при своем мнении, IMHO.