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

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

Компиллируемые языки эффективнее скриптовых примерно на порядок.
А два порядка — это эффект уже от СМО, на этом и строился рассчёт.


S>Даже если мы рассматриваем только pure и deterministic запросы, обеспечение ACID накладывает свои ограничения.

А что тут нового?
Там как в любом другом наборе ресурсов и очередей к ним.


S>Т.е. при самом неоптимальном query plan, основные тормоза будут даже не на интерпретации выражений вроде GetIntFieldByOffset()*GetDecimalFieldByOffset(), а на захвате блокировок.

Эээ, тормоза на блокировках зависят от частоты конфликтов квадратично.
В этом прелесть механизмов СМО и засада одновременно.
Т.е. слишком большой штраф при увеличении конфликтов, но и уменьшение конфликтов происходит в квадратичной зависимости от улучшения эффективности.

В общем, есть такая дисциплина — теория массового обслуживания, я одно время плотно по ней упражнялся.

Она простая и одновременно мощная — там 3-4 основные формулы всего (три основных вида распределения плотности потока заявок, но можно взять нормальное распределение для простоты), с помощью этого аппарата можно расписать вообще всё происходящее в IT в плане обсуждаемого, т.е. работу любых сервисов, локального пула потоков IO и задач, общение многих независимых программ и/или многих независимых сетевых соединений одной программы (а так же в произвольном сочетании) через одну сетевую карту и т.д..

К каждому ресурсу приписывается трафик заявок и среднее время обработки заявки в отсутствии ожидания.
Можно найти среднюю длину очереди, можно найти среднее время ожидания в очереди и т.д., так как основной закон прост аки закон Ома.

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

Т.е., при уменьшении времени обработки каждой заявки на порядок, время ожидания в очереди изменится на два порядка при том же трафике.

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

Если в 10 — то в 100.
Т.е. заменили скриптовую машинку на компиллируемый код — получили из одной машины аналог развёрнутого кластера на 100 узлов (при этом сам механизм организации кластера всё еще сферический и ничего не стоит).

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

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

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


S>И если мы его скомпилируем в бинарь, устранив интерпретатор, то захват/отпускание блокировок никуда не денутся.
S>Ну, впрочем, это всё ещё такие, прикидки на пальцах.

И одновременно с этим еще больше начинаю тебя не понимать уже я...

Обрати внимание на мою тактику: я первым делом выясняю мотивы — что, куда, зачем, сколько это даст? Какой ценой?
Если дебет с кредитом даёт неплохой расклад — можно и углубиться.
Иначе тема сворачивается сходу (по крайней мере моё в ней участие... ну кроме когда чел начинает заниматься откровенным вредительством, типа как был тут один проповедник русификации всего российского программирования, и складно ж звидел, в чём основное вредительство и состояло).

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

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

Компиллируемые языки эффективнее скриптовых примерно на порядок.
А два порядка — это эффект уже от СМО, на этом и строился рассчёт.


S>Даже если мы рассматриваем только pure и deterministic запросы, обеспечение ACID накладывает свои ограничения.

А что тут нового?
Там как в любом другом наборе ресурсов и очередей к ним.


S>Т.е. при самом неоптимальном query plan, основные тормоза будут даже не на интерпретации выражений вроде GetIntFieldByOffset()*GetDecimalFieldByOffset(), а на захвате блокировок.

Эээ, тормоза на блокировках зависят от частоты конфликтов квадратично.
В этом прелесть механизмов СМО и засада одновременно.
Т.е. слишком большой штраф при увеличении конфликтов, но и уменьшение конфликтов происходит в квадратичной зависимости от улучшения эффективности.

В общем, есть такая дисциплина — теория массового обслуживания, я одно время плотно по ней упражнялся.

Она простая и одновременно мощная — там 3-4 основные формулы всего (три основных вида распределения плотности потока заявок, но можно взять нормальное распределение для простоты), с помощью этого аппарата можно расписать вообще всё происходящее в IT в плане обсуждаемого, т.е. работу любых сервисов, локального пула потоков IO и задач, общение многих независимых программ и/или многих независимых сетевых соединений одной программы (а так же в произвольном сочетании) через одну сетевую карту и т.д..

К каждому ресурсу приписывается трафик заявок и среднее время обработки заявки в отсутствии ожидания.
Можно найти среднюю длину очереди, можно найти среднее время ожидания в очереди и т.д., так как основной закон прост аки закон Ома.

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

Т.е., при уменьшении времени обработки каждой заявки на порядок, время ожидания в очереди изменится на два порядка при том же трафике.

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

Если в 10 — то в 100.
Т.е. заменили скриптовую машинку на компиллируемый код — получили из одной машины аналог развёрнутого кластера на 100 узлов (при этом сам механизм организации кластера всё еще сферический и ничего не стоит).

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

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

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

Кстате, принципиальное отделение текущих/оперативных данных от т.н. "исторических" тоже даёт сравнимый чудовищный эффект.
На своей заднице испробовал когда-то, да еще на тормознутой технике конца 90-х — начала нулевых, когда любые эффекты были ну уж слишком хорошо заметны.


S>И если мы его скомпилируем в бинарь, устранив интерпретатор, то захват/отпускание блокировок никуда не денутся.
S>Ну, впрочем, это всё ещё такие, прикидки на пальцах.

И одновременно с этим еще больше начинаю тебя не понимать уже я...

Обрати внимание на мою тактику: я первым делом выясняю мотивы — что, куда, зачем, сколько это даст? Какой ценой?
Если дебет с кредитом даёт неплохой расклад — можно и углубиться.
Иначе тема сворачивается сходу (по крайней мере моё в ней участие... ну кроме когда чел начинает заниматься откровенным вредительством, типа как был тут один проповедник русификации всего российского программирования, и складно ж звидел, в чём основное вредительство и состояло).