Здравствуйте, Sinclair, Вы писали:

V>>Ну я когда-то наэкспериментировался.
S>Ну, то есть данных нет.

Не хами.
Данные тебе были даны — более полусекунды лагов при построчном редактировании в простой двухзвенке.
Таковы реалии 96-97-го года.


V>>Ограничение снизу для in-proc всегда было близко к 0-лю.
S>Мы всё ещё про MS Access?

У MS Access визуальные формы поверх данных на DAO воообще быстрее всего летали.
Быстрее не существовало в природе на тот момент, потому что народ не понимал толком, как машины работают.
Натурально.
По крайней мере подавляющее большинство программистов, которые разрабатывали именно программы, работающие с БД, т.е. всякие учётные системы.
Эти гаврики по-жизни были от земли оторваны и нихрена не соображали.
Зато горазды лепить отмазки, почему и соображать не надо.

Кароч, если дёргать из MS Access данные через ADO, т.е. пробегаться по выборкам — это жуткое нубство.
Его надо пользовать через DAO, в режиме ODBCDirect, при исполнении запросов указывать способ навигации через индексы, то бишь по-сути будут запрошены лишь индексы нужных строк. А сами данные запрашиваются в основном по мере прорисовки формы на экране (таблицы на форме).
Вот тут и стоит помедитировать, ИМХО. ))
И да, пресловутая jet db в этом режиме не используется.
А то я помню, как тут некоторые руки заламывали, мол, почему Янус тормозит, виновата jet engine.
Виновато, для начала, ADDO.DB, это если с самого начала начинать.

В общем, в 96-м году при отображении данных не спотыкался только MS Access.
Формы на FoxPro или на Клиппере имели кое-какую задержку при отображении.
Про Oracle вообще говорить смысла не было без техники за десятки тыщ баксов.
Sybase был так себе в те года, потом появился в точности такой же брат-близнец MS SQL. ))
Оба сливали по удобству и возможностям языка даже галимому Interbase.
Такое безобразие творилось вплоть до выхода верси MS SQL 7.0, которую следовало бы назвать 1.0, ы-ы-ы.
А 6-ку следовало бы назвать открытой альфой, даже не бетой.

Вот в таких условиях приходилось вертеться.
Скажи, тебе пришлось в своё время вдоволь натрахаться с 6-ым MS SQL? ))

А еще вокруг заполонили дельфисты, со своими херак-херак и в продакшен c умными видом.
Но для меня это всегда была как обратная сторона Луны, хотя на Дельфи одно время поупражнялся.
На асме и то прикольней, если вдруг приходится код именно писать, а не просто мышой накидывать. ))
В асме хотя бы мощнейший макропроцессор, а в Дельфях аж нифига от слова совсем.
Прямо смертная тоска берет. ))
Мне всегда казалось, что работать в Борланд или на их прожуктах — это такое наказание для непослушных инженеров.
Пока они клепали самую лучшую в мире среду для С++ (пусть даже текстовую), они были мега-популярны и уважаемы.
Как только забросили С++, так буквально за 3-4 года превратились в ничто и звать никак.
И до сих пор оттуда вылезти не могут.

V>>А так-то для самых ходовых сценариев должно быть малое время отклика, т.е. больше интересует ограничение снизу.
S>Это для каких, например?

Это когда девочка набирает по 2-3 строки заказа в секунду.
На той технике.
А сейчас смотрю на современные WPF/C# приложухи, на быстрые сетки... но не уверен, что на современной мейнстимовой платформе можно набивать данные с такой же скоростью. Сейчас всё всегда тормозит. При том, что мощности выросли в 100 раз.


V>>Сейчас из RAID SSD данные заливаются "сами" через DMA на скорости работы самой оперативки.
S>Мы всё ещё о настольном решении, в котором есть и "локальный кэш" и удалённое подключение?

Мы сейчас про что угодно.
У меня RAID SSD даже на ноуте.
Сейчас интелловские RAID-контроллеры везде, считай, кроме совсем начального уровня.
Два диска в параллель и огонь.


S>Или мы всеръёз рассуждаем о применимости MS Access на сервере в боевом режиме?

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

Кароч, уже было всё сказано, каким образом использовался MS Access — как GUI платформа, как удобный конструктор и САМЫЙ эффективный (на тот момент) COM-сервер своих объектов.
Потому что абсолютно все его контролы были windowsless.
Даже EDIT.
Даже списки и таблицы.
Даже TAB-контрол.
Вообще все.
Просто окно верхнего уровня всегда, которое даже не содержало дочерних окон-скроллбаров.
Всё рисовалось само.
Другой такой системы в природе не существовало, поэтому нагруженные формы с данными можно было лепить только на ём, используя его как каркас.
Благо, собственные ActiveX-контролы или просто COM-объекты с поддержкой визуального редакторивания св-в можно было делать самим на раз-два.

А всё остальное еле пыхало.
Для сравнения, в Дельфях windowsless были только лейблы, круги-овалы и всякие рамки вокруг окон.
Но эти контролы не "равнозначны" полноценным, а в хосте MS Access любые ActiveX контролы были вполне равнозначный.

Ну и про идиому использования собственной базы приложения как эффективного локального кеша-аагрегатора разных истоников данных — тоже уже говорил.

Просто мне и на MFC пришлось одно время поупражняться.
ТАк смешно выходит, что писаная полностю нейтивная прога для работы с БД будет сливать MS Access безбожно.


V>>Т.е. чтением с диска можно пренебречь в сравнении с другими затратами, бо за один маленький чих со стороны проца заливается целая страница или группа их (причём, страницы сейчас не обязательно по 4 KB, запросто и по 64). Ну и, данные из диска в любом случае читать надо.
V>>А вот "ручным" проталкиванием каждого байта через пайпы или сокеты пренебречь не получится при их наличии.
S>Эмм? Каждого байта?

Разумеется.


S>Откуда такие фантазии?

Не хами.


S>Очень рекомендую ознакомиться с архитектурой современных сетевых стеков.

Не хами.


S>Ну, чтобы представлять, что происходит, когда выполняется чтение из сокета, подключенного к 127.0.0.1.

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


S>Но и это — не лучший выбор для out-of-proc, по сравнению, скажем, с shared memory, которую SQL Server использует по умолчанию при локальном подключении.

Да-да.
При том, что эта технология — это на саммом деле технология маппинга файлов, где для возврата просто целого числа из базы тебе надо воспользоваться 4кB блоком или 8кB в популярных x64. Затратней даже обычного TCP с собственным сервис-провайдером для быстрой картейки какой-нить.


S>В общем, прекращаем распространять тьму невежства.

Тебе с ISAM не хватило, что ле?
Ты эта, так и будешь себя до смерти считать непогрешимым? ))

Дешевле WriteProcessMemory/ReadProcessMemory все-равно ничего нет.


V>>Более того, большой их параллельный трафик из разных потоков сильно тормозит систему в целом.
S>Да ладно!

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


S>(facepalm). Локально крутить RDBMS вообще имеет смысл только при недогрузке CPU.

Нормальный нейтивный сервак БД всегда архинедогружен.
Он способен считать что-то там намного быстрее, чем медленная внешняя БД вообще способна отдавать данные.
Поэтому, ему толком нечего делать.

Здравствуйте, Sinclair, Вы писали:

V>>Ну я когда-то наэкспериментировался.
S>Ну, то есть данных нет.

Не хами.
Данные тебе были даны — более полусекунды лагов при построчном редактировании в простой двухзвенке.
Таковы реалии 96-97-го года.


V>>Ограничение снизу для in-proc всегда было близко к 0-лю.
S>Мы всё ещё про MS Access?

У MS Access визуальные формы поверх данных на DAO воообще быстрее всего летали.
Быстрее не существовало в природе на тот момент, потому что народ не понимал толком, как машины работают.
Натурально.
По крайней мере подавляющее большинство программистов, которые разрабатывали именно программы, работающие с БД, т.е. всякие учётные системы.
Эти гаврики по-жизни были от земли оторваны и нихрена не соображали.
Зато горазды лепить отмазки, почему и соображать не надо.

Кароч, если дёргать из MS Access данные через ADO, т.е. пробегаться по выборкам — это жуткое нубство.
Его надо пользовать через DAO, в режиме ODBCDirect, при исполнении запросов указывать способ навигации через индексы, то бишь по-сути будут запрошены лишь индексы нужных строк. А сами данные запрашиваются в основном по мере прорисовки формы на экране (таблицы на форме).
Вот тут и стоит помедитировать, ИМХО. ))
И да, пресловутая jet db в этом режиме не используется.
А то я помню, как тут некоторые руки заламывали, мол, почему Янус тормозит, виновата jet engine.
Виновато, для начала, ADODB, это если с самого начала начинать.

В общем, в 96-м году при отображении данных не спотыкался только MS Access.
Формы на FoxPro или на Клиппере имели кое-какую задержку при отображении.
Про Oracle вообще говорить смысла не было без техники за десятки тыщ баксов.
Sybase был так себе в те года, потом появился в точности такой же брат-близнец MS SQL. ))
Оба сливали по удобству и возможностям языка даже галимому Interbase.
Такое безобразие творилось вплоть до выхода верси MS SQL 7.0, которую следовало бы назвать 1.0, ы-ы-ы.
А 6-ку следовало бы назвать открытой альфой, даже не бетой.

Вот в таких условиях приходилось вертеться.
Скажи, тебе пришлось в своё время вдоволь натрахаться с 6-ым MS SQL? ))

А еще вокруг заполонили дельфисты, со своими херак-херак и в продакшен c умными видом.
Но для меня это всегда была как обратная сторона Луны, хотя на Дельфи одно время поупражнялся.
На асме и то прикольней, если вдруг приходится код именно писать, а не просто мышой накидывать. ))
В асме хотя бы мощнейший макропроцессор, а в Дельфях аж нифига от слова совсем.
Прямо смертная тоска берет. ))
Мне всегда казалось, что работать в Борланд или на их прожуктах — это такое наказание для непослушных инженеров.
Пока они клепали самую лучшую в мире среду для С++ (пусть даже текстовую), они были мега-популярны и уважаемы.
Как только забросили С++, так буквально за 3-4 года превратились в ничто и звать никак.
И до сих пор оттуда вылезти не могут.

V>>А так-то для самых ходовых сценариев должно быть малое время отклика, т.е. больше интересует ограничение снизу.
S>Это для каких, например?

Это когда девочка набирает по 2-3 строки заказа в секунду.
На той технике.
А сейчас смотрю на современные WPF/C# приложухи, на быстрые сетки... но не уверен, что на современной мейнстимовой платформе можно набивать данные с такой же скоростью. Сейчас всё всегда тормозит. При том, что мощности выросли в 100 раз.


V>>Сейчас из RAID SSD данные заливаются "сами" через DMA на скорости работы самой оперативки.
S>Мы всё ещё о настольном решении, в котором есть и "локальный кэш" и удалённое подключение?

Мы сейчас про что угодно.
У меня RAID SSD даже на ноуте.
Сейчас интелловские RAID-контроллеры везде, считай, кроме совсем начального уровня.
Два диска в параллель и огонь.


S>Или мы всеръёз рассуждаем о применимости MS Access на сервере в боевом режиме?

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

Кароч, уже было всё сказано, каким образом использовался MS Access — как GUI платформа, как удобный конструктор и САМЫЙ эффективный (на тот момент) COM-сервер своих объектов.
Потому что абсолютно все его контролы были windowsless.
Даже EDIT.
Даже списки и таблицы.
Даже TAB-контрол.
Вообще все.
Просто окно верхнего уровня всегда, которое даже не содержало дочерних окон-скроллбаров.
Всё рисовалось само.
Другой такой системы в природе не существовало, поэтому нагруженные формы с данными можно было лепить только на ём, используя его как каркас.
Благо, собственные ActiveX-контролы или просто COM-объекты с поддержкой визуального редакторивания св-в можно было делать самим на раз-два.

А всё остальное еле пыхало.
Для сравнения, в Дельфях windowsless были только лейблы, круги-овалы и всякие рамки вокруг окон.
Но эти контролы не "равнозначны" полноценным, а в хосте MS Access любые ActiveX контролы были вполне равнозначный.

Ну и про идиому использования собственной базы приложения как эффективного локального кеша-аагрегатора разных истоников данных — тоже уже говорил.

Просто мне и на MFC пришлось одно время поупражняться.
ТАк смешно выходит, что писаная полностю нейтивная прога для работы с БД будет сливать MS Access безбожно.


V>>Т.е. чтением с диска можно пренебречь в сравнении с другими затратами, бо за один маленький чих со стороны проца заливается целая страница или группа их (причём, страницы сейчас не обязательно по 4 KB, запросто и по 64). Ну и, данные из диска в любом случае читать надо.
V>>А вот "ручным" проталкиванием каждого байта через пайпы или сокеты пренебречь не получится при их наличии.
S>Эмм? Каждого байта?

Разумеется.


S>Откуда такие фантазии?

Не хами.


S>Очень рекомендую ознакомиться с архитектурой современных сетевых стеков.

Не хами.


S>Ну, чтобы представлять, что происходит, когда выполняется чтение из сокета, подключенного к 127.0.0.1.

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


S>Но и это — не лучший выбор для out-of-proc, по сравнению, скажем, с shared memory, которую SQL Server использует по умолчанию при локальном подключении.

Да-да.
При том, что эта технология — это на саммом деле технология маппинга файлов, где для возврата просто целого числа из базы тебе надо воспользоваться 4кB блоком или 8кB в популярных x64. Затратней даже обычного TCP с собственным сервис-провайдером для быстрой картейки какой-нить.


S>В общем, прекращаем распространять тьму невежства.

Тебе с ISAM не хватило, что ле?
Ты эта, так и будешь себя до смерти считать непогрешимым? ))

Дешевле WriteProcessMemory/ReadProcessMemory все-равно ничего нет.


V>>Более того, большой их параллельный трафик из разных потоков сильно тормозит систему в целом.
S>Да ладно!

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


S>(facepalm). Локально крутить RDBMS вообще имеет смысл только при недогрузке CPU.

Нормальный нейтивный сервак БД всегда архинедогружен.
Он способен считать что-то там намного быстрее, чем медленная внешняя БД вообще способна отдавать данные.
Поэтому, ему толком нечего делать.