Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Только ты забыл одну интересную вещь — это все критично для 32 бит, а 32битные серверные винды уже много лет не выпускаются. Ах да, я забыл, чуть менее чем все С++ приложения портировать на 64 бита — изрядный геморой.
Уже лет 10 пишу код, который компилируется и в 32 и в 64 бита. В С++ есть такая удобнейшая штука, как typedef, которая разруливает подобные моменты. В Линухах тоже уже лет 10 все программы компилируются на любой target.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>>>Пока не увижу в новостях, что где-то вышел движок биржи на Linq или банковский оп-день — это всё сказки про белого бычка. G>>>>А ты видишь в новостях про биржи на ODBC или опердни на ADO?
V>>>Твой вопрос лишен смысла. G>>Также как и твой.ODBC и ADO такие же технологии работы с данными, как и EF.
V>>>Биржи написаны на С/С++. ВСЕ единицы попыток переписать биржи на дотнет закончились отказом от этих попыток. G>>Я знаю только одну историю про LSE, у тебя еще есть? V>Э, нет. В случае LSE биржа реально перешла на дотнет, а потом вернулась. А так-то многие ведущие биржи активно внедряли дотнет. Просто, в случае именно "движка" биржи, до релиза дело не дошло.
Где доказательства твоим словам?
Кстати только что появилась новость, что московская биржка упала и судя по лентам падает регулярно. А она как раз на C++. Вот тебе нэйтив и надежность.
V>>>Наиболее часто вызываемые рантайм-транзакции в оперднях банков сделаны на хранимках. G>>Не факт что это хорошо.
V>Зато безопасно. Потому что, если процессить внешним серваком — то это можно быстро, конечно, но встаёт вопрос об журналинге транзакций в БД — в случае непредвиденности можно потерять транзакции за последние миллисекунды. А это ну ваще никак нельзя. А если делать на внешнем серваке приложений т.н. "длинные транзакции", то резко падает производительность. Поэтому, самые частовызываемые вещи делают в БД. В принципе, возможность писать хранимки на дотнете может помочь.
А при чем тут хранимки? Транзакции и батчи отменили? Чем хранимка лучше запроса, отправленного с клиента? Все равно одна транзакция это один insert, больше не нужно. Если кто-то написал, то это не значит, что это правильно.
V>>>Linq — это не просто генератор запросов, это еще мега-удобный маппер их результатов. В нейтиве такое на сегодня, увы, никак в подобном виде. В нейтиве код маппинга обычно генерируют отдельной тулзиной, типа http://www.qxorm.com/qxorm_en/home.html или http://www.codesynthesis.com/products/odb/, а то и просто ручками, см. boost::serialization. Только в следующем стандарте С++ ожидается, наконец, стандарт на ABI и на метаинформацию... только тогда можно будет делать сравнимые в плане удобства для разработчика мапперы на плюсах, без необходимости подключать и настраивать внешние утилиты для процесса разработки.
G>>При чем тут маппер?
V>Потому что для нейтива это самая болезненная часть.
G>>Код на C++ уже научился запросы генерить из лямбд?
V>Да. В С++, в отличие от, можно переопределить вообще все операторы языка, даже операторы присваивания. Это позволяет в том же синтаксисе организовать некий query builder.
И оператор лямбды переопределять?
Покажи пример в конце концов чето-то похожего на linq to database.
G>>Маппер это малекькая часть, которая при наличии прямых рук пишется за неделю.
V>Я напишу тебе маппер на десяток объектов с помощью boost::serialization за единицы минут. Дальше что? По мере разработки этих объектов, добавления/удаления — ничего автоматом не происходит. Нужно ручками синхронизировать. Кароч, геммор не приведи господь, если этих объектов сотни. Поэтому с внешними тулзами удобнее, они дают хоть какую-то автоматизацию. Тебе не с чем сравнить, ты не понимаешь, насколько это круто — интегрированный маппер. )))
Еще раз повторю — маппер прямыми руками пишется за неделю. Уровня Dapper. На .NET. На C++ такое не пишется вообще, поэтому в корпоративной разработке и в вебе C++ сосет. Да и для большинства клиентских приложений сосет, по причине по той же причине.
G>>>>Но именно этот генератор запросов позволяет разрабатывать приложения с огромной скоростью, не нагружая DBA написанием селектов. V>>>Ну вот AVK утверждает, что он не пользуется специфическим Linq-синтаксисом. А используемый им синтаксис был доступен мне еще хрен его знает когда через самописный генератор запросов + маппинг через BLT. Более того, в нейтивных генераторах запросов тоже примерно такой же синтаксис, как показывает AVK. G>>Ну и пусть утверждает. Но AVK один, а Linq используют десятки или сотни тысяч.
V>>>Вот ты используешь синтаксис запросов Linq или пишешь в "классическом" стиле? G>>Конечно пишу Linq когда возможно. Более того, даже оптимизировал некоторые приложения переписывая с хранимок на Linq.
V>Ты не понял вопроса, походу. Библиотеку Linq можно использовать как обычную библиотеку, без использования в коде "синтаксиса запросов". Я спрашиваю — ты используешь этот новый синтаксис запросов или используешь Linq в виде вызовов обычных методов (методов-расширений в т.ч.)?
И то и другое, как удобнее.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>Кста. Народ уже экспериментирует на плюсах: V>https://github.com/k06a/boolinq
V>)))
Такие библиотеки с 2008 года плодятся со страшной скоростью. Вот только запросов к базе никто делать не умеет. Все только с массивами и работают.
Здравствуйте, gandjustas, Вы писали:
V>>Как же ты забодал уже своей... назовём это "неосведомлённостью". И ведь спешишь отвечать первый! V>>Кол-во одновременно открытых соединений/сессий может на порядки превышать кол-во потоков. Потоки обрабатывают запросы, а не соединения. G>Ты похоже вообще не понимаешь...
да-да
G>Один рабочий поток в один момент времени обрабатывает один запрос, для одного запроса достаточно одного соединения. Зачем иметь более одного соединения на поток?
Затем, что не факт, что соединение будет закрыто после запроса. Если браузер спрашивает ресурсы с этого же домена, то он может переиспользовать соединение. При нагрузке одновременно живут тысячи TCP-соединений. Твой пул потоков в ASP.Net тоже не фиксированный, может расти. Просто он не может падать ниже 50.
G>100 выбрано как раз из-за сценария asp.net, с учетом того что хреново написанный код может несколько соединений на один запрос использовать.
Нет, не из-за этого. А из-за того, что в хреново написанном коде не всегда явно вызывается Dispose, поэтому конекшен не возвращается в пул. А еще потому, что серверное приложение может что-то делать в фоне, поэтому коннекшен может жить гораздо дольше, чем запрос. А еще потому, что в случае асинхронщины мы на тех же 50 потоках можем одновременно обрабатывать хоть десятки-сотни тыщ соединений.
V>>Я выделил место, в котором ты подставился (опять) так, что мне хочется с тобой не общаться еще несколько лет. Нарисуй себе, что ле, на листике, как соотносятся сетевые TCP-сессии с потоками из пула. ))) А теперь, если асинхронно? )) G>Как раз об асинхронном я написал ниже, ты читаешь перед тем, как отвечать?
G>>>При применении асинхронных обработчиков HTTP может быть понадобится увеличить до 1000.
Ничего не надо. Если асинхронщина написана грамотно, то НЕ ТРЕБУЕТСЯ потоков больше, чем ядер в системе. В наших продуктах именно так. )) Но для дотнетчиков взят запас, потому что в обычном дотнетном коде асинхронный код запросто перемешивается с синхронным.
V>>Упереться очень просто. Без специальных настроек виндов под системную память будет выделено ограниченное пространство верхних адресов. Адресов, а не памяти, соображаешь? Т.е. даже при наличии дохрена свободной обычной памяти — ничего уже не поделать. G>А при чем тут адреса, если речь про дескрипторы? Для них не обязаны никакие адреса выделяться.
Для них выделяется системная память. Системная память сидит в определенном диапазоне адресов. Она мапится в адресное пространство каждого процесса при заходе в вызовы ядра.
G>Ну даже если предположить что чтототам выделяется, то все равно в пуле соединений по умолчанию не более 100 соединений, я видел единицы проектов где этого не хватало. Упереться в максимальное количество хендлов при этом нельзя.
Что-то ты заврался. Ты и не можешь увидеть, что этого не хватает. Просто соединения будут браться не из пула, а создаваться как обычные объекты. А затем лишние будут не возвращаться в пул, а просто удаляться.
G>До этого момента ты и не знал, что есть пул соединений, то есть в живую ты не мог этой картины наблюдать. Получается что это снова твои фантазии и не более того, все вылеты ado.net просто плод твоего воображения.
Какой же ты наивный даже для своего возраста. До "этого момента". Какая прелесть. Пройдись что-ле по дотнетным форумам здесь до 2005-го года. Я активно участвовал.
G>>>Будь добр укажи текст ошибки при "вылете ADO.NET", или приведи ссылку с описанием проблемы. А то ты сказки рассказываешь. Я 8 лет с .NET работаю (гораздо больше тебя судя по всему) и видел ошибок ADO.NET на порядок меньше, чем ты пишешь. V>>Считаю года я плохо, поэтому соглашусь, что ты длиннее. ))) G>Все таки укажи текст ошибки.
Всё-таки не наглей. Давно на игнор напрашиваешься. Твой опыт только на одном дотнете фактически никакой, мне реально все-равно, видел ты что-то или нет. Знач, мало работал. Знач, у вас нагрузка детская. 8 лет — это ни о чем в индустрии. И тем более ни о чем, если речь об одной только технологии. Тебе даже не с чем сравнить.
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>С чего ты решил, что ошибка была именно из-за дедлока? НС>А что, нет?
В случае дедлока соединение сбрасывается по заметному таймауту. Без такого таймаута — это не дедлок. Мгновенно выдаётся скрин с дефолтной растеризацией ошибки.
V>>И почему, если ошибка в дедлоке, то просто-напросто не переспросить запрос заново? НС>Потому что это нафик никому не нужно.
А как же "лицо" команды разработчиков?
Тем более, что это дело одной строчки.
НС>А при чем тут дотнет?
Так не было до переезда на него такого. Я не верю, что в течении пары месяцев после переезда настолько резко возросла нагрузка на сайт. Но эти экраны стали появляться оч оперативно после переезда.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>Как же ты забодал уже своей... назовём это "неосведомлённостью". И ведь спешишь отвечать первый! V>>>Кол-во одновременно открытых соединений/сессий может на порядки превышать кол-во потоков. Потоки обрабатывают запросы, а не соединения. G>>Ты похоже вообще не понимаешь...
V>да-да
G>>Один рабочий поток в один момент времени обрабатывает один запрос, для одного запроса достаточно одного соединения. Зачем иметь более одного соединения на поток?
V>Затем, что не факт, что соединение будет закрыто после запроса. Если браузер спрашивает ресурсы с этого же домена, то он может переиспользовать соединение. При нагрузке одновременно живут тысячи TCP-соединений. Твой пул потоков в ASP.Net тоже не фиксированный, может расти. Просто он не может падать ниже 50.
До .NET 4 был лимит по умолчанию в 50 потоков на одно приложение. После .NET 4 используется стандартный thread pool, который дает максимум 25 потоков на ядро. Количество соединений абсолютно нерелевантно этому числу. Соединение воовсе не обязательно должно поток занимать.
G>>100 выбрано как раз из-за сценария asp.net, с учетом того что хреново написанный код может несколько соединений на один запрос использовать.
V>Нет, не из-за этого. А из-за того, что в хреново написанном коде не всегда явно вызывается Dispose, поэтому конекшен не возвращается в пул. А еще потому, что серверное приложение может что-то делать в фоне, поэтому коннекшен может жить гораздо дольше, чем запрос. А еще потому, что в случае асинхронщины мы на тех же 50 потоках можем одновременно обрабатывать хоть десятки-сотни тыщ соединений.
Еще раз — пул был придуман задолго до того как асинхронщина в .NET была мейнстримом, и лимит в 100 очень хорошо отражает реалии asp.net того времени. В десктопном приложении вообще нет смысла иметь более одного активного соединения.
V>>>Я выделил место, в котором ты подставился (опять) так, что мне хочется с тобой не общаться еще несколько лет. Нарисуй себе, что ле, на листике, как соотносятся сетевые TCP-сессии с потоками из пула. ))) А теперь, если асинхронно? )) G>>Как раз об асинхронном я написал ниже, ты читаешь перед тем, как отвечать?
G>>>>При применении асинхронных обработчиков HTTP может быть понадобится увеличить до 1000.
V>Ничего не надо. Если асинхронщина написана грамотно, то НЕ ТРЕБУЕТСЯ потоков больше, чем ядер в системе. В наших продуктах именно так. )) Но для дотнетчиков взят запас, потому что в обычном дотнетном коде асинхронный код запросто перемешивается с синхронным.
Я вообще-то про кол-во соединений в пуле. Но обычно веб-сервер загибается раньше, чем забивает 100 соединений.
V>>>Упереться очень просто. Без специальных настроек виндов под системную память будет выделено ограниченное пространство верхних адресов. Адресов, а не памяти, соображаешь? Т.е. даже при наличии дохрена свободной обычной памяти — ничего уже не поделать. G>>А при чем тут адреса, если речь про дескрипторы? Для них не обязаны никакие адреса выделяться.
V>Для них выделяется системная память. Системная память сидит в определенном диапазоне адресов. Она мапится в адресное пространство каждого процесса при заходе в вызовы ядра.
Это не факт, у тебя есть доказательства твоих слов?
G>>Ну даже если предположить что чтототам выделяется, то все равно в пуле соединений по умолчанию не более 100 соединений, я видел единицы проектов где этого не хватало. Упереться в максимальное количество хендлов при этом нельзя.
V>Что-то ты заврался. Ты и не можешь увидеть, что этого не хватает. Просто соединения будут браться не из пула, а создаваться как обычные объекты. А затем лишние будут не возвращаться в пул, а просто удаляться.
Да конечно. Если соединения в пуле кончатся ты эксепшн получишь. Это ты выдумываешь небылицы уже несколько постов. Ты хоть знаешь как создать соединение с SQL Server без пулинга? Мне кажется что нет.
G>>До этого момента ты и не знал, что есть пул соединений, то есть в живую ты не мог этой картины наблюдать. Получается что это снова твои фантазии и не более того, все вылеты ado.net просто плод твоего воображения. V>Какой же ты наивный даже для своего возраста. До "этого момента". Какая прелесть. Пройдись что-ле по дотнетным форумам здесь до 2005-го года. Я активно участвовал.
Ты и тогда фантазировал во всю?
G>>>>Будь добр укажи текст ошибки при "вылете ADO.NET", или приведи ссылку с описанием проблемы. А то ты сказки рассказываешь. Я 8 лет с .NET работаю (гораздо больше тебя судя по всему) и видел ошибок ADO.NET на порядок меньше, чем ты пишешь. V>>>Считаю года я плохо, поэтому соглашусь, что ты длиннее. ))) G>>Все таки укажи текст ошибки.
V>Всё-таки не наглей. Давно на игнор напрашиваешься. Твой опыт только на одном дотнете фактически никакой, мне реально все-равно, видел ты что-то или нет. Знач, мало работал. Знач, у вас нагрузка детская. 8 лет — это ни о чем в индустрии. И тем более ни о чем, если речь об одной только технологии. Тебе даже не с чем сравнить.
Укажи текст ошибки, а то пока все это только твои фантазии.
Здравствуйте, vdimas, Вы писали:
V>В случае дедлока соединение сбрасывается по заметному таймауту.
Вовсе необязательно. Детектор может в ряде ситуаций обнаруживать дедлок сразу, без таймаута.
V>>>И почему, если ошибка в дедлоке, то просто-напросто не переспросить запрос заново? НС>>Потому что это нафик никому не нужно. V>А как же "лицо" команды разработчиков?
С ним все в порядке.
V>Тем более, что это дело одной строчки.
Дело тут далеко не в одной строчке.
НС>>А при чем тут дотнет? V>Так не было до переезда на него такого.
Это когда у сайта было полтора посетителя в день?
V> Я не верю, что в течении пары месяцев после переезда настолько резко возросла нагрузка на сайт. Но эти экраны стали появляться оч оперативно после переезда.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, vdimas, Вы писали:
V>>В случае дедлока соединение сбрасывается по заметному таймауту.
НС>Вовсе необязательно. Детектор может в ряде ситуаций обнаруживать дедлок сразу, без таймаута.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>Детектор дедлоков срабатывает каждые 500мс.
V>по умолчанию каждые 5 сек
Блин, 5000мс. Но при нахождении дедлока повторно срабатывает через 100мс, если не находит — интервал увеличивается.
Так что не обязательна заметная задержка. Если дедлоки появляются часто, то заметной задержки не будет.
Здравствуйте, gandjustas, Вы писали:
G>>>С .NET 2.0 SqlConnection поддерживает аснхронное чтение. Ты с 2005 года .NET то видел вообще?
V>>Вот, опять ты подставился. Это "асинхронное" чтение в дотнете сделано по технологии Completion Routines. G>Это асинхронное чтение сделано на базе нативного SNI.
Садись, два. SNI — это просто описание протокола. ЛЮБОЙ клиентский драйвер любой базы лишь реализует клиентскую часть этого протокола.
G>Так что все баги и сложность парсера — его следствие.
Баги парсера от убогого кода. Сложность там не большая, скорее — наоборот. Топорно в лоб написано, как студенты 2-го курса пишут лабораторки.
G>Веб-стек, например, не опирается на сложные и старые API, поэтому там прекрасно работает асинхронность.
Слышал звон, да не знаешь где он. На КАКОЙ именно асинхронной технологии работает Веб-стек?
А я тебе скажу — на никакой. Сидит хендлер событий на нейтивном АПИ IIS и вызывает дотнетный диспетчер.
Кароч, ты даже не в курсе, как работает твоя основная технология. Поздравляю, чо!
V>>Это предъявляет определённые требования к потоку, в котором это происходит. В результате, твоя асинхронщина подключается только тогда, когда ты вызываешь асинхронное же АПИ, иначе событие Completion Routines никогда не получит шанса на обработку. G>Логично, а ты что хотел?
А я хотел бы, чтобы completion routines исчезло раз и навсегда. Из всех асинхронных механизмов оно самое убогое и тормозное. К тому же с кучей ограничений. Но ты же не в курсе, видимо, что completion routines может работать в цикле GUI? Т.е. при заходе на SleepEx или WaitForXxxEx выполняются накопленные на тот момент completion routines. Прикинь, какая засада — пока ты сам не вызовешь определенные системные ф-ии, никакого колбека от асинхронщины не происходит. Т.е. вообще ничего не происходит. Именно поэтому так тормозят дотнетные асинхронные сокеты. А весь твой ASP.Net именно на них и написан. Просто в основном используется синхронное чтение и запись ответа, наверняка и у вас тоже. В общем, по характеристикам диспетчеризации нагрузки Asp.Net сосёт не нагибаясь. Слава богу, что основной трафик не на HTML-код, а на картинки и медиа.
G>Если ты используегшь синхронное API, то ты и так занимаешь поток, зачем нужно занимать еще один поток на Completion или любые другие пляски исполнять, если в итоге получатель данных работает синхронно?
Затем, чтобы пока ты выполняешь обработку поступившей порции данных, физическое устройство (вернее, его драйвер) могут заливать в твои буфера следующую порцию данных. А иначе, чтобы распараллелить обработку, на дотнете надо создать еще один поток, который будет заниматься сугубо выгребанием данных. А уже из этого потока передавать данные целевому. Правда, если бы еще дотнетчики lock-free умели хорошо... а то через дотнетную синхронизацию на мониторе убивается любая производительность.
Кароч, для того же TCP, чтобы поддерживать окно максимальным, необходимо оперативно выгребать данные из сокета. Для сравнения, дотнет не в состоянии нагрузить современные сетевые карточки, которые с легкостью нагружает нейтив. Разница в пропускной способности в среднем до 3-х раз. Чем меньшими порциями оперируем, тем больше разница вплоть до более 20 раз.
V>>Более того, для тех же злополучных блобов, когда ты открывал к нему Stream и читал из него асинхронно, то там асинхронность эмулировалась на стороне дотнета, реально её не было. G>Если у тебя не установлен CommandBehavior.SequentialAccess, то парсер TDS читает строку, а тебе отдает тупо MemoryStream. G>Если у тебя установлен CommandBehavior.SequentialAccess, то тебе отдается SqlSequentialStream, который таки асинхронно читает поток. Глянь в ILSpy — он ожидает сигнала получения пакета и копирует байты в выходной буфер.
Если аснхронно — то сам ничего не читает и не ожидает. Кароч, всё ясно, курить completion routines до просветления. Ты получаешь сигнал готовности данных не асинхронно, а только когда входишь в ожидание этого сигнала, т.н. alertable thread state. Получаешь сигнал готовности иногда с бооольшим опозданием, ведь ты заходишь в slertable state очень даже синхронно, причем, ты должен получить сигнал готовности в том же самом потоке, откуда ты начал "асинхронную" операцию. Поэтому, никакого load balancing. Поэтому, задержавшись по неким объективным причинам на обработке текущей порции данных от одной из асинхронных операций, ты тормозишь вообще все асинхронные операции, привязанные к данному потоку.
Сравнимая по убогости технология — только WsaSelect для сокетов. Но в нейтиве мы хоть можем выбирать, как работать из кучи вариантов. А вдотнете имеем нифига не масштабируемый ввод-вывод. Отсюда плачевные результаты по производительности этого ввода/вывода.
G>Ничего что GetStream появился в .NET 4.5, а ты рассказываешь про какие-то дремучие времена?
Ничего, ничего. Ты ж соврал про 8 лет на дотнете, походу.
Есть такой SqlBytes.Stream.
G>По моему эти ошибки только в твоем воображении существуют.
Рассуждая таким макаром, по твоему земля плоская. Ты же её и космоса не видел.
V>>И да. Упомянутый мною баг я обнаружил на 2-м дотнете, ес-но. И мне пришлось изучить код дотнетного клиентского драйвера под MS SQL фактически наизусть. А твоя распальцовка попросту смешна, бо ты в глаза не его видел и понятие не имеешь, как он работает. G>Ну ты окончательно заврался, GetStream появился только в .NET 4.5. G>До .NET 4.5 не было API для асинхронного чтения ридера.
Видишь суслика? А он есть! (С)
V>>Далее. В Windows есть минимум 4 способа организации асинхронщины. Так вот, OLEDB давал "правильную" работу с TCP-соединением, даже при обычном, т.е. блокирующем чтении из него. Потому что overlapped API позволяет не только ожидать готовности данных, но может "само" заливать данные в заранее подготовленные буфера. G>Ага, верю, чувак, верю. Жги дальше.
Порядком утомил своим невежеством и хамством. До встречи через годик-другой.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>>>С .NET 2.0 SqlConnection поддерживает аснхронное чтение. Ты с 2005 года .NET то видел вообще?
V>>>Вот, опять ты подставился. Это "асинхронное" чтение в дотнете сделано по технологии Completion Routines. G>>Это асинхронное чтение сделано на базе нативного SNI.
V>Садись, два. SNI — это просто описание протокола. ЛЮБОЙ клиентский драйвер любой базы лишь реализует клиентскую часть этого протокола.
Да что ты? А ничего что парсер TDS зовет нативные методы?
G>>Веб-стек, например, не опирается на сложные и старые API, поэтому там прекрасно работает асинхронность. V>Слышал звон, да не знаешь где он. На КАКОЙ именно асинхронной технологии работает Веб-стек? V>А я тебе скажу — на никакой. Сидит хендлер событий на нейтивном АПИ IIS и вызывает дотнетный диспетчер. V>Кароч, ты даже не в курсе, как работает твоя основная технология. Поздравляю, чо!
А причем тут IIS? Я про веб-стек .NETа. Он на обычных сокетах сидит, которые юзают обычные WSAфункции
V>>>Это предъявляет определённые требования к потоку, в котором это происходит. В результате, твоя асинхронщина подключается только тогда, когда ты вызываешь асинхронное же АПИ, иначе событие Completion Routines никогда не получит шанса на обработку. G>>Логично, а ты что хотел?
V>А я хотел бы, чтобы completion routines исчезло раз и навсегда. Из всех асинхронных механизмов оно самое убогое и тормозное. К тому же с кучей ограничений.
Тогда вопрос к нативной реализации SNI, которую использует парсер TDS. .NET тут не при чем.
V>Но ты же не в курсе, видимо, что completion routines может работать в цикле GUI?
С чего ты взял что я не в курсе? Снова свой мир в голове?
V>Т.е. при заходе на SleepEx или WaitForXxxEx выполняются накопленные на тот момент completion routines. Прикинь, какая засада — пока ты сам не вызовешь определенные системные ф-ии, никакого колбека от асинхронщины не происходит. Т.е. вообще ничего не происходит. Именно поэтому так тормозят дотнетные асинхронные сокеты.
Он не вызывют Wait — функций. Но даже если вызывают, приведи тесты.
V>А весь твой ASP.Net именно на них и написан.
Смотрю ILSpy код ASP.NET, нету там сокетов, снова воспаленное воображение.
G>>Если ты используегшь синхронное API, то ты и так занимаешь поток, зачем нужно занимать еще один поток на Completion или любые другие пляски исполнять, если в итоге получатель данных работает синхронно? V>Затем, чтобы пока ты выполняешь обработку поступившей порции данных, физическое устройство (вернее, его драйвер) могут заливать в твои буфера следующую порцию данных.
В чем проблема сделать это на .NET ?
V>А иначе, чтобы распараллелить обработку, на дотнете надо создать еще один поток, который будет заниматься сугубо выгребанием данных. А уже из этого потока передавать данные целевому. Правда, если бы еще дотнетчики lock-free умели хорошо... а то через дотнетную синхронизацию на мониторе убивается любая производительность.
Ну покажи как сделать быстро.
V>Кароч, для того же TCP, чтобы поддерживать окно максимальным, необходимо оперативно выгребать данные из сокета. Для сравнения, дотнет не в состоянии нагрузить современные сетевые карточки, которые с легкостью нагружает нейтив. Разница в пропускной способности в среднем до 3-х раз. Чем меньшими порциями оперируем, тем больше разница вплоть до более 20 раз.
Опять у тебя свой мир в голове. .NET может выплевывать данные в сетевой драйвер с той же скоростью, что и нативный код, собственно от нативности тут вообще ничего не зависит, время выполнения коллбека в .NET бесконечно мало по сравнению со временем выполнения send. Для того, чтобы запустить чтение данных параллельно с обработкой не нужно создавать потоки?
V>>>Более того, для тех же злополучных блобов, когда ты открывал к нему Stream и читал из него асинхронно, то там асинхронность эмулировалась на стороне дотнета, реально её не было. G>>Если у тебя не установлен CommandBehavior.SequentialAccess, то парсер TDS читает строку, а тебе отдает тупо MemoryStream. G>>Если у тебя установлен CommandBehavior.SequentialAccess, то тебе отдается SqlSequentialStream, который таки асинхронно читает поток. Глянь в ILSpy — он ожидает сигнала получения пакета и копирует байты в выходной буфер.
V>Если аснхронно — то сам ничего не читает и не ожидает. Кароч, всё ясно, курить completion routines до просветления. Ты получаешь сигнал готовности данных не асинхронно, а только когда входишь в ожидание этого сигнала, т.н. alertable thread state. Получаешь сигнал готовности иногда с бооольшим опозданием, ведь ты заходишь в slertable state очень даже синхронно, причем, ты должен получить сигнал готовности в том же самом потоке, откуда ты начал "асинхронную" операцию. Поэтому, никакого load balancing. Поэтому, задержавшись по неким объективным причинам на обработке текущей порции данных от одной из асинхронных операций, ты тормозишь вообще все асинхронные операции, привязанные к данному потоку.
Прочитал внимательно код TDS — явного вызова completion routines не увидел, все уходит через нативную библиотеку SNI, как она вызывает завершение — хз.
Так что есть подозрение что ты и тут свистишь.
V>Сравнимая по убогости технология — только WsaSelect для сокетов. Но в нейтиве мы хоть можем выбирать, как работать из кучи вариантов. А вдотнете имеем нифига не масштабируемый ввод-вывод. Отсюда плачевные результаты по производительности этого ввода/вывода.
Ну ок, покажи как надо. На слово тебе верить чтоли?
G>>Ничего что GetStream появился в .NET 4.5, а ты рассказываешь про какие-то дремучие времена? V>Ничего, ничего. Ты ж соврал про 8 лет на дотнете, походу. V>Есть такой SqlBytes.Stream.
Так он синхронный. Конечно вся асинхронность в нем эмулируется.
Ты же говорил о честном асинхронном стриме от SQL.
G>>По моему эти ошибки только в твоем воображении существуют. V>Рассуждая таким макаром, по твоему земля плоская. Ты же её и космоса не видел.
Тут какбы есть разница, много людей видело землю из космоса, да и физические эксперимены позволяют утверждать что земля круглая.
А ты рассказываешь про баги и тормоза, которых кроме тебя никто не видел. Кроме того неоднократно уже откровенно свистел про многие вещи.
V>>>И да. Упомянутый мною баг я обнаружил на 2-м дотнете, ес-но. И мне пришлось изучить код дотнетного клиентского драйвера под MS SQL фактически наизусть. А твоя распальцовка попросту смешна, бо ты в глаза не его видел и понятие не имеешь, как он работает. G>>Ну ты окончательно заврался, GetStream появился только в .NET 4.5. G>>До .NET 4.5 не было API для асинхронного чтения ридера. V>Видишь суслика? А он есть! (С)
Ну вот опять ты врешь. Не было до .NET 4.5 асинхронного чтения из ридера. Даже если тебе в руки стрим попадал, то все равно он был насквозь синхронный.
V>>>Далее. В Windows есть минимум 4 способа организации асинхронщины. Так вот, OLEDB давал "правильную" работу с TCP-соединением, даже при обычном, т.е. блокирующем чтении из него. Потому что overlapped API позволяет не только ожидать готовности данных, но может "само" заливать данные в заранее подготовленные буфера. G>>Ага, верю, чувак, верю. Жги дальше. V>Порядком утомил своим невежеством и хамством. До встречи через годик-другой.
Давай, послушаем сказки снова, ибо ты уже совсем слился.
Сюда, пожалуй, направлю свой вопрос, т.к. тема весьма интересная:
В данный момент есть только 2 бесплатные heavy ORM под .NET:
1. NHibernate — тормозное чудовище. Работать можно, но лучше не связываться.
2. EF 6. Тоже кривой проект, который вроде бы доведён до нормального уровня в последней версии, но (согласно "неуравновешанной" мягко говоря стратегии майкрософт) будет выпилен и заменён на EF 7 с которым будет не полностью совместим.
Из light ORM тоже особо не понавыбираешь:
1. Dapper — слишком примитивный и для специфических целей.
2. Linq to sql — давно не развивается, но теоретически поддерживается.
3. BLToolkit — вроде хорош, но завязан на одного/нескольких человек, которым он перестал быть особенно интересен и они переключились на linq to db. Тоже теоретически поддерживается, но общие прогнозы пессимистические, т.к. полноценно тянуть 2 фреймворка вряд ли будут.
4. Linq to db — в разработке, пока не богат функционалом, мало информации в инете, возможны баги.
К чему этот вопрос: мне сейчас надо накидать прототип, который возможно перерастёт в большой проект (а возможно и нет). Нужен ORM. Хотелось бы, конечно, плюшек в виде lazy loading и change tracking (т.к. неизвестно куда потом требования угуляют), но и без них можно обойтись.
Так же важен момент быстрого вхождения средних (не совсем бестолковых, но и не "10x") разработчиков.
Хотелось бы надёжную штуковину, которая бы 3-4 года ещё была актуальна и "в струе" дотнета.
База планируется средней нагруженности — будут блобы, файлы-документы, сотни пользователей, планировщики и т.д.
Что бы мне такое выбрать, чтобы не очень промахнуться?
Здравствуйте, A-Myth, Вы писали:
AM>4. Linq to db — в разработке, пока не богат функционалом, мало информации в инете, возможны баги.
l2db по функционалу во многом богаче blt. А большая часть отсуствующего там отсутствует специально.
AM>К чему этот вопрос: мне сейчас надо накидать прототип, который возможно перерастёт в большой проект (а возможно и нет). Нужен ORM.
linq2db
AM> Хотелось бы, конечно, плюшек в виде lazy loading и change tracking
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>linq2db
Ок. Посмотрю внимательнее.
AM>> Хотелось бы, конечно, плюшек в виде lazy loading и change tracking НС>Они тебе не нужны, поверь мне.
А вот с change tracking была история. В одном приложении с развесистым UI внезапно понадобился глобальный undo/redo.
Написано всё было на linq2sql и чтобы прикрутить нормальный ct пришлось попотеть. А вот была бы поддержка на уровне orm...
Здравствуйте, A-Myth, Вы писали:
AM>Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>linq2db
AM>Ок. Посмотрю внимательнее.
AM>>> Хотелось бы, конечно, плюшек в виде lazy loading и change tracking НС>>Они тебе не нужны, поверь мне. AM>А вот с change tracking была история. В одном приложении с развесистым UI внезапно понадобился глобальный undo/redo. AM>Написано всё было на linq2sql и чтобы прикрутить нормальный ct пришлось попотеть. А вот была бы поддержка на уровне orm...
Бери ef и не парься. Примеров в интернете можно нагулить на любую задачу.
Здравствуйте, A-Myth, Вы писали:
AM>Написано всё было на linq2sql и чтобы прикрутить нормальный ct пришлось попотеть. А вот была бы поддержка на уровне orm...
Зачем мешать два разных функционала? Это не является задачей ORM.
Здравствуйте, gandjustas, Вы писали:
G>Бери ef и не парься. Примеров в интернете можно нагулить на любую задачу.
Тоже вариант. Но сейчас, когда детальнее смотрю на задачу то вижу, что будет много разнообразной работы с базой, возможно, даже ручного анализа на первых порах (+ будет немного высоконагруженных мест), тонкой настройки.
Т.е. это точно не code first — хочется больше держать под ручным контролем и переделывать при необходимости.
В общем — пока не решил.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Зачем мешать два разных функционала? Это не является задачей ORM.
На концептуальном уровне согласен.
Но в реальности — зависит от дизайна и от других факторов. В тот момент поддержка ct хотя бы на уровне EF нам бы была выгодна просто с финансовой точки зрения.
