SQL Server - как "залить" изображения?

[BFG-9000]

Это было связано с обработкой событий от сокетов (они делались через очередь сообщений - потому заточенность на потоке). Ну MFC и не был предназначен для серверных компонент.
Сам хендл сокета, в тоже время - можно было использовать где угодно, это чисто Win32.

Вот именно. Ситуация один в один с описанной тобой с АДО-шными объектами коннекта.

Это делается, в контекст потока можно положить что угодно. Я только не понят причем тут межпоточный обмен? Ты предлагаешь чтоб на сервере рабочие потоки между собой взиамодействовали? Ну-ну.

Блин, чего ж ты так боишься отойти от штампов. Я привел простой пример - у тебя есть слабый сервер БД. Ну слабый он, достался от предыдущих итераций создания системы, трогать низзя или экономически невыгодно или там продакшн с непрерывным циклом или он вообще принадлежит третьей стороне которая перед тобой ответственности за качество и скорость его работы не несет. Такое сплошь и рядом по принципу "эта штука работает? ничего не трогай!". Задача минимизировать на него нагрузку. Я предложил пожертвовать вычилительной мощностью сервера приложений, сделав излишне затратное с вычислительной точки решение и вынести работу с БД вообще в пул отдельных потоков где я могу облизывать и целовать в северный мост сервер БД как захочу. Что предложишь ты?

 

[dr. Unk]

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

 

[sergeime]

Блин, чего ж ты так боишься отойти от штампов. Я привел простой пример - у тебя есть слабый сервер БД. Ну слабый он, достался от предыдущих итераций создания системы, трогать низзя или экономически невыгодно или там продакшн с непрерывным циклом или он вообще принадлежит третьей стороне которая перед тобой ответственности за качество и скорость его работы не несет. Такое сплошь и рядом по принципу "эта штука работает? ничего не трогай!". Задача минимизировать на него нагрузку. Я предложил пожертвовать вычилительной мощностью сервера приложений, сделав излишне затратное с вычислительной точки решение и вынести работу с БД вообще в пул отдельных потоков где я могу облизывать и целовать в северный мост сервер БД как захочу. Что предложишь ты?

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

 

[kost]

И никогда не будет работать, пока ты на свой код не посмотришь с открытыми глазами, что ли... ну или дернул бы свой handler прям из браузера, handler.ashx?id=111. Ведь даже ж не попробовал, так ведь?

код не мой - стянуто с инета. Handler из браузера попробую дернуть, так как чайник, то даже не знал о такой возможности. А что с кодом не так? Не проще ли сразу показать на ошибку, а не разводить долгие переписки? Время очень дорого.

 

[sergeime]

код не мой - стянуто с инета. Handler из браузера попробую дернуть, так как чайник, то даже не знал о такой возможности. А что с кодом не так? Не проще ли сразу показать на ошибку, а не разводить долгие переписки? Время очень дорого.

Да пожалста, только ж с подсказками никогда ничему не научишься.

1. В селекте у тебя только Image_Content, а ты потом еще просишь Image_Type.

2. Что это еще за именование параметров запроса -*ImageId. MSSQL хавает *ImageId - насчет другого ничего не знаю.

3. Вместо
cmd.Parameters.Add("*ImageId", SqlDbType.Int).Value = context.Request.QueryString["id"];

пиши сразу (.NET 2.0)

cmd.Parameters.AddWithValue("*ImageId", context.Request["id"]);

4.
<asp:Image ID="Image1" runat="server" ImageUrl='<%# "Handler.ashx?id=" + Eval("Img_Id") %>' />

меняй на

<asp:Image ID="Image1" runat="server" ImageUrl='<%# Eval("Img_Id", "Handler.ashx?id={0}") %>' />

 

[romziki]

Хандлер это очень грубо говоря такая же страница ASPX, только видоизменная, без ненужной инфы. Вот пример как выодится из файла в браузер.

FileStream instream = File.OpenRead(context.Server.MapPath("Images").ToString() + "/Confidential.gif");
BinaryReader br = new BinaryReader(instream);
context.Response.ContentType = "image/gif";
context.Response.BinaryWrite(br.ReadBytes((int)instream.Length));

cmd.Parameters.AddWithValue("*ImageId", context.Request["id"]);

гы так тоже хавает? обычно юзаю

...commandText="....*ImageId";
cmd.Parameters.AddWithValue("ImageId", iImageID);

Т.е. с символом собачки
PS. context.Request["id"] - тоже плохо юзать. нужно сначала распарсить в инт
If(Int32.TryParse(context.Request["id"], out iImageID)){// do your code }

все это имхо.

 

[BFG-9000]

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

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

 

[sergeime]

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

Я что-то не пойму, у тебя коннекты в пуле или потоки. Это как бы разные вещи в моем понимании. Надо уменьшить нагрузку на базу - делай нормальное кеширование, без кеша у тебя число запросов нифига не уменьшится.

 

[BFG-9000]

Я что-то не пойму, у тебя коннекты в пуле или потоки. Это как бы разные вещи в моем понимании. Надо уменьшить нагрузку на базу - делай нормальное кеширование, без кеша у тебя число запросов нифига не уменьшится.

В пуле изначально были подготовленные коннекты. Ты сказал, что в долбанутой революции от МС есть проблемы с передачей подготовленных объектов коннекта в рабочие потоки ИИСа. Я доработал решение и обернул объекты коннекта в отдельные потоки.
Интересно посмотреть на кеширование запросов к например госреестру физических лиц хотя бы города-милионника Интересно будет при нагрузке скажем 100К запросов в сутки и ТТЛ кеша например 5 дней задуматься над смыслом существования сервера БД вообще, если в кеше лежит сразу половина базы - еще чуток и сервер БД тихонько переедет в кеш
Вопрос стоял не в уменьшении кл-ва запросов, а в снижении нагрузки на сервер путем реюзинга подготовленных запросов. Т.е. когда сервер БД уже озадачен структурой запроса, осталось в нее только параметры подставить.

 

[sergeime]

В пуле изначально были подготовленные коннекты. Ты сказал, что в долбанутой революции от МС есть проблемы с передачей подготовленных объектов коннекта в рабочие потоки ИИСа.

Проблем нет, надо лишь четко понимать разницу между multi-threaded apartments, single-threaded, понимать как могут взаимодействать объекты из разных потоков и что такое маршаллинг. Я говорил о проблемных двуногих особях которые не знаю что такое пул и пытаются хранить коннекты в сессии.

Я доработал решение и обернул объекты коннекта в отдельные потоки.

Смысл этого мне непонятен по-прежнему. Видитмо чтобы иметь геморрой с синхронизацией? Любая синхронизация - это потенциальное узкое место.

Интересно посмотреть на кеширование запросов к например госреестру физических лиц хотя бы города-милионника Интересно будет при нагрузке скажем 100К запросов в сутки и ТТЛ кеша например 5 дней задуматься над смыслом существования сервера БД вообще, если в кеше лежит сразу половина базы - еще чуток и сервер БД тихонько переедет в кеш
Вопрос стоял не в уменьшении кл-ва запросов, а в снижении нагрузки на сервер путем реюзинга подготовленных запросов. Т.е. когда сервер БД уже озадачен структурой запроса, осталось в нее только параметры подставить.

В нормальных базах существует понятие плана запроса, компилированые stored proc, статистистические индексы и т.д. Которое прекрасно реюзается сервером без всяких махинаций на клиенте.
Кэш надо строить с умом, а не так как ты обрисовал. Подумать сначала надо что и как кэшить.

 

[BFG-9000]

Смысл этого мне непонятен по-прежнему. Видитмо чтобы иметь геморрой с синхронизацией? Любая синхронизация - это потенциальное узкое место.

Забыл дописать "... в кривых руках". Не вижу никаких проблем с синхронизацией, для которой винда предоставляет 4 независимых механизма. Для чего - я тебе объяснил. Для избежания например маршаллинга, для того, чтобы не интересоваться сингл или мультитред и т.д.

В нормальных базах существует понятие плана запроса, компилированые stored proc, статистистические индексы и т.д. Которое прекрасно реюзается сервером без всяких махинаций на клиенте.

Напоминаю:

Я вобще-то высказывался иначально за мускуль, если ты уже забыл.

Кэш надо строить с умом, а не так как ты обрисовал. Подумать сначала надо что и как кэшить.

Это так по умному теперь звучит фраза "все *****асы, а я дартаньян"?
Расскажи, как надо строить кеш, если параметрами запроса являются ИНН, а результатами ФИО, адрес ну еще пара-тройка полей с инфой о человеке типа даты рождения. Объем базы 1 лям записей. Нагрузка 100К запросов в сутки. Вот такой простой случай. Очевидно существует особое дао построения кешей, которое позволяет уменьшить их объем в 9 раз?

 

[sergeime]

Забыл дописать "... в кривых руках". Не вижу никаких проблем с синхронизацией, для которой винда предоставляет 4 независимых механизма. Для чего - я тебе объяснил. Для избежания например маршаллинга, для того, чтобы не интересоваться сингл или мультитред и т.д.

Это если отказываться от COM. А если не отказываться - то про маршаллинг помнить надо. И очень хорошо помнить.
Хм, да, а потом окажется что хендл подготовленной команды мускуля нифига в другом потоке работать не будет, потому что кто-то очень умный TLS использует.
А как будет работать команда если с ее коннектом в другом потоке тоже кто-то что-то делать пытается?

А какие-такие 4 независимых механизма синхронизации в винде, можно поинтересоваться?

Это так по умному теперь звучит фраза "все *****асы, а я дартаньян"?
Расскажи, как надо строить кеш, если параметрами запроса являются ИНН, а результатами ФИО, адрес ну еще пара-тройка полей с инфой о человеке типа даты рождения. Объем базы 1 лям записей. Нагрузка 100К запросов в сутки. Вот такой простой случай. Очевидно существует особое дао построения кешей, которое позволяет уменьшить их объем в 9 раз?

Ну не тупи... никто не делает кэш на такие простые запросы на одну запись.