Странная реализация HttpClient в .NET Core

Представьте что у вас есть приложение. Не очень маленькое, но и не гигантское, работает помаленьку развивается, и тут вы совершенно случайно замечаете в мониторинге, что один из сервисов жрёт 25% CPU. Хм... вроде многовато, но мало ли что. Может боты набежали на сайт и смотрят все странички, или пользователи ходят. Да и 25% немного, запас огромный (400% максимум). Но на всякий случай сервис перепускается и загрузка падает до 1%. Вы думаете — какой-то глюк, но через некоторое время загрузка процессора растёт опять.

Вот с подобной ситуацией я столкнулся несколько недель назад. Есть какая-то утечка CPU (не памяти, а именно процессора), при этом ни истерики в логах ни каких-то явных знаков, указывающих на проблему. Приложение, хоть и не очень большое, но делает кучу разных вещей, отправляет письма, общается через собственную API-платформу, активно кеширует данные, связывается с другими частями и внешними сервисами, генерирует документы, в общем точек для анализа очень много. А утечка небольшая, несколько процентов в день, да и эти несколько процентов в моменте могут быть настоящей нагрузкой от живых пользователей. Т.е. даже не ясно как поступать с профилированием. Да и на деве это не повторяется.

Когда я в очередной раз сдался, я не выдержал, и подцепился дебаггером к боевому серверу напрямую. И... ничего не понял, всё выглядит нормально. Отцепился — загрузка 0%. Тут у меня уже задёргался глаз. Через некоторое время повторил — да, подключение дебаггера явно лечит проблему, как и перезапуск приложения. Но это ведь не выход и не решение. А вдруг это какая-то проблема у нас, и если в этом приложении данную проблему можно замаскировать, то она может выстрелить где-то ещё. Так что пришлось разбираться дальше.

Неожиданно удалось нагуглить данный тред на GitHub'е. Проблема у Microsoft'овской библиотеки и связана она с HttpClient. Утверждалось, что нельзя его создавать на каждый HTTP запрос, а надо использовать статичный. Правда в документации есть пример использования:

В котором его заворачивают в using. Я попробовал покопать в данном направлении и выяснил первую забавную вещь: использование статичного HttpClient в .NET Core быстрее раз в 5, чем создавать его на каждый запрос. Но тут нюансы с самим временем запроса, но смысл в том, что уже есть причина использовать статичную версию. При этом под "большой" .NET разницы нет никакой.

В общем, выложил новую версию приложения, но проблема осталась. (может я не туда копаю?). Попробовал переключиться с .NET Core 2.1 на 2.0 — проблема ушла. Т.е. проблема есть только под core, под Linux и версия должна быть больше чем 2.0 (более свежие не проверял). Читаем документацию и видим, как разработчики Microsoft, светясь от гордости, рекламируют новую реализацию Http Client Factory, через которую и идут все запросы (не может Microsoft просто написать библиотеку, делающие HTTP запросы, внутри обязана быть магия!). В общем теперь всё managed, в 10 раз лучше и в 50 раз быстрее. Ага, и сделано как раз в 2.1

Прикидываю, где ещё скрылись HttpClient'ы и нахожу библиотечку для отправки Push-уведомлений, которая внутри себя создаёт данный класс. Собственно, поэтому в первый раз и не было найдено это использование. Переделываю использование данной библиотеки и проблема исчезает! Всё работает замечательно.

Тут я начинаю громко материться, но нахожу в документации небольшую приписку:

Т.е. они знают о данной проблеме! Но явно про это написать было стыдно, так что засунули всё в сноску, зато не будет никаких претензий от разработчиков. Сноска есть? Есть! Значит читайте внимательнее.

Получается совершенно странная ситуация: Disposable-класс, который надо использовать синглтоном. При том, что все предыдущие реинкарнации подобных классов были честными Disposable-объектами. Но тут решили сделать по-другому. Зачем? Я пока не понял. Но свинью подложили знатную. Представьте, у вас есть базовая библиотека, написанная под большой .NET, вы её мигрируете на Core, пользуетесь под Windows, всё нормально, а потом, спустя длительное время замечаете, что приложение жрёт много процессора. Вам нужно будет пройти квест, подобный моему, чтобы найти проблему, переписать библиотеку и весь остальной код, обновить всё что нужно и всё из-за странного архитектурного решения разработчиков из Microsoft.

Деградация Windows Server

Есть у меня простенький компьютер. Был куплен в порыве шопоголизма на распродаже. Я так и не придумал, чем занять данный компьютер, поэтому накатил на него Windows Server 2016 (По факту LTSB сборка 10-ой винды 1607, которая Anniversary Update, но с серверными фичами). Компьютер после запуска (и ожидания 8 минут, пока винда разберётся со своими внутренними делами) выглядел так:

Если не вдаваться в подробности, то запущено 54 процесса, 848 потоков и занято 0.9Гб оперативки. Вполне допустимая ситуация для пустого сервера, хотя всегда хочется меньше.

Но я решил потестировать недавно вышедший Windows Server 2019, эта та же Windows 10, только уже злополучная 1809, October 2018 Update. Я просто обновил сервер, подождал джентльменские 8 минут и результат на экране:

Процессов уже стало 110 (ровно в два раза больше!), количество потоков увеличилось всего на 300 штук, что уже лучше, хендлов стало больше почти в 2 раза и сожрано стало на 400МБ оперативной памяти больше.

Ещё раз, для понимания бреда. За 2 года разработки операционная система на свои личные нужды стала использовать гораздо больше ресурсов. Может от этого она стала быстрее или лучше работать? Как-то незаметно. Вместо оптимизации системы в итоге получаешь просто ещё больше внутреннего потребления. Зачем? А просто так, потому что программисты Microsoft могут тратить ресурсы как захотят. Железо же становится быстрее, памяти больше, никто и не заметит. И вот это бесит неимоверно.

UPD: Оказывается, это сознательное решение Microsoft, они в 1703 разгруппировали сервисы, если в системе больше чем 3.5ГБ памяти. Объяснили как всегда надёжностью и безопасностью. Но памяти это, конечно же, жрёт больше, о чём не скрывают. А то, что "стабильность" теперь зависит от количества оперативной памяти — выглядит это очень странно.

UPD2: Поиск решения проблемы привёл на следующую ссылку, надо в реестре по пути:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control отредактировать (создать?) ключ SvcHostSplitThresholdInKB, изменив там количество памяти для разделения процессов. Итог изменения ключа следующий:

Процессов и памяти резко уменьшилось. До старых значений ещё не доходит, но всё-таки результат стал получше. 

Yappi Days 2018. Впечатления

Изначально не планировал идти на эту конференцию, но привлекли пара докладов и свободная суббота, так что решил сходить.

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

Изначально у конфы не заявлена специализация, просто конференция для разработчиков (видно, чтобы собрать всех желающих программистов Ярославля, кстати, их удивительно много, и занимаются интересными вещами, удивился). В результате, темы были весьма разными (чтобы всем хватило), а сложность докладов очень низкая, местами очень капитанская.

При этом, доклады от спонсоров очень хорошо выделялись своей очевидностью и рекламой. Например, доклад про PVS-Studio был всего-лишь рекламой PVS-Studio (продукт, кстати, хорош, и на стенде очень плодотворно пообщались с разработчиками), доклад от Тензора поразил своим абсолютным, нереальным отсутствием практического смысла (рекламировалась внутренняя утилита компании Тензор, т.е. её не увидеть, не пощупать, и использовать можно только если ты работаешь в Тензоре).

Также, у организаторов вышла лажа с порядком докладов: вначале Владимир Ильмов рассказывал про Netflix стек для микросервисов и докер у него был как базовая концепция, а затем был доклад про то, что такое докер в принципе. Совсем не понял, в чём был смысл доклада от CUSTIS, назывался он "Как работает браузер", в реальности человек начал рассказывать про то, что такое DNS, как в http передаются заголовки. Т.е. такой вымученный доклад, лишь бы что-то рассказать (да, я даже в лекции для студентов старался держать уровень выше). При этом CUSTIS никак себя не рекламировал (не было стендов), и смысл им рассказать один бестолковый доклад — я так и не понял.

Конечно, т.к. было 3 потока, я не мог посетить все доклады, возможно, я пропустил что-то интересное, но общее впечатление весьма посредственное. Причём именно из-за докладов — слишком обще, слишком просто, слишком про всё. Надо специализироваться и повышать уровень. И ещё раз скажу, с организацией всё было отлично, а халявные пиццы от Пиццы-Фабрики очень рулили.

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

WireGuard

Сегодня Роскомнадзор в очередной раз забанил подсеть Амазона (или хостер пофиксил "проблему"), в общем пришлось заворачивать всё в VPN, что привело к весьма печальной скорости работы сервера, т.к. VPN был далеко.

Решил поднять его поближе, в Azure, а т.к. в нём весьма грустно с фаирволлом, решил попробовать новый хипстерский VPN под названием WireGuard. Правда потом оказалось, что VPN всё-таки можно было попробовать устроить, но у меня оказалась неправильная виртуалка, в которой всё делается через жопу. Надо было создавать другую и гуглить как в азуровом фаирволле сделать проброс чего-то отличного от TCP и UDP.

В общем, WireGuard позиционируется как простой и правильный VPN, без кучи опций и настроек. Просто работает. И в целом да, только оказалось, что это нифига не VPN в привычном понимании (хотя технически да, и виртуальная, и частная, и сеть).

Что хочется получить от VPN:

• Стабильной работы (у всех существующих решений всё плохо)
• Простой конфигурации (PPTP рулит)
• Безопасности (SSTP, L2TP/IPSec, OpenVPN)
• Выдачи IP адресов (все умеют)
• Выдачи маршрутов (у всех очень грустно)
• Выдачи доп. настроек (ещё хуже)

При этом, стоит напомнить про такую технологию как IPSec, которая не является туннелем сама по себе, т.е. не приносит дополнительных интерфейсов и IP-адресов, а просто безопасно заворачивает IP пакеты в себя. Т.е. идеально подходит для связи Server-Server или Сеть-Сеть через конкретные шлюзы. Для динамики и NAT подходит весьма плохо.

И вот тут вылезает WireGuard. Что же он делает?

• Создаёт отдельный сетевой интерфейс
• На него руками необходимо назначить IP (wat?)
• Клиент и сервер в целом не разделяются (привет IPSec), они равнозначные пиры (peers), но в целом можно использовать концепцию клиент-сервер, просто сделав определённые настройки
• Если нужно устроить VPN, то можно сделать это ручками через iptables и маскарад
• Каждый пир определяется парой ключей (публичным и приватным), так что заранее на сервере никого не добавить (можно нагенерить ключей, но как-то коряво выглядит)
• По умолчанию роуты связаны со списком разрешённых IP'шников, т.е. делаются на клиенте, проброса нет

Так что получается, что это какой-то упрощённый IPSec, но с отдельным интерфейсом и IP-адресом (без добавления, думаю можно извернуться, но уже не очень дефолтная конфигурация). Т.е. использовать его как VPN — можно, но очень фигово (хотя если для себя делаете, то вполне норм). И с VPN'ами по-прежнему всё тухло, а WireGuard оказался каким-то странным созданием.

Но с другой стороны, настраивается он элементарно и начинает сразу же работать. Это ему плюс. Только имейте в виду, что конфигурация через wg-quick и ip работает по-разному, через ip можно сделать гораздо больше и и точнее.

Хранение данных в памяти

Очень давно вынашиваю идею о том, что базу данных для приложения стоит размещать в памяти. Конечно, не полностью в памяти, основную базу оставить, но использовать очень и очень агрессивное кеширование. Зачем? Об этом ниже.

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

Почему не стоит полагаться на кеш SQL-сервера?

Потому что он построен именно на модели кеша для данных, и в него можно попадать или не попадать. Конечно, в MS SQL есть OLTP таблицы, которые хранятся в памяти, но они больше для очень активных данных, и вообще это на уровне SQL, причём MS SQL. А без них — используются стандартные алгоритмы для поиска, оптимизированные для данных, находящихся на диске, как результат, необходимый кеш для очень 100% попадания в память многократно превышает размер реальных данных.

Я же предлагаю забить на это, и максимально хранить все данные из базы в памяти (загружать их из базы на старте, или ленивым образом).

Что это даёт?

• Резко упрощается внешняя логика пользователя. Во многих случаях можно отказаться от джойнов, если нет дополнительной фильтрации. Например, классический джойн с данных с пользователем (например, вывести автора данных) можно заменить на выборку данных и доставание всех пользователей по ID. Это очёнь дешёво
• Можно использовать очень тупые алгоритмы, и это всё равно будет очень быстро. Фуллскан 10000 записей почти незаметная вещь, а если надо будет ещё быстрее — всегда можно будет прикрутить "индекс" в виде словарика
• Можно избавиться от отдельного кеша для тяжёлых данных, ибо и так всё в памяти
• Тупо быстрее из-за отсутствия запросов к внешнему SQL-серверу
• Легко хранить данные, которые тяжело забирать из SQL (объект с зависимыми детишками, слабо-структурированные документы, JSON/XML поля)
• При этом, если приложение написано с использованием LINQ, то местами можно вообще не заметить разницы между базой и памятью (если грамотно спланировать архитектуру приложения)

 А в память влезет?

А вот это как раз главный вопрос, который всех останавливает и которого все боятся. И из-за этого, всё так и останавливается на уровне идей. Но давайте прикинем необходимое количество памяти.

• База данных в 20ГБ содержит где-то 20ГБ данных (логично, да?), в памяти это будет занимать примерно столько же. Найти подходящий сервер — не так уж и сложно. Естественно, базы в 100МБ вообще влезут в память без проблем
• Очень часто в "больших" базах большой объём занимают всякие полумёртвые данные — журналы, результаты импорта, файлы, подписанные данные, акксесс логи... Эти данные нужны очень редко, их можно не хранить в памяти, тем самым кардинально снизив объём "реальных" данных
• Многие данные нужны только в небольшом количестве. Например, у вас есть 10000 пользователей в системе, но активны только 1000, тут можно использовать какой-нить LRU кеш и не держать в памяти все объекты, а только активные. Опять же, очень сокращает необходимый объём памяти
• Ну и для реально огромных баз данных можно уж держать в памяти только специально выделенные объекты (например, справочники). Хотя, с такими объёмами у вас будет проблем побольше чем просто держать в памяти

Как реализовать?

Поскольку я ещё не делал это в полном виде, то могу только предположить следующие варианты:

• Собственный кеш класса, ратающего с сущностью (e.g. UserManager), он сам решает, что и как кешировать. Проблемы в куче аналогичного кода в разных классах и сложность с инвалидацией. Плюсы: в каждом конкретном случае можно использовать самые эффективные варианты
• Мемоизация и автомемоизация методов. Плюсы: очень упрощается код, минусы: сложно инвалидировать и оптимально использовать данные. 
• Обёртка над ORM (или использование встроенных средств типа Second Level Cache), которая сделает всё сама. Проблемы: сложно в реализации и конфигурировании. Плюсы: полная прозрачность в использовании со стороны кода

Краткий итог

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

Итоги моего 2017 года

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

Получилось так, что я почти забросил этот блог. ибо хочется писать про интересное, а это интересное надо долго и упорно изучать, чтобы пост не получился глупым и ошибочным. А в итоге получается, что занимаюсь или банальщиной, или не сильно углубляюсь, или лезу в такие дебри, что объяснить их не представляется возможным. А вот так, чтобы что-то интересное... На новый год принято давать себе обещания, типа бросить пить, заняться спортом, вести блог... Так вот не буду, ибо не знаю ещё, чем буду заниматься в следующем году...

А в этом активно и вплотную занялся .NET Core под Linux, фактически все новые проекты теперь там и живут, и живут весьма неплохо. На работе кроме всякой мелочи был сделан очень крутой проект. Он. конечно выглядит просто и банально, но внутри там очень всё круто, микросервисно, распредёлённо и кешированно. При этом, пока не замучали новыми фичами, он умудрялся жить на мелких виртуалках, используя по максимуму всё, что они предоставляли. Но в конце-концов, один проект превратился в два, с общей и своей частью, я сдался и развёл проект на 3 сервера и разрешил жрать память (хотя слишком разрешил 16 Гигов, съеденных из-за баги доставили много радости в поиске бага).

В остальном, год был похож на прошлый. Был хакатон, но участвовал я один, в итоге "почётное" третьё место. И ещё не внедрено. Продолжаю пилить на гитхабе свой клонятор, Crc32 (теперь ещё быстрее), и архиватор, который уже помаленьку использую в бою и вижу, что у него есть очень интересные фичи. Также нарисовал свой аналог IPSec под названием AutoTunnel, получилось интересно, но надо бы чуть допилить, ибо склейка фрагментированных UDP пакетов со стороны Windows — это боль.

С нетехнической стороны — год отметился путешествиями: Баку, Минск, Кострома, Мюнхен, Тбилиси, Амстердам, Прага... Посетил кучу мест, получил много впечатлений и не собираюсь останавливаться на достигнутом!

К сожалению, со всей этой беготнёй, забыл про новогоднее настроение, но у меня есть ещё 2 дня его найти, буду упорно стараться. Ну а вам его тоже желаю, надеюсь, что оно у вас уже есть и вы готовитесь к самому весёлому празднику, Новому Году.

С Наступающим!

Ненавистный .NET

Последнее время совсем не пишу в блог, как-то нет подходящих тем, могу только сообщить, что такой ненависти к Microsoft я давно не испытывал. Попытка поработать с .NET Core 2.0 сразу же привела к идиотским ошибкам, типа 2 entry point у приложения. При этом второй генерируется самостоятельно (!), другими словами, у Microsoft новые отличнейшие идеи, как всё должно работать по их мнению, вместо того, чтобы просто сделать рабочий продукт.

Если кончится мат и появятся слова, постараюсь написать что-то более членораздельное. Но, блин, у Microsoft был отличнейший .NET, приложения на котором просто работали... Теперь не так, они могут падать по совершенно различным причинам, а Dll Hell уже перешёл все границы. Ну, как, как можно так портить жизнь разработчикам за их же деньги...