Быстрая и компактная сериализация объекта в.NET
Nest.js-Interceptors обрабатывает только запрос, обработанный вашим контроллером, и ответ отправляется. Если вы выполняете http-запросы с Axios во время обработки запроса контроллера, они не будут обрабатываться перехватчиком.
Axios Interceptor
HttpService выставляет свой экземпляр axios напрямую через get axiosRef(). С его помощью вы можете добавить axios interceptor :
this.httpService.axiosRef.interceptors.request.use(config => console.log(config));
Вы можете, например, сделать это в onModuleInit() вашего AppModule. [ 1119]
Делегирование на фасад
В качестве альтернативы вы можете создать фасад HttpService, который регистрирует запрос и делегирует все вызовы встроенному HttpService:
[111 ]
Вы можете создать свой собственный LoggingHttpModule, который импортирует встроенный HttpModule и экспортирует ваш MyHttpService. [+1121]
6 ответов
Можно использовать Буферы Протокола . Я изменяю весь свой код сериализации от BinaryFormatter со сжатием к Буферам Протокола и получаю очень хорошие результаты. Это более эффективно в оба времени и пространства.
существует две реализации.NET Jon Skeet и Marc Gravell .
Обновление : Чиновник реализация.NET может быть найден здесь .
Как автор, я пригласил бы Вас пробовать protobuf-сеть ; это поставлется с двоичными файлами и для Моно 2,0 и для Silverlight 2.0 и быстро и эффективно . Если Вы имеете какие-либо проблемы вообще, просто отбрасываете меня электронное письмо (см. мой Stack Водосливный профиль); поддержка является бесплатной.
версия Jon (см. ранее принятый ответ) также очень хороша, но IMO, protobuf-сетевая версия более идиоматична для C# - Jon, был бы идеален, если бы Вы говорили C# с Java, таким образом, у Вас мог быть подобный API в обоих концах.
Вы могли попытаться использовать JSON. Это не как пропускная способность, эффективная как Буферы Протокола, но было бы намного легче контролировать сообщения с инструментами как Wireshark, который помогает много при отладке проблем..NET 3.5 идет с сериализатором JSON.
Вы могли передать данные через DeflateStream или GZipStream для сжатия его до передачи. Эти классы живут в Система. Пространство имен IO.Compression .
У меня была очень похожая проблема - сохранение в файл. Но следующее можно также использовать по сети, поскольку оно было фактически разработано для удаленного взаимодействия.
Решение состоит в использовании библиотеки Саймона Хьюитта - см. Оптимизация Сериализация в .NET - часть 2 .
В части 1 статьи говорится (выделено жирным шрифтом): "... Если вы когда-либо использовали удаленное взаимодействие .NET для большого количества данных, вы обнаружите, что есть проблемы с масштабируемость. Для небольших объемов данных хорошо работает достаточно, но большие объемы требуют много ресурсов процессора и памяти, генерируют большие объемы данных для передачи , и может завершиться ошибкой с исключениями Out Of Memory. Существует также большая проблема со временем, затрачиваемым на фактическое выполнение сериализация - большие объемы данных могут сделать ее невозможной для использования в приложениях .... "
Я получил аналогичный результат для моего конкретного приложения, 40 в раз быстрее сохранение и в 20 раз быстрее загрузка (от минуты в секунды). Размер сериализованных данных был тоже сильно уменьшено. Я точно не помню но это было как минимум 2-3 раза.
Начать довольно легко. Однако есть один
gotcha: используйте сериализацию .NET только для самых высоких
структура данных уровня (чтобы получить сериализацию / десериализацию
запущен), а затем вызовите сериализацию / десериализацию
функции непосредственно для полей на самом высоком уровне
структура данных. Иначе никакого разгона не будет ...
Например, если конкретная структура данных (скажем,
Generic.List ) не поддерживается библиотекой, тогда .NET
Вместо этого будет использоваться сериализация, и это недопустимо. Вместо
сериализуйте список в клиентском коде (или аналогичном). Для примера
см. рядом с надписью «Это наша собственная кодировка». в той же функции
как указано ниже.
Для справки: код из моего приложения - см. рядом с «Примечание: это единственное место, где мы используем встроенный .NET ...».
У меня есть несколько тестов для ведущих сериализаторов .NET , доступных на основе набора данных Northwind.
@marcgravell двоичный protobuf-net - это самая быстрая протестированная реализация, которая примерно на 7x быстрее, чем самый быстрый доступный сериализатор Microsoft (XML DataContractSerializer) в BCL.
Я также поддерживаю несколько высокопроизводительных сериализаторов текста .NET с открытым исходным кодом:
- JSV TypeSerializer компактный, чистый, похожий на JSON + CSV формат, который в 3,1 раза быстрее, чем DataContractSerializer
- , поскольку а также JsonSerializer , который в 2,6 раза быстрее.