Сообщения

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

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

Протокол HTTP предусматривает использование сжатия данных. В спецификации указаны, такие способы, как deflate, compress, gzip.
Если клиент способен принимать данные в сжатом виде, то он отправляет заголовок
Accept-Encoding: gzip, deflate
Если на сервере реализован механизм сжатия данных, то сервер сжимает содержимое ответа и указать это в заголовке
Content-Encoding: gzip

Настройки на уровне IIS
Configuring HTTP Compression in IIS 7

<system.webServer><httpCompressiondirectory="%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files"><schemename="gzip"dll="%Windir%\system32\inetsrv\gzip.dll"/><dynamicTypes><addmimeType="text/*"enabled="true"/><addmimeType="message/*"enabled="true"/><addmimeType="application/javascript"enabled="true"/><addmimeType="*/*"enabled="false"/></dynamicTypes><staticTypes><addmimeType="tex…

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

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

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

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

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

Например нужно найти данные у которых значения в столбце меньше на единицу чем аргумент:
where col-1=@var При таком поиске придется рассчитывать значение  col-1 для каждой строчки и поиск по индексу использован не будет.
Запрос нужно переписать так, что бы значения для предиката высчитывалось один раз и дальше использовалось для поиска.
where col=@var+1
Можно исп…

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, то необходимо явно указать что БД "надежна"
ALTERDATABASE myDB SET TRUSTWORTHY ON;
Так же возможно понадобится изменить владельца
EXEC sp_changedbowner 'sa'
Регистрируем сборку в БД
CREATE ASSEMBLY SqlWebRequest FROM'C:\clr\SqlWebRequest.dll'WITH PERMISSION_SET=UNSAFE;
И создаем sql функции
CREATEFUNCTION dbo.WebrequestGET( @uri nvarchar(max), @user nvarchar(255)=NULL, @passwd nvarchar(255)=NULL ) RETURNS nvarchar(max) ASEXTERNAL NAME SqlWebRequest.Functions.GET; GOCREATEFUNCTION dbo.WebrequestPOST( @uri nvar…