Сообщения

Сообщения за апрель, 2017

Компрессия данных в ASP.NET Core

Протокол HTTP предусматривает использование сжатия данных. В спецификации указаны, такие способы, как deflate , compress , gzip . Если клиент способен принимать данные в сжатом виде, то он отправляет заголовок Accept-Encoding: gzip, deflate Если на сервере реализован механизм сжатия данных, то сервер сжимает содержимое ответа и указать это в заголовке Content-Encoding: gzip Настройки на уровне IIS Configuring HTTP Compression in IIS 7 <system.webServer> <httpCompression directory= "%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files" > <scheme name= "gzip" dll= "%Windir%\system32\inetsrv\gzip.dll" /> <dynamicTypes> <add mimeType= "text/*" enabled= "true" /> <add mimeType= "message/*" enabled= "true" /> <add mimeType= "application/javascript" enabled= "true" /> <add mimeType= "*/*&q

Кеширование с ETag в ASP.NET Core

ETag или entity tag - один из механизмов кэширования в HTTP. Фактически сервер присваивает идентификатор состоянию ресурса. Если состояние изменилось идентификатор должен быть обновлен. Это может быть как статика (CSS, картинки, возможно какие то актуальные документы и пр) так и динамически формирующиеся данные. В общем виде для создания ETag можно использовать хэш-функцию по содержимому ресурса, желательно устойчивую к коллизиям. Сильные и слабые проверки Слабая проверка отличается наличием начального W/ в ETag и проверяет, что два ресурса семантически эквивалентны и фактически являются взаимозаменяемыми, хотя могут быть не идентичны байт за байтом. Сильная проверка ETag проверяет, что содержание в обоих ресурсах байт за байтом идентично, и что все другие поля (такие как Content-Language), также не отличаются.  Сильные ETags допускают кэширование и сборку частичных ответов, как при запросах диапазона байт. Вариант использование Веб-сервер в заголовки HTTP возвращает

SARG предикаты в MS SQL Server

Довольно часто у начинающих разработчиков возникает вопрос почему оптимизатор запросов не использует поиск по нужному им индексу. Работа оптимизатора тема очень не простая и под капотом у него куча нюансов. Но есть два момента на которые стоит обратить внимания в первую очередь, это селективность и какие предикаты поиска используются. Про селективность, а конкретней про статистику в следующий раз, а сейчас немного про SARG предикаты. SARG (Seekable/Searchble Arguments) предикаты позволяют сделать поиск по индексу. Любые манипуляции над столбцами которые участвуют в поиске не позволяют использовать алгоритмы поиска по индексу. Например нужно найти данные у которых значения в столбце меньше на единицу чем аргумент: where col - 1 =@ var При таком поиске придется рассчитывать значение  col - 1  для каждой строчки и поиск по индексу использован не будет. Запрос нужно переписать так, что бы значения для предиката высчитывалось один раз и дальше использовалось для поиска. where

WebRequest в MS SQL Server

Для того что бы отправлять/загружать данные по сети из MS SQL Server, можно написать две небольшие CLR функцию. Для HTTP методов POST и GET. Собираем сборку и копируем к примеру в C:\clr\SqlWebRequest.dll Дальше настраиваем MSQL Server и подключаем функции. Включаем интеграцию со средой CLR sp_configure 'clr enabled' , 1 ; RECONFIGURE; Если в сборки есть код который работает вне контекста MS Sql Server, то необходимо явно указать что БД "надежна" ALTER DATABASE myDB SET TRUSTWORTHY ON ; Так же возможно понадобится изменить владельца EXEC sp_changedbowner 'sa' Регистрируем сборку в БД CREATE ASSEMBLY SqlWebRequest FROM 'C:\clr\SqlWebRequest.dll' WITH PERMISSION_SET = UNSAFE; И создаем sql функции CREATE FUNCTION dbo.WebrequestGET( @ uri nvarchar( max ), @ user nvarchar( 255 ) = NULL , @ passwd nvarchar( 255 ) = NULL ) RETURNS nvarchar( max ) AS EXTERNAL NAME SqlWebRequest.F