Сообщение Re[51]: В России опять напишут новый объектно-ориентированны от 13.04.2018 15:55
Изменено 13.04.2018 15:57 vdimas
Re[51]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Sinclair, Вы писали:
S>Мы просто замеряли реальные времена исполнения запросов. По сети MS SQL отдавал данные за ~100мсек. Это в 1997 году, есличо.
Ага, если один чел-клиент на ём работает.
Фтопку такие замеры.
У меня реальное боевое применение в течени нескольких лет было, если чо.
Два десятка девочек строчат накладные, менеджер их проверяет/проводит/откатывает, ком.директор продажи итогами просматривает — не жило оно "в лоб" от слова ни-фи-га.
S>Полусекундные паузы из-за out-of-proc на локальной машине — беспардонное враньё.
Смотря какая очередь запросов накопилась.
Задержки по передаче каждого запроса из очереди сказываются на суммарном времени задержки по каждому из них.
Кароч, чего тут говорить. Когда на Дельфях вовсю еше выполняли все операции прямо в потоке GUI, мы вовсю выносили IO в отдельный поток и получали настоящую асинхронность. Если даже на современной технике и с современной сеткой переход на асинхронность считается хорошим тоном, то про те времена и говорить было бесполезно — это вообще было условие существования более-менее отзывчивой системы на том железе.
Во фрилансерстве в 2000-е применял эти же подходы уже и на C#, задолго до всяких async — делали систему POS+учёт для торговых точек в США.
S>Ну, то есть в паузы — верю. В то, что они из-за out-of-proc — чушь. Из-за кривых рук они могли быть, исключительно из-за кривых рук.
Т.е. у всей индустрии кривые руки? ))
Заметная разница есть у всех.
Просто ты не занимался такими вещами вплотную.
V>>От попыток чтения всего набора возвращаемых данных.
S>На клиппере прочесть "весь набор" — это надо постараться. Я так полагаю, что вы, коллега, Клиппера своими глазами не видели, да?
Ошибочно полагаешь.
V>>Сплошной copy&paste, по-другому в дельфях никак.
S>Это больше говорит о ваших способностях, чем о Delphi.
Тут желателено был бы пример типизированной коллекции, чтобы без copy&paste, или слил.
S>Это как один мой знакомый склонировал полностью исходники TListView, потому что хотел в нём свой потомок TListItem обрабатывать, а AddItem там сразу готовый айтем возвращает.
S>Не заметил, что можно просто перекрыть CreateListItem. Бывает.
При чём тут твой знакомый?
V>>4 SSD в параллель, скорость чтения 3.6 гига.
S>Неплохо, неплохо. Даже с учётом того, что реалистичная скорость, намеренная в тестах, около 2х гигов.
Врать не надоело?
Полно обозоров на ютубе, народ показывает скриншоты — получают те самые 3.6 гига/с.
V>>Потому что уже пошли материнки с PCIe 4.0, с удвоенной пропускной сопособностью, т.е. можно получить 32 гигабайта/с.
S>Ну, во-первых, мы же не порнуху копируем. СУБД редко удаётся свести всё к линейному чтению. Так что с 32гб/с не выйдет.
Выйдёт.
Скорость же удельная величина.
Просто где-то наод не 32 гига за секунду, а 32 метра за 1ms.
S>Во-вторых, а куда мы собираемся заливать эти прочитанные данные? Не в память ли? Какой смысл читать данные с диска втрое быстрее, чем их сможет принять память?
Память уже давно многоканальная, особенно на серваках.
Да и на ноутах минимум двухканальная уже стандарт де-факто.
V>>Кол-во IO в сек (см на NVMe):
V>>Image: 3lv12.jpg
S>Вот картинка с IOPS — полезная штука. Видно, что с таким винтом можно делать странички по 4к и он будет их отдавать довольно шустро. Всё равно, конечно, рандомное чтение из памяти будет на порядки быстрее
Это если брать полный цикл чтения одного блока, но это никогда не требуется.
Классический сервак баз данных создаёт очереди обработки, как раз через эти очереди насыщается пиковая пропускная способность.
Обрати внимание на графике на размер очереди самого накопителя.
А так-то есть накопители и с большим размером очереди.
S>поэтому пересылка result set через границу процесса будет нам стоить пренебрежимо мало по сравнению со стоимостью исполнения запроса на диск.
Ай, какое нубство...
Драйвер может помещать в очередь за раз кучу запросов к диску и за одно прерывание тоже выгребается куча же ответов.
А в твоём варианте мы имеем от сервака приложений сотни/тысячи коннекшенов к SQL-серваку одновременно, где в каждый коннекшен серваку надо отдать данные индивидуально. Из-за этого не получается "размазать" затраты на одну операцию ввода/вывода на сотни логических прикладных операций.
Судя по всему, ты не понимаешь примеры группировки операций, которые я постоянно привожу.
V>>А теперь я их лишь озвучиваю, бо, прямо скажем, твои представления на уровне слухов и обычного для прикладников тех лет непонимания.
S>Какие представления?
Да хотя бы почему приложение на дельфях медленнее работает с базами данных при отображении в таблицах.
Сейчас-то это трудно заметить, а в 96-м году это было более чем очевидно, особенно при листании выборок в таблицах.
Насчёт FoxPro аналогично — такая же точно ошибка в архитектуре и пой же самой причине тормоза, GUI морозилось, пока все данные для отображаемых строк не прочитает. ))
Учитывая, что мы уже выяснили, что ты не понимал, что такое ISAM, приходится объяснять, какой от него вообще толк, т.е. как именно с этим подходом можно эффективно работать.
V>>Не знаю в каком году. В 96-м tabstop работал по таким компонентам коряво — сначала проходился по windowed-контролам и лишь потом, когда доходила очередь до самой формы, она проходилась по windowsless.
S>В 96м — это, наверное, ещё Delphi 1.0? 16-разрядный? Не помню, не застал.
И в институте не программировал ни разу?
V>>Да вот не просто. Сначала надо освободить ДРУГОЙ буфер со скидыванием его содержимого на диск, если мы нагруженно через эту кухню работаем.
S>Зачем нам освобождать "другой" буфер? Пишем в буфер 1 — отдаём клиенту — пишем в буфер 2. Получили сигнал "давай ещё" — говорим клиенту "смотри буфер 2", и пишем в буфер 1.
Опять какой-то детсад, сорри.
Ключевое выделил.
Пока у клиента "живой" рекордсет на руках, выделенная под него shared-память будет только расти.
Избежать этого можно только при открытии рекодрсета в режиме forward only, но такой рекордсет нельзя было напрямую прибиндить к форме в Дельфи, Фокспро или MS Access.
Т.е., с единственным "лекарством" от этой болезни можно было работать лишь обслуживая низкоуровневую механику ручками. К чему я и пришел в итоге, после серии экспериментов с локальным кешированием записей. Потому что выбора у меня всё-равно не было, ведь после выхода 7-го MS SQL альтернативы ему для "обычного" железа, считай, отсутствовали. А его ни in-proc не подключить, ни написать свой драйвер передачи данных для сервака, есть лишь выбор из предоставляемого. Вот и выкручивайся.
V>>Пфф... Вопрос в том СКОЛЬКО раз потребуется переключать контекст?
S>Ну всяко меньше раз, чем при чтении файла по кускам.
Файл читается большими страницами. Почти всегда за раз скидывается или читается большое кол-во страниц. Т.е. затраты одной IO-операции неплохо "размазываются" по большой группе логических операций. Этот механизм включён в саму операционку.
V>>Про "нет копирований" булшит в обсуждаемом сценарии.
V>>Сервак же не маппированные области базы данных возвращает а формирует в памяти представление твоего рекордсета.
S>Ну да, всё верно. И in-proc сервер делает то же самое. Рекордсет-то точно такой же.
Разве что контекст исполнения на кажду порцию данных переключать не надо.
А, может, ты забыл, что операции записи в shared-память провоцируют исключения ОС?
Поэтому, писать в такую память "построчно" точно так же глупо.
Поэтому и было глупо насчёт "зато нет копирования".
Не всё, что написано на Stack Overflow является истинной. Даже если у поста стоит десяток плюсов. ))
V>>Можно сразу писать результат "туда".
V>>Опять же, глупо возвращать ВСЕ данные сразу, их надо возвращать порциями, чтобы обрабатывать в "оперативной" манере.
S>Буфер — наше всё.
Межпроцессный дорог.
А межпотоковый у меня "размазывает" одну операцию синхронизации стоимостью 1 микросекунду на сотни/тысячи сообщений в lock-free межпотоковых буферах.
V>>Я пол-года не выкатывал свою первую систему с использованием SQL-севака, потому что при обычном, принятом по-умолчанию "построчном" редактировании, т.е. с сохранением каждой строки, впечатление было ужасным после варианта с файловой базой.
S>Естественно. Некурящие люди так не делали ни в какие годы.
Примерно с 2000-го года делали аж бегом. ))
Хотя тут характерно твоё согласие, хотя были возражения на это же выше.
Сам себе противоречишь.
S>Сохранение делалось "потранзакционно", а строки заказа лежали в памяти.
А когда их сотни и тут связь с серваком глюкнулась, то амба. ))
Поэтому, на MS Access и было удобно, что это и GUI-прога и локальная шустрая база одновременно.
А так-то я в период фрилансерства как раз выполнил один такой заказик для целого семейства систем на Дельфи, который был TCP проксей и "держал" TCP-связь что со стороны клиента, что со стороны сервака, пока связь восстанавливалась. Бо терять прилично наработанного времени всегда обидно, скажем, человек долго редактировать большой заказ и несколько раз его перепроверял перед сохранением.
V>>Зачем?
S>Для масштабирования.
А что сначала надо масштабировать — базу или сервак приложений? ))
Просто был опыт писания сервака приложений и на нейтиве, так вот, надобность "масштабирования" волшебным образом уменьшается примерно в 10 раз. Т.е. он допускает вдесятеро большую нагрузку, чем явовские или дотнетные серваки.
И даже сложно придумать такое применение, где бы потребовалось то самое "масштабирование".
Вон ты сам писал, что RSDN работает на скромном железе для его популярности.
А популярность, действительно, нехилая.
Для нейтивной такой системы нужно было бы в 10 раз более скромное железо для того же отклика.
S>Мы просто замеряли реальные времена исполнения запросов. По сети MS SQL отдавал данные за ~100мсек. Это в 1997 году, есличо.
Ага, если один чел-клиент на ём работает.
Фтопку такие замеры.
У меня реальное боевое применение в течени нескольких лет было, если чо.
Два десятка девочек строчат накладные, менеджер их проверяет/проводит/откатывает, ком.директор продажи итогами просматривает — не жило оно "в лоб" от слова ни-фи-га.
S>Полусекундные паузы из-за out-of-proc на локальной машине — беспардонное враньё.
Смотря какая очередь запросов накопилась.
Задержки по передаче каждого запроса из очереди сказываются на суммарном времени задержки по каждому из них.
Кароч, чего тут говорить. Когда на Дельфях вовсю еше выполняли все операции прямо в потоке GUI, мы вовсю выносили IO в отдельный поток и получали настоящую асинхронность. Если даже на современной технике и с современной сеткой переход на асинхронность считается хорошим тоном, то про те времена и говорить было бесполезно — это вообще было условие существования более-менее отзывчивой системы на том железе.
Во фрилансерстве в 2000-е применял эти же подходы уже и на C#, задолго до всяких async — делали систему POS+учёт для торговых точек в США.
S>Ну, то есть в паузы — верю. В то, что они из-за out-of-proc — чушь. Из-за кривых рук они могли быть, исключительно из-за кривых рук.
Т.е. у всей индустрии кривые руки? ))
Заметная разница есть у всех.
Просто ты не занимался такими вещами вплотную.
V>>От попыток чтения всего набора возвращаемых данных.
S>На клиппере прочесть "весь набор" — это надо постараться. Я так полагаю, что вы, коллега, Клиппера своими глазами не видели, да?
Ошибочно полагаешь.
V>>Сплошной copy&paste, по-другому в дельфях никак.
S>Это больше говорит о ваших способностях, чем о Delphi.
Тут желателено был бы пример типизированной коллекции, чтобы без copy&paste, или слил.
S>Это как один мой знакомый склонировал полностью исходники TListView, потому что хотел в нём свой потомок TListItem обрабатывать, а AddItem там сразу готовый айтем возвращает.
S>Не заметил, что можно просто перекрыть CreateListItem. Бывает.
При чём тут твой знакомый?
V>>4 SSD в параллель, скорость чтения 3.6 гига.
S>Неплохо, неплохо. Даже с учётом того, что реалистичная скорость, намеренная в тестах, около 2х гигов.
Врать не надоело?
Полно обозоров на ютубе, народ показывает скриншоты — получают те самые 3.6 гига/с.
V>>Потому что уже пошли материнки с PCIe 4.0, с удвоенной пропускной сопособностью, т.е. можно получить 32 гигабайта/с.
S>Ну, во-первых, мы же не порнуху копируем. СУБД редко удаётся свести всё к линейному чтению. Так что с 32гб/с не выйдет.
Выйдёт.
Скорость же удельная величина.
Просто где-то наод не 32 гига за секунду, а 32 метра за 1ms.
S>Во-вторых, а куда мы собираемся заливать эти прочитанные данные? Не в память ли? Какой смысл читать данные с диска втрое быстрее, чем их сможет принять память?
Память уже давно многоканальная, особенно на серваках.
Да и на ноутах минимум двухканальная уже стандарт де-факто.
V>>Кол-во IO в сек (см на NVMe):
V>>Image: 3lv12.jpg
S>Вот картинка с IOPS — полезная штука. Видно, что с таким винтом можно делать странички по 4к и он будет их отдавать довольно шустро. Всё равно, конечно, рандомное чтение из памяти будет на порядки быстрее
Это если брать полный цикл чтения одного блока, но это никогда не требуется.
Классический сервак баз данных создаёт очереди обработки, как раз через эти очереди насыщается пиковая пропускная способность.
Обрати внимание на графике на размер очереди самого накопителя.
А так-то есть накопители и с большим размером очереди.
S>поэтому пересылка result set через границу процесса будет нам стоить пренебрежимо мало по сравнению со стоимостью исполнения запроса на диск.
Ай, какое нубство...
Драйвер может помещать в очередь за раз кучу запросов к диску и за одно прерывание тоже выгребается куча же ответов.
А в твоём варианте мы имеем от сервака приложений сотни/тысячи коннекшенов к SQL-серваку одновременно, где в каждый коннекшен серваку надо отдать данные индивидуально. Из-за этого не получается "размазать" затраты на одну операцию ввода/вывода на сотни логических прикладных операций.
Судя по всему, ты не понимаешь примеры группировки операций, которые я постоянно привожу.
V>>А теперь я их лишь озвучиваю, бо, прямо скажем, твои представления на уровне слухов и обычного для прикладников тех лет непонимания.
S>Какие представления?
Да хотя бы почему приложение на дельфях медленнее работает с базами данных при отображении в таблицах.
Сейчас-то это трудно заметить, а в 96-м году это было более чем очевидно, особенно при листании выборок в таблицах.
Насчёт FoxPro аналогично — такая же точно ошибка в архитектуре и пой же самой причине тормоза, GUI морозилось, пока все данные для отображаемых строк не прочитает. ))
Учитывая, что мы уже выяснили, что ты не понимал, что такое ISAM, приходится объяснять, какой от него вообще толк, т.е. как именно с этим подходом можно эффективно работать.
V>>Не знаю в каком году. В 96-м tabstop работал по таким компонентам коряво — сначала проходился по windowed-контролам и лишь потом, когда доходила очередь до самой формы, она проходилась по windowsless.
S>В 96м — это, наверное, ещё Delphi 1.0? 16-разрядный? Не помню, не застал.
И в институте не программировал ни разу?
V>>Да вот не просто. Сначала надо освободить ДРУГОЙ буфер со скидыванием его содержимого на диск, если мы нагруженно через эту кухню работаем.
S>Зачем нам освобождать "другой" буфер? Пишем в буфер 1 — отдаём клиенту — пишем в буфер 2. Получили сигнал "давай ещё" — говорим клиенту "смотри буфер 2", и пишем в буфер 1.
Опять какой-то детсад, сорри.
Ключевое выделил.
Пока у клиента "живой" рекордсет на руках, выделенная под него shared-память будет только расти.
Избежать этого можно только при открытии рекодрсета в режиме forward only, но такой рекордсет нельзя было напрямую прибиндить к форме в Дельфи, Фокспро или MS Access.
Т.е., с единственным "лекарством" от этой болезни можно было работать лишь обслуживая низкоуровневую механику ручками. К чему я и пришел в итоге, после серии экспериментов с локальным кешированием записей. Потому что выбора у меня всё-равно не было, ведь после выхода 7-го MS SQL альтернативы ему для "обычного" железа, считай, отсутствовали. А его ни in-proc не подключить, ни написать свой драйвер передачи данных для сервака, есть лишь выбор из предоставляемого. Вот и выкручивайся.
V>>Пфф... Вопрос в том СКОЛЬКО раз потребуется переключать контекст?
S>Ну всяко меньше раз, чем при чтении файла по кускам.
Файл читается большими страницами. Почти всегда за раз скидывается или читается большое кол-во страниц. Т.е. затраты одной IO-операции неплохо "размазываются" по большой группе логических операций. Этот механизм включён в саму операционку.
V>>Про "нет копирований" булшит в обсуждаемом сценарии.
V>>Сервак же не маппированные области базы данных возвращает а формирует в памяти представление твоего рекордсета.
S>Ну да, всё верно. И in-proc сервер делает то же самое. Рекордсет-то точно такой же.
Разве что контекст исполнения на кажду порцию данных переключать не надо.
А, может, ты забыл, что операции записи в shared-память провоцируют исключения ОС?
Поэтому, писать в такую память "построчно" точно так же глупо.
Поэтому и было глупо насчёт "зато нет копирования".
Не всё, что написано на Stack Overflow является истинной. Даже если у поста стоит десяток плюсов. ))
V>>Можно сразу писать результат "туда".
V>>Опять же, глупо возвращать ВСЕ данные сразу, их надо возвращать порциями, чтобы обрабатывать в "оперативной" манере.
S>Буфер — наше всё.
Межпроцессный дорог.
А межпотоковый у меня "размазывает" одну операцию синхронизации стоимостью 1 микросекунду на сотни/тысячи сообщений в lock-free межпотоковых буферах.
V>>Я пол-года не выкатывал свою первую систему с использованием SQL-севака, потому что при обычном, принятом по-умолчанию "построчном" редактировании, т.е. с сохранением каждой строки, впечатление было ужасным после варианта с файловой базой.
S>Естественно. Некурящие люди так не делали ни в какие годы.
Примерно с 2000-го года делали аж бегом. ))
Хотя тут характерно твоё согласие, хотя были возражения на это же выше.
Сам себе противоречишь.
S>Сохранение делалось "потранзакционно", а строки заказа лежали в памяти.
А когда их сотни и тут связь с серваком глюкнулась, то амба. ))
Поэтому, на MS Access и было удобно, что это и GUI-прога и локальная шустрая база одновременно.
А так-то я в период фрилансерства как раз выполнил один такой заказик для целого семейства систем на Дельфи, который был TCP проксей и "держал" TCP-связь что со стороны клиента, что со стороны сервака, пока связь восстанавливалась. Бо терять прилично наработанного времени всегда обидно, скажем, человек долго редактировать большой заказ и несколько раз его перепроверял перед сохранением.
V>>Зачем?
S>Для масштабирования.
А что сначала надо масштабировать — базу или сервак приложений? ))
Просто был опыт писания сервака приложений и на нейтиве, так вот, надобность "масштабирования" волшебным образом уменьшается примерно в 10 раз. Т.е. он допускает вдесятеро большую нагрузку, чем явовские или дотнетные серваки.
И даже сложно придумать такое применение, где бы потребовалось то самое "масштабирование".
Вон ты сам писал, что RSDN работает на скромном железе для его популярности.
А популярность, действительно, нехилая.
Для нейтивной такой системы нужно было бы в 10 раз более скромное железо для того же отклика.
Re[51]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Sinclair, Вы писали:
S>Мы просто замеряли реальные времена исполнения запросов. По сети MS SQL отдавал данные за ~100мсек. Это в 1997 году, есличо.
Ага, если один чел-клиент на ём работает.
Фтопку такие замеры.
У меня реальное боевое применение в течени нескольких лет было, если чо.
Два десятка девочек строчат накладные, менеджер их проверяет/проводит/откатывает, ком.директор продажи итогами просматривает — не жило оно "в лоб" от слова ни-фи-га.
S>Полусекундные паузы из-за out-of-proc на локальной машине — беспардонное враньё.
Смотря какая очередь запросов накопилась.
Задержки по передаче каждого запроса из очереди сказываются на суммарном времени задержки по каждому из них.
Кароч, чего тут говорить. Когда на Дельфях вовсю еше выполняли все операции прямо в потоке GUI, мы вовсю выносили IO в отдельный поток и получали настоящую асинхронность. Если даже на современной технике и с современной сеткой переход на асинхронность считается хорошим тоном, то про те времена и говорить было бесполезно — это вообще было условие существования более-менее отзывчивой системы на том железе.
Во фрилансерстве в 2000-е применял эти же подходы уже и на C#, задолго до всяких async — делали систему POS+учёт для торговых точек в США.
S>Ну, то есть в паузы — верю. В то, что они из-за out-of-proc — чушь. Из-за кривых рук они могли быть, исключительно из-за кривых рук.
Т.е. у всей индустрии кривые руки? ))
Заметная разница есть у всех.
Просто ты не занимался такими вещами вплотную.
V>>От попыток чтения всего набора возвращаемых данных.
S>На клиппере прочесть "весь набор" — это надо постараться. Я так полагаю, что вы, коллега, Клиппера своими глазами не видели, да?
Ошибочно полагаешь.
V>>Сплошной copy&paste, по-другому в дельфях никак.
S>Это больше говорит о ваших способностях, чем о Delphi.
Тут желателен был бы пример типизированной коллекции, чтобы без copy&paste, или слил.
S>Это как один мой знакомый склонировал полностью исходники TListView, потому что хотел в нём свой потомок TListItem обрабатывать, а AddItem там сразу готовый айтем возвращает.
S>Не заметил, что можно просто перекрыть CreateListItem. Бывает.
При чём тут твой знакомый?
V>>4 SSD в параллель, скорость чтения 3.6 гига.
S>Неплохо, неплохо. Даже с учётом того, что реалистичная скорость, намеренная в тестах, около 2х гигов.
Врать не надоело?
Полно обозоров на ютубе, народ показывает скриншоты — получают те самые 3.6 гига/с.
V>>Потому что уже пошли материнки с PCIe 4.0, с удвоенной пропускной сопособностью, т.е. можно получить 32 гигабайта/с.
S>Ну, во-первых, мы же не порнуху копируем. СУБД редко удаётся свести всё к линейному чтению. Так что с 32гб/с не выйдет.
Выйдёт.
Скорость же удельная величина.
Просто где-то надо не 32 гига за секунду, а 32 метра за 1ms.
S>Во-вторых, а куда мы собираемся заливать эти прочитанные данные? Не в память ли? Какой смысл читать данные с диска втрое быстрее, чем их сможет принять память?
Память уже давно многоканальная, особенно на серваках.
Да и на ноутах минимум двухканальная уже стандарт де-факто.
V>>Кол-во IO в сек (см на NVMe):
V>>Image: 3lv12.jpg
S>Вот картинка с IOPS — полезная штука. Видно, что с таким винтом можно делать странички по 4к и он будет их отдавать довольно шустро. Всё равно, конечно, рандомное чтение из памяти будет на порядки быстрее
Это если брать полный цикл чтения одного блока, но это никогда не требуется.
Классический сервак баз данных создаёт очереди обработки, как раз через эти очереди насыщается пиковая пропускная способность.
Обрати внимание на графике на размер очереди самого накопителя.
А так-то есть накопители и с большим размером очереди.
S>поэтому пересылка result set через границу процесса будет нам стоить пренебрежимо мало по сравнению со стоимостью исполнения запроса на диск.
Ай, какое нубство...
Драйвер может помещать в очередь за раз кучу запросов к диску и за одно прерывание тоже выгребается куча же ответов.
А в твоём варианте мы имеем от сервака приложений сотни/тысячи коннекшенов к SQL-серваку одновременно, где в каждый коннекшен серваку надо отдать данные индивидуально. Из-за этого не получается "размазать" затраты на одну операцию ввода/вывода на сотни логических прикладных операций.
Судя по всему, ты не понимаешь примеры группировки операций, которые я постоянно привожу.
V>>А теперь я их лишь озвучиваю, бо, прямо скажем, твои представления на уровне слухов и обычного для прикладников тех лет непонимания.
S>Какие представления?
Да хотя бы почему приложение на дельфях медленнее работает с базами данных при отображении в таблицах.
Сейчас-то это трудно заметить, а в 96-м году это было более чем очевидно, особенно при листании выборок в таблицах.
Насчёт FoxPro аналогично — такая же точно ошибка в архитектуре и пой же самой причине тормоза, GUI морозилось, пока все данные для отображаемых строк не прочитает. ))
Учитывая, что мы уже выяснили, что ты не понимал, что такое ISAM, приходится объяснять, какой от него вообще толк, т.е. как именно с этим подходом можно эффективно работать.
V>>Не знаю в каком году. В 96-м tabstop работал по таким компонентам коряво — сначала проходился по windowed-контролам и лишь потом, когда доходила очередь до самой формы, она проходилась по windowsless.
S>В 96м — это, наверное, ещё Delphi 1.0? 16-разрядный? Не помню, не застал.
И в институте не программировал ни разу?
V>>Да вот не просто. Сначала надо освободить ДРУГОЙ буфер со скидыванием его содержимого на диск, если мы нагруженно через эту кухню работаем.
S>Зачем нам освобождать "другой" буфер? Пишем в буфер 1 — отдаём клиенту — пишем в буфер 2. Получили сигнал "давай ещё" — говорим клиенту "смотри буфер 2", и пишем в буфер 1.
Опять какой-то детсад, сорри.
Ключевое выделил.
Пока у клиента "живой" рекордсет на руках, выделенная под него shared-память будет только расти.
Избежать этого можно только при открытии рекодрсета в режиме forward only, но такой рекордсет нельзя было напрямую прибиндить к форме в Дельфи, Фокспро или MS Access.
Т.е., с единственным "лекарством" от этой болезни можно было работать лишь обслуживая низкоуровневую механику ручками. К чему я и пришел в итоге, после серии экспериментов с локальным кешированием записей. Потому что выбора у меня всё-равно не было, ведь после выхода 7-го MS SQL альтернативы ему для "обычного" железа, считай, отсутствовали. А его ни in-proc не подключить, ни написать свой драйвер передачи данных для сервака, есть лишь выбор из предоставляемого. Вот и выкручивайся.
V>>Пфф... Вопрос в том СКОЛЬКО раз потребуется переключать контекст?
S>Ну всяко меньше раз, чем при чтении файла по кускам.
Файл читается большими страницами. Почти всегда за раз скидывается или читается большое кол-во страниц. Т.е. затраты одной IO-операции неплохо "размазываются" по большой группе логических операций. Этот механизм включён в саму операционку.
V>>Про "нет копирований" булшит в обсуждаемом сценарии.
V>>Сервак же не маппированные области базы данных возвращает а формирует в памяти представление твоего рекордсета.
S>Ну да, всё верно. И in-proc сервер делает то же самое. Рекордсет-то точно такой же.
Разве что контекст исполнения на кажду порцию данных переключать не надо.
А, может, ты забыл, что операции записи в shared-память провоцируют исключения ОС?
Поэтому, писать в такую память "построчно" точно так же глупо.
Поэтому и было глупо насчёт "зато нет копирования".
Не всё, что написано на Stack Overflow является истинной. Даже если у поста стоит десяток плюсов. ))
V>>Можно сразу писать результат "туда".
V>>Опять же, глупо возвращать ВСЕ данные сразу, их надо возвращать порциями, чтобы обрабатывать в "оперативной" манере.
S>Буфер — наше всё.
Межпроцессный дорог.
А межпотоковый у меня "размазывает" одну операцию синхронизации стоимостью 1 микросекунду на сотни/тысячи сообщений в lock-free межпотоковых буферах.
V>>Я пол-года не выкатывал свою первую систему с использованием SQL-севака, потому что при обычном, принятом по-умолчанию "построчном" редактировании, т.е. с сохранением каждой строки, впечатление было ужасным после варианта с файловой базой.
S>Естественно. Некурящие люди так не делали ни в какие годы.
Примерно с 2000-го года делали аж бегом. ))
Хотя тут характерно твоё согласие, хотя были возражения на это же выше.
Сам себе противоречишь.
S>Сохранение делалось "потранзакционно", а строки заказа лежали в памяти.
А когда их сотни и тут связь с серваком глюкнулась, то амба. ))
Поэтому, на MS Access и было удобно, что это и GUI-прога и локальная шустрая база одновременно.
А так-то я в период фрилансерства как раз выполнил один такой заказик для целого семейства систем на Дельфи, который был TCP проксей и "держал" TCP-связь что со стороны клиента, что со стороны сервака, пока связь восстанавливалась. Бо терять прилично наработанного времени всегда обидно, скажем, человек долго редактировать большой заказ и несколько раз его перепроверял перед сохранением.
V>>Зачем?
S>Для масштабирования.
А что сначала надо масштабировать — базу или сервак приложений? ))
Просто был опыт писания сервака приложений и на нейтиве, так вот, надобность "масштабирования" волшебным образом уменьшается примерно в 10 раз. Т.е. он допускает вдесятеро большую нагрузку, чем явовские или дотнетные серваки.
И даже сложно придумать такое применение, где бы потребовалось то самое "масштабирование".
Вон ты сам писал, что RSDN работает на скромном железе для его популярности.
А популярность, действительно, нехилая.
Для нейтивной такой системы нужно было бы в 10 раз более скромное железо для того же отклика.
S>Мы просто замеряли реальные времена исполнения запросов. По сети MS SQL отдавал данные за ~100мсек. Это в 1997 году, есличо.
Ага, если один чел-клиент на ём работает.
Фтопку такие замеры.
У меня реальное боевое применение в течени нескольких лет было, если чо.
Два десятка девочек строчат накладные, менеджер их проверяет/проводит/откатывает, ком.директор продажи итогами просматривает — не жило оно "в лоб" от слова ни-фи-га.
S>Полусекундные паузы из-за out-of-proc на локальной машине — беспардонное враньё.
Смотря какая очередь запросов накопилась.
Задержки по передаче каждого запроса из очереди сказываются на суммарном времени задержки по каждому из них.
Кароч, чего тут говорить. Когда на Дельфях вовсю еше выполняли все операции прямо в потоке GUI, мы вовсю выносили IO в отдельный поток и получали настоящую асинхронность. Если даже на современной технике и с современной сеткой переход на асинхронность считается хорошим тоном, то про те времена и говорить было бесполезно — это вообще было условие существования более-менее отзывчивой системы на том железе.
Во фрилансерстве в 2000-е применял эти же подходы уже и на C#, задолго до всяких async — делали систему POS+учёт для торговых точек в США.
S>Ну, то есть в паузы — верю. В то, что они из-за out-of-proc — чушь. Из-за кривых рук они могли быть, исключительно из-за кривых рук.
Т.е. у всей индустрии кривые руки? ))
Заметная разница есть у всех.
Просто ты не занимался такими вещами вплотную.
V>>От попыток чтения всего набора возвращаемых данных.
S>На клиппере прочесть "весь набор" — это надо постараться. Я так полагаю, что вы, коллега, Клиппера своими глазами не видели, да?
Ошибочно полагаешь.
V>>Сплошной copy&paste, по-другому в дельфях никак.
S>Это больше говорит о ваших способностях, чем о Delphi.
Тут желателен был бы пример типизированной коллекции, чтобы без copy&paste, или слил.
S>Это как один мой знакомый склонировал полностью исходники TListView, потому что хотел в нём свой потомок TListItem обрабатывать, а AddItem там сразу готовый айтем возвращает.
S>Не заметил, что можно просто перекрыть CreateListItem. Бывает.
При чём тут твой знакомый?
V>>4 SSD в параллель, скорость чтения 3.6 гига.
S>Неплохо, неплохо. Даже с учётом того, что реалистичная скорость, намеренная в тестах, около 2х гигов.
Врать не надоело?
Полно обозоров на ютубе, народ показывает скриншоты — получают те самые 3.6 гига/с.
V>>Потому что уже пошли материнки с PCIe 4.0, с удвоенной пропускной сопособностью, т.е. можно получить 32 гигабайта/с.
S>Ну, во-первых, мы же не порнуху копируем. СУБД редко удаётся свести всё к линейному чтению. Так что с 32гб/с не выйдет.
Выйдёт.
Скорость же удельная величина.
Просто где-то надо не 32 гига за секунду, а 32 метра за 1ms.
S>Во-вторых, а куда мы собираемся заливать эти прочитанные данные? Не в память ли? Какой смысл читать данные с диска втрое быстрее, чем их сможет принять память?
Память уже давно многоканальная, особенно на серваках.
Да и на ноутах минимум двухканальная уже стандарт де-факто.
V>>Кол-во IO в сек (см на NVMe):
V>>Image: 3lv12.jpg
S>Вот картинка с IOPS — полезная штука. Видно, что с таким винтом можно делать странички по 4к и он будет их отдавать довольно шустро. Всё равно, конечно, рандомное чтение из памяти будет на порядки быстрее
Это если брать полный цикл чтения одного блока, но это никогда не требуется.
Классический сервак баз данных создаёт очереди обработки, как раз через эти очереди насыщается пиковая пропускная способность.
Обрати внимание на графике на размер очереди самого накопителя.
А так-то есть накопители и с большим размером очереди.
S>поэтому пересылка result set через границу процесса будет нам стоить пренебрежимо мало по сравнению со стоимостью исполнения запроса на диск.
Ай, какое нубство...
Драйвер может помещать в очередь за раз кучу запросов к диску и за одно прерывание тоже выгребается куча же ответов.
А в твоём варианте мы имеем от сервака приложений сотни/тысячи коннекшенов к SQL-серваку одновременно, где в каждый коннекшен серваку надо отдать данные индивидуально. Из-за этого не получается "размазать" затраты на одну операцию ввода/вывода на сотни логических прикладных операций.
Судя по всему, ты не понимаешь примеры группировки операций, которые я постоянно привожу.
V>>А теперь я их лишь озвучиваю, бо, прямо скажем, твои представления на уровне слухов и обычного для прикладников тех лет непонимания.
S>Какие представления?
Да хотя бы почему приложение на дельфях медленнее работает с базами данных при отображении в таблицах.
Сейчас-то это трудно заметить, а в 96-м году это было более чем очевидно, особенно при листании выборок в таблицах.
Насчёт FoxPro аналогично — такая же точно ошибка в архитектуре и пой же самой причине тормоза, GUI морозилось, пока все данные для отображаемых строк не прочитает. ))
Учитывая, что мы уже выяснили, что ты не понимал, что такое ISAM, приходится объяснять, какой от него вообще толк, т.е. как именно с этим подходом можно эффективно работать.
V>>Не знаю в каком году. В 96-м tabstop работал по таким компонентам коряво — сначала проходился по windowed-контролам и лишь потом, когда доходила очередь до самой формы, она проходилась по windowsless.
S>В 96м — это, наверное, ещё Delphi 1.0? 16-разрядный? Не помню, не застал.
И в институте не программировал ни разу?
V>>Да вот не просто. Сначала надо освободить ДРУГОЙ буфер со скидыванием его содержимого на диск, если мы нагруженно через эту кухню работаем.
S>Зачем нам освобождать "другой" буфер? Пишем в буфер 1 — отдаём клиенту — пишем в буфер 2. Получили сигнал "давай ещё" — говорим клиенту "смотри буфер 2", и пишем в буфер 1.
Опять какой-то детсад, сорри.
Ключевое выделил.
Пока у клиента "живой" рекордсет на руках, выделенная под него shared-память будет только расти.
Избежать этого можно только при открытии рекодрсета в режиме forward only, но такой рекордсет нельзя было напрямую прибиндить к форме в Дельфи, Фокспро или MS Access.
Т.е., с единственным "лекарством" от этой болезни можно было работать лишь обслуживая низкоуровневую механику ручками. К чему я и пришел в итоге, после серии экспериментов с локальным кешированием записей. Потому что выбора у меня всё-равно не было, ведь после выхода 7-го MS SQL альтернативы ему для "обычного" железа, считай, отсутствовали. А его ни in-proc не подключить, ни написать свой драйвер передачи данных для сервака, есть лишь выбор из предоставляемого. Вот и выкручивайся.
V>>Пфф... Вопрос в том СКОЛЬКО раз потребуется переключать контекст?
S>Ну всяко меньше раз, чем при чтении файла по кускам.
Файл читается большими страницами. Почти всегда за раз скидывается или читается большое кол-во страниц. Т.е. затраты одной IO-операции неплохо "размазываются" по большой группе логических операций. Этот механизм включён в саму операционку.
V>>Про "нет копирований" булшит в обсуждаемом сценарии.
V>>Сервак же не маппированные области базы данных возвращает а формирует в памяти представление твоего рекордсета.
S>Ну да, всё верно. И in-proc сервер делает то же самое. Рекордсет-то точно такой же.
Разве что контекст исполнения на кажду порцию данных переключать не надо.
А, может, ты забыл, что операции записи в shared-память провоцируют исключения ОС?
Поэтому, писать в такую память "построчно" точно так же глупо.
Поэтому и было глупо насчёт "зато нет копирования".
Не всё, что написано на Stack Overflow является истинной. Даже если у поста стоит десяток плюсов. ))
V>>Можно сразу писать результат "туда".
V>>Опять же, глупо возвращать ВСЕ данные сразу, их надо возвращать порциями, чтобы обрабатывать в "оперативной" манере.
S>Буфер — наше всё.
Межпроцессный дорог.
А межпотоковый у меня "размазывает" одну операцию синхронизации стоимостью 1 микросекунду на сотни/тысячи сообщений в lock-free межпотоковых буферах.
V>>Я пол-года не выкатывал свою первую систему с использованием SQL-севака, потому что при обычном, принятом по-умолчанию "построчном" редактировании, т.е. с сохранением каждой строки, впечатление было ужасным после варианта с файловой базой.
S>Естественно. Некурящие люди так не делали ни в какие годы.
Примерно с 2000-го года делали аж бегом. ))
Хотя тут характерно твоё согласие, хотя были возражения на это же выше.
Сам себе противоречишь.
S>Сохранение делалось "потранзакционно", а строки заказа лежали в памяти.
А когда их сотни и тут связь с серваком глюкнулась, то амба. ))
Поэтому, на MS Access и было удобно, что это и GUI-прога и локальная шустрая база одновременно.
А так-то я в период фрилансерства как раз выполнил один такой заказик для целого семейства систем на Дельфи, который был TCP проксей и "держал" TCP-связь что со стороны клиента, что со стороны сервака, пока связь восстанавливалась. Бо терять прилично наработанного времени всегда обидно, скажем, человек долго редактировать большой заказ и несколько раз его перепроверял перед сохранением.
V>>Зачем?
S>Для масштабирования.
А что сначала надо масштабировать — базу или сервак приложений? ))
Просто был опыт писания сервака приложений и на нейтиве, так вот, надобность "масштабирования" волшебным образом уменьшается примерно в 10 раз. Т.е. он допускает вдесятеро большую нагрузку, чем явовские или дотнетные серваки.
И даже сложно придумать такое применение, где бы потребовалось то самое "масштабирование".
Вон ты сам писал, что RSDN работает на скромном железе для его популярности.
А популярность, действительно, нехилая.
Для нейтивной такой системы нужно было бы в 10 раз более скромное железо для того же отклика.