Re[11]: диалог с любителями потоков
От: Sinclair Россия https://github.com/evilguest/
Дата: 09.07.09 04:23
Оценка:
Здравствуйте, gandjustas, Вы писали:
G>В axum есть возможность делать асинхронные вызовы, выглядяще как синхронные и запускать множество таких параллельно.
Вот надо бы поглядеть. Пока руки не доходят.
G>Причем средставми метапрограммирования имхо тоже самое достижимо будет и в nemerle.
Вот-вот. Я лично от немерле ожидаю как раз возможностей обставить шарп именно в быстром применении таких вот штук.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: диалог с любителями потоков
От: Gomes Россия http://irazin.ru
Дата: 09.07.09 05:00
Оценка:
Здравствуйте, Sinclair, Вы писали:

VD>>А меня и уверять не надо. Я и так заню, что подход фиговенький.

S>Ну, я не стану давать тебе советов, но лично я бы сначала ознакомился с предметом. А уже потом делал выводы.

Как прежде люди были просты: они знали только то, чему учились. Ныне, ничему не учась, все знают.

М. Ю. Лермонтов
Re[9]: диалог с любителями потоков
От: Gomes Россия http://irazin.ru
Дата: 09.07.09 05:36
Оценка: +2
Здравствуйте, VladD2, Вы писали:

VD>Не тебе судить о том в чем я разбираюсь.

Твои посты обо всем говорят. Только никто тебе это прямо сказать не захотел.

VD>Ты никто и зовут тебя никак.

Базару нет. Зато о тебе вчера по первому каналу рассказывали.

VD>Так что спрашивать тебя мне не о чем. Одью.

Угу.
Re[10]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.09 18:43
Оценка:
Здравствуйте, Sinclair, Вы писали:

VD>>Про сокеты речи и не шало. Речь шла о праллельных запросах.

S>Не очень понятно, что такое "запрос" в твоей интерпретации.

Длч HTTP — GET/POST и т.п. А вообще физическое обращение к серверу (не просто открытый сокет).

VD>>И более 10 их окучить не удастся. При этом будет не хилый оверхэд на переключение контекста.

S>А кто тебе сказал, что будут вообще переключения контекста?

Наличие 10 параллельно работающих потоков с одинаковым приоритетом.

VD>>Почитай про эрланг. Для него (хотя язык интерпретатор) и 1000 праллельно работающих задач — это нормально.

S>Ты намекаешь на то, что в эрланге низкая стоимость переключения контекста?

Почти никакая.

S>Потому что получить 1000 параллельно работающих задач на 4х ядрах невозможно — всё равно 996 будут ждать исполнения. Чудес не бывает.


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

VD>>А меня и уверять не надо. Я и так заню, что подход фиговенький.

S>Ну, я не стану давать тебе советов, но лично я бы сначала ознакомился с предметом. А уже потом делал выводы.

Ну, дык ознакомься. Только сразу с двумя. Тогда и поговорим. ОК?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: диалог с любителями потоков
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.07.09 02:51
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Длч HTTP — GET/POST и т.п. А вообще физическое обращение к серверу (не просто открытый сокет).

А что значит "параллельно"? Для меня сеанс GET/POST неразрывно связан с сокетом: он начинается с открытия сокета, и заканчивается (иногда) закрытием.
Мне не очень понятно, можно ли говорить о каком-то запросе, пока нет открытого сокета (или хотя бы ожидающего accept).


VD>Почти никакая.

Я в курсе.

S>>Потому что получить 1000 параллельно работающих задач на 4х ядрах невозможно — всё равно 996 будут ждать исполнения. Чудес не бывает.

VD>Для клиентов их запросы будут обработаны параллельно. И это главное.
Ну конечно же не будут. Чудес не бывает.
VD>Потоки дороговаты для таких задачей.
Совершенно верно. Поэтому никто не применяет 1 поток на 1 клиента. Делают легковесные потоки. В Эрланге это просто реализовано из коробки; остальным приходится прогибаться вручную.
VD>Ну, дык ознакомься. Только сразу с двумя. Тогда и поговорим. ОК?
Продолжаю непонимать, чего именно я не знаю об Эрланге такого, чтоб не мог рассуждать о его производительности применительно к протоколу HTTP.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.07.09 19:58
Оценка: +1 -1
Здравствуйте, Sinclair, Вы писали:

S>>>Потому что получить 1000 параллельно работающих задач на 4х ядрах невозможно — всё равно 996 будут ждать исполнения. Чудес не бывает.

VD>>Для клиентов их запросы будут обработаны параллельно. И это главное.
S>Ну конечно же не будут. Чудес не бывает.

Если хоть сто раз повторить "сахар" то сладче не станет.
Та же фигня и тут. Хоть 100 раз повтори ничего не изменится.
Чудес конечно не бывает, на многозадачность на основе переключения задач никто не отменял. Для клиента важно не то за сколько выполнен его запрос, а то через сколько он начнет получать ответ. Если его запрос простоит в очереди 10 секунд, а потом будет выполнен за 0.001 секунды, то для него это будет медленно.

VD>>Потоки дороговаты для таких задачей.

S>Совершенно верно. Поэтому никто не применяет 1 поток на 1 клиента. Делают легковесные потоки. В Эрланге это просто реализовано из коробки; остальным приходится прогибаться вручную.

Я не очень понимаю о чем в данном случае идет речь. В IIS используются полноценные потоки. Комплейшон порты и очереди — это конечно хорошие оптимизации, но только для подхода где нет легких потоков (а лучше процессов).

Тут все, как бы, очень просто. Для работы программисту удобнее чтобы каждый отдельный запрос выполнялся бы в отдельном потоке или процессе. Если поток/процесс дешев, то это отличное решение, причем, не требующее дополнительных оптимизаций. Но потоки в современных ОС не дешевы. Переключение контекста дорогое удовольствие. Причем чем больше переключений (т.е. больше потоков) тем дороже.

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

Уверен, что производительность при этом увеличилась бы очень существенно.

Собсвтенно к чему я виду. Идея создавать по потоку на запрос — очень сдравая идея. Проблема только в стоимости переключения контекста. Снизить ее и все будет ОК. А пока что получается, как всегда, выбор из двух зол наименьшего. Мы все же имеем отдельные потоки на каждый запрос, но с кучей оптимизаций и прогибов (это я про очереди ожидания).

VD>>Ну, дык ознакомься. Только сразу с двумя. Тогда и поговорим. ОК?

S>Продолжаю непонимать, чего именно я не знаю об Эрланге такого, чтоб не мог рассуждать о его производительности применительно к протоколу HTTP.

Протокол тут индифферентен. Тут важна сама идея массово-парцелльных вычислений. Дешевые процессы и посылка сообщений. Как только мы имеем две этих вещи, то идея по потоку на запрос становится совершенно здравой. Ну, возможно по потоку на сессию, чтобы было где состояние хранить и не надо было бы огромный влюстэйт гонять (или в БД его пихать).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.07.09 20:01
Оценка:
Здравствуйте, Sinclair, Вы писали:

G>>Причем средставми метапрограммирования имхо тоже самое достижимо будет и в nemerle.

S>Вот-вот. Я лично от немерле ожидаю как раз возможностей обставить шарп именно в быстром применении таких вот штук.

Дык надо не ожидать, а взять и сделать то что хочется .

В прочем, системные вещи макросам не по зубам. Реализовать легкие потоки/процессы будет весьма затруднительно. Если только, как в yeild-е, переписывать код в конечный автомат. Но и это не просто.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: диалог с любителями потоков
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 11.07.09 08:57
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Собсвтенно к чему я виду. Идея создавать по потоку на запрос — очень сдравая идея. Проблема только в стоимости переключения контекста. Снизить ее и все будет ОК.


Не только в переключении, но и в стоимости самого контекста. Когда на стек даётся 1M, это много, даже если из них используется на каждую нить дай бог 30K, затраты идут на размер виртуальной памяти, на страничный механизм и так далее. Преимущества сред стиля Эрланга ещё и в том, что там можно использовать столько памяти на нить (процесс), сколько реально нужно (ну, максимум в 2 раза за счёт аллокатора кучи). В нагрузочных тестах мы там спокойно рождали и по миллиону процессов, хотя при этом процессорам уже было явно тяжело. На видимых на уровне C тредах в этом случае кончилась бы любая виртуальная память.

VD>По уму в управляемых средах вроде донета и явы можно было бы значительно облегчить стоимость перключения контекста. Особенно это было бы легко сделать если бы эти среды поддерживали бы неизменяемые данные. Тогда можно было бы спокойно создавать 1000 виртуальных потоков или процессов, а всю байду вроде комплейшон потров и другой асинхронности заложить в библиотеки и рантайм.


В принципе не вижу препятствий к тому, чтобы так писать уже сейчас, с небольшой подпоркой в стиле green threads поверх обычных тредов. Но объекты придётся упрощать до данных:)
The God is real, unless declared integer.
Re[13]: диалог с любителями потоков
От: EvilChild Ниоткуда  
Дата: 11.07.09 14:18
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>В прочем, системные вещи макросам не по зубам. Реализовать легкие потоки/процессы будет весьма затруднительно. Если только, как в yeild-е, переписывать код в конечный автомат. Но и это не просто.


Посмотри на Kilim.
Домашняя страница давно лежит почему-то.
Если есть час времени, то можно глянуть видео.
now playing: Heartthrob — Signs
Re[13]: диалог с любителями потоков
От: EvilChild Ниоткуда  
Дата: 11.07.09 14:30
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Тут все, как бы, очень просто. Для работы программисту удобнее чтобы каждый отдельный запрос выполнялся бы в отдельном потоке или процессе. Если поток/процесс дешев, то это отличное решение, причем, не требующее дополнительных оптимизаций. Но потоки в современных ОС не дешевы. Переключение контекста дорогое удовольствие. Причем чем больше переключений (т.е. больше потоков) тем дороже.


Программисту скорее удобнее, чтобы код можно было писать в последовательном стиле.
Чтобы этого добиться необязательно заводить по потоку на обработку запроса.
Можно писать последовательный код, который потом компилятор подвергнет CPS преобразованию (см. Kilim и вроде Axum так же поступает).
Nemerle в теории такое должно быть под силу с помощью макросов.
Если сходишь по ссылкам из соседнего поста про Kilim — расскажи по зубам ли им такая трансформация.
now playing: Heartthrob — Interference
Re[13]: диалог с любителями потоков
От: mrTwister Россия  
Дата: 13.07.09 13:05
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Тут важна сама идея массово-парцелльных вычислений. Дешевые процессы и посылка сообщений.

Главное слово выделено. Особенность HTTP приложений в том, что там время, затрачиваемое на вычисления, ничтожно мало в сравнении с временем, затрачиваемым на IO.
лэт ми спик фром май харт
Re[14]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.07.09 18:50
Оценка:
Здравствуйте, mrTwister, Вы писали:

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

VD>>Тут важна сама идея массово-парцелльных вычислений. Дешевые процессы и посылка сообщений.

T>Главное слово выделено. Особенность HTTP приложений в том, что там время, затрачиваемое на вычисления, ничтожно мало в сравнении с временем, затрачиваемым на IO.


А кто сказал что IO там главное и по делу? И кто сказал, что всегда и везде IO занимает основное время?

К тому же что означает IO? Вот я нажимаю на ссылочку "Мой RSDN\Ответы мне" и сайт начинает безбожно тормозить. Это IO виноват? Мне кажется, что IO — это тоже вычисления в массе своей. Пользователю же важно чтобы он по быстрее получил отклик, а не то чем занят процессор сервера. А раз так то нам нужны более пораллельные решения которые обрабатывают данные более интеллектуально. И здесь мне кажется, идея обработки запросов пользователей в легких процессах намного лучше идеи возни с комплешон-портами, пулами потоков и в итоге с массовым переключением контекста потоков.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: диалог с любителями потоков
От: EvilChild Ниоткуда  
Дата: 13.07.09 19:31
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>А кто сказал что IO там главное и по делу? И кто сказал, что всегда и везде IO занимает основное время?


VD>К тому же что означает IO? Вот я нажимаю на ссылочку "Мой RSDN\Ответы мне" и сайт начинает безбожно тормозить. Это IO виноват? Мне кажется, что IO — это тоже вычисления в массе своей. Пользователю же важно чтобы он по быстрее получил отклик, а не то чем занят процессор сервера. А раз так то нам нужны более пораллельные решения которые обрабатывают данные более интеллектуально. И здесь мне кажется, идея обработки запросов пользователей в легких процессах намного лучше идеи возни с комплешон-портами, пулами потоков и в итоге с массовым переключением контекста потоков.


Я не в курсе как устроен сайт, но есть подозрение, что по нажатию тобой кнопки происходит запрос к серверу БД,
база небось на диске хранится к которому надо сходить, что суть IO.
Формирование HTTP ответа просто ерунда по сравнению с этим — какие там вычисления то?
Так что львиную долю времени твой запрос проводит в ожидании ответа от диска.
Наверняка там есть индексы, ядро держит в кэше куски БД, но это как раз оптимизации цель которых снизить стоимость этого самого IO.
now playing: Oliver Koletzki — Nascita Of The Monsters (Martin Patino Remix)
Re[15]: диалог с любителями потоков
От: mrTwister Россия  
Дата: 13.07.09 20:09
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А кто сказал что IO там главное и по делу? И кто сказал, что всегда и везде IO занимает основное время?


Опыт профилирования.
Именно поэтому многие высоконагруженные веб-приложения написаны на тормозных скриптовых языках.

VD>К тому же что означает IO? Вот я нажимаю на ссылочку "Мой RSDN\Ответы мне" и сайт начинает безбожно тормозить. Это IO виноват?


Да. Тут имеют место массовые обращения через порты ввода-вывода к БД, распределенному кешу, файловой системе и т.д.

VD>Мне кажется, что IO — это тоже вычисления в массе своей.


Это неважно, что там внутри. Базе данных плевать на то, какого цвета потоки у веб-сервера: зеленые или ещё какие. Ей пришел запрос на IO порт, БД запрос обработала, и выплюнула обратно ответ. Веб сервер всё это время ждал, а не занимался никакими вычислениями.
лэт ми спик фром май харт
Re[16]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.07.09 16:43
Оценка:
Здравствуйте, mrTwister, Вы писали:

VD>>А кто сказал что IO там главное и по делу? И кто сказал, что всегда и везде IO занимает основное время?


T>Опыт профилирования.


Твой? Это уже является показателем?

T>Именно поэтому многие высоконагруженные веб-приложения написаны на тормозных скриптовых языках.


Я таких не знаю. Ну за исключением тех что написаны на Эрланг. Только это как раз совершенно другой случай.

VD>>К тому же что означает IO? Вот я нажимаю на ссылочку "Мой RSDN\Ответы мне" и сайт начинает безбожно тормозить. Это IO виноват?


T>Да. Тут имеют место массовые обращения через порты ввода-вывода к БД, распределенному кешу, файловой системе и т.д.


А СУБД, по-твоему, только к дискам обращается? Данные она не обрабатывает? План построения запросов, соеденения, фильтрацию, кэширование не она делает? На это время не тратится?

VD>>Мне кажется, что IO — это тоже вычисления в массе своей.


T>Это неважно,


Это очень важно! Только это и важно. Если бы все упиралось в медленные устройства ввода-вывода вроде дисков, то твоя позиция имела бы смысл. А так, 99% времени, при обработке веб-запроса, тратится на вычисления. Если бы они работали параллельно и с минимальными затратами, то пользователи были бы удовлетворены. А так пользователь ждет, железо занимается непроизводительными вычислениями, а горе программисты оправдывают эту ситуацию разными глупостями.


T> Базе данных плевать на то, какого цвета потоки у веб-сервера: зеленые или ещё какие. Ей пришел запрос на IO порт, БД запрос обработала, и выплюнула обратно ответ. Веб сервер всё это время ждал, а не занимался никакими вычислениями.


Это махровая чушь. Процессоров в сервере ограниченное количество. Если веб-сервер ждет ответ от СУБД, то процессор занимает СУБД. Это ни разу не ускоряет ни ответ текущему пользователю, ни параллельным.

Если бы веб-сервер и СУБД работали в легких процессах, то при передаче запросов от одного к другому не пришлось бы переключать контекст потока ОС (вызов можно было бы осуществить в рамках того же потока), а сам вызов стоил бы многократно дешевле.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.07.09 18:21
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>Я не в курсе как устроен сайт, но есть подозрение, что по нажатию тобой кнопки происходит запрос к серверу БД,

EC>база небось на диске хранится к которому надо сходить, что суть IO.

База, точнее часто используемая ее часть, сидит в памяти (в кэше). Так что обращение к БД в большинстве случае выливается в виртуальный IO, что на самом деле есть вычисления.

EC>Формирование HTTP ответа просто ерунда по сравнению с этим — какие там вычисления то?


Разнообразные. Я их уже перечислял. Превратить строковый запрос в набор данных — это не самая простая задача. И уж точно не IO в ней главное.

EC>Так что львиную долю времени твой запрос проводит в ожидании ответа от диска.


Хрен там. Диски в основном работают только на запись.

EC>Наверняка там есть индексы, ядро держит в кэше куски БД, но это как раз оптимизации цель которых снизить стоимость этого самого IO.


Более верно будет сказать — устранить необходимость в реальном ИО.

Могу сказать за наш сайт. Основное повышение производительности сайта достигалось установкой моря памяти и кучи процессоров. Сейчас на сервере стоит 16 гиг памяти и 8 ядер (два процессора).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: диалог с любителями потоков
От: EvilChild Ниоткуда  
Дата: 14.07.09 18:49
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>База, точнее часто используемая ее часть, сидит в памяти (в кэше). Так что обращение к БД в большинстве случае выливается в виртуальный IO, что на самом деле есть вычисления.

Неужто все только и делают, что смотрят ответы тебе? Объём БД какой? Очень сомнительно, что такие редкоиспользуемые данные будут в кеше, разве, что памяти совсем немерянно. Но ты ближе к телу сайта — тебе виднее, спорить не стану.

EC>>Формирование HTTP ответа просто ерунда по сравнению с этим — какие там вычисления то?


VD>Разнообразные. Я их уже перечислял. Превратить строковый запрос в набор данных — это не самая простая задача. И уж точно не IO в ней главное.


Превратить строковый запрос в набор данных — это отравить текст запроса базе и перелить построчно данные из датаридера в хттп ответ?
С точки зрения кода твоего приложения IO здесь и вправду немного и он относительно дёшев, настоящий IO в БД происходит и сдаётся мне, что он существенно дороже.

EC>>Так что львиную долю времени твой запрос проводит в ожидании ответа от диска.


VD>Хрен там. Диски в основном работают только на запись.


А из БД в память данные как попадают? через астрал?

EC>>Наверняка там есть индексы, ядро держит в кэше куски БД, но это как раз оптимизации цель которых снизить стоимость этого самого IO.


VD>Более верно будет сказать — устранить необходимость в реальном ИО.


VD>Могу сказать за наш сайт. Основное повышение производительности сайта достигалось установкой моря памяти и кучи процессоров. Сейчас на сервере стоит 16 гиг памяти и 8 ядер (два процессора).


Вы одномоментно их ставили или сначало одно, потом другое?
now playing: Dominik Eulberg — Afraid Of Seeing Stars?
Re[17]: диалог с любителями потоков
От: BulatZiganshin  
Дата: 14.07.09 20:39
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Могу сказать за наш сайт. Основное повышение производительности сайта достигалось установкой моря памяти и кучи процессоров. Сейчас на сервере стоит 16 гиг памяти и 8 ядер (два процессора).


кстати, про intel x-25m я надеюсь вы в курсе
Люди, я люблю вас! Будьте бдительны!!!
Re[12]: диалог с любителями потоков
От: BulatZiganshin  
Дата: 14.07.09 20:49
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>>>Потому что получить 1000 параллельно работающих задач на 4х ядрах невозможно — всё равно 996 будут ждать исполнения. Чудес не бывает.

VD>>Для клиентов их запросы будут обработаны параллельно. И это главное.
S>Ну конечно же не будут. Чудес не бывает.
VD>>Потоки дороговаты для таких задачей.
S>Совершенно верно. Поэтому никто не применяет 1 поток на 1 клиента. Делают легковесные потоки. В Эрланге это просто реализовано из коробки; остальным приходится прогибаться вручную.
VD>>Ну, дык ознакомься. Только сразу с двумя. Тогда и поговорим. ОК?
S>Продолжаю непонимать, чего именно я не знаю об Эрланге такого, чтоб не мог рассуждать о его производительности применительно к протоколу HTTP.

вопрос наверно в том, что зелёные потоки должны поддерживаться на уровне вычислительной модели RTS. поскольку нужна синхронизация объектов при попытке одновременного доступа/обновления. что в свою очередь имеет смысл в основном при immutable objects

поэтому 1000 потоков конечно одновременно не работает. вопрос в том, что в отличие от обычных языков программисту удобно программировать (не надо самому заниматься имитацией наличия множества потоков и синхронизация всех мутабельных объектов обходится достаточно дёшево. it just works. а организации пулов потоков и борьбе за синхронизацию мутабельных объектов целые книжки посвящают
Люди, я люблю вас! Будьте бдительны!!!
Re[17]: диалог с любителями потоков
От: mrTwister Россия  
Дата: 15.07.09 08:14
Оценка: +3 -1
Здравствуйте, VladD2, Вы писали:

T>>Опыт профилирования.

VD>Твой? Это уже является показателем?
Разумеется. "Практика — критерий истины" (с)

T>>Именно поэтому многие высоконагруженные веб-приложения написаны на тормозных скриптовых языках.

VD>Я таких не знаю. Ну за исключением тех что написаны на Эрланг. Только это как раз совершенно другой случай.
Ну вот, например, эти были написаны на PHP: Facebook, Wikipedia (MediaWiki), Yahoo!, WordPress, YouTube, MyYearbook, Digg, Joomla, Tagged.

T>>Да. Тут имеют место массовые обращения через порты ввода-вывода к БД, распределенному кешу, файловой системе и т.д.

VD>А СУБД, по-твоему, только к дискам обращается? Данные она не обрабатывает? План построения запросов, соеденения, фильтрацию, кэширование не она делает? На это время не тратится?

Клиенту СУБД (то есть Web-серверу в нашем случае) совершенно плевать, что там делается внутри СУБД. Клиент общается с базой через порты ввода-вывода (сеть, трубы). В этом смысле, для него любое обращение к базе — это стандартная IO операция, которая отлично ложится на IOCP.

VD>>>Мне кажется, что IO — это тоже вычисления в массе своей.

T>>Это неважно,

VD>Это очень важно! Только это и важно. Если бы все упиралось в медленные устройства ввода-вывода вроде дисков, то твоя позиция имела бы смысл. А так, 99% времени, при обработке веб-запроса, тратится на вычисления. Если бы они работали параллельно и с минимальными затратами, то пользователи были бы удовлетворены. А так пользователь ждет, железо занимается непроизводительными вычислениями, а горе программисты оправдывают эту ситуацию разными глупостями.

Вычислениями занимается не Web-сервер (о котором идет речь в этой ветке) а СУБД.

T>> Базе данных плевать на то, какого цвета потоки у веб-сервера: зеленые или ещё какие. Ей пришел запрос на IO порт, БД запрос обработала, и выплюнула обратно ответ. Веб сервер всё это время ждал, а не занимался никакими вычислениями.

VD>Процессоров в сервере ограниченное количество. Если веб-сервер ждет ответ от СУБД, то процессор занимает СУБД. Это ни разу не ускоряет ни ответ текущему пользователю, ни параллельным.

VD>Если бы веб-сервер и СУБД работали в легких процессах, то при передаче запросов от одного к другому не пришлось бы переключать контекст потока ОС (вызов можно было бы осуществить в рамках того же потока), а сам вызов стоил бы многократно дешевле.


Чтобы Web-сервер по сети обращался к СУБД, которая находится на другой машине и при этом выполнение запроса бы происходило в одном процессе и потоке с Web-сервером — это круто!!!
лэт ми спик фром май харт
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.