はてなブックマーク

クラウドでアプリケーションを動かす上で HTTP リクエストの回復力を高める事は極めて重要です。それは何故か？ クラウドでアプリケーションを動かすという事は、ホスティング環境は動的であり、ネットワークの問題やサーバー側の問題など様々な問題によって HTTP リクエストが失敗する可能性があるという事です。 こうした失敗は一時的なものが多く、リトライなどを上手く挟み回復力を高める事によって、サービス全体として正常に動作させる事ができます。 また回復力が乏しいアプリケーションの場合、とあるリクエストの失敗が原因で、サービス全体として障害が起きてしまう可能性があります。 これを Cascading failure といったりしますが、このような障害を避けるためにも回復力は重要です。Cascading failure については下の gif を見るとイメージが付きやすいかと思います。 ちなみにこの「

この記事は Qiita C# Advent Calendar 2023 23 日目の記事です。 登壇版 OpenTelemetry について プロジェクトの主要なコンポーネント API 及び SDK という言葉について 仕様のステータス 各言語のサポート状況 OpenTelemetry Collector OpenTelemetry Collector を使わない場合。 OpenTelemetry Collector を使う場合。 Collector の実態とステータス お手軽な動かし方 OpenTelemetry の NuGet パッケージ ほぼ必須なパッケージ 便利なパッケージ C#/ASP.NET Core での使い方 Example SignalR + OpenTelemetry おまけ まとめ 登壇版 .NET ラボ 2023/12/16 で登壇した際の資料です。 スライドはこち

現代の .NET では "zero-byte reads" という最適化が随所で行われています。 この記事ではその "zero-byte reads" とはなんなのか、という事についてつらつら書いていこうと思います。 そしてそれに深く絡むピン留めのお話も。 どんな最適化か。 ピン留め手段と GC 負荷。 まとめ。 豆知識。 References どんな最適化か。 端的にいうと、Socket や Stream がネイティブとデータのやりとりする際に、managed heap に確保されているメモリを長時間にわたりピン留めしないようにするための最適化です。 どういう事か。 たとえば C# の Socket.ReceiveAsync は Windows 上では Win32 API の WSARecv をラップしたような形になっています。 C# の Socket.ReceiveAsync には M

登壇版 ConsoleFormatter HttpLogging ConsoleFormatterOptions.IncludeScopes W3C Trace Context ExceptionHandler DbDataSource HttpClientFactory まとめ References 登壇版 .NET ラボ 2023/07/22 で発表した資料です。 スライドはこちら。 スライドはアニメーション豊かなので、スライドと本投稿合わせながら見るといいかもです。 登壇のアーカイブはこちら。 30 分程度です。 ConsoleFormatter ログはだいた標準出力、まぁコンソールに出力しますよね。 そしてコンソールにログを出力するといっても、当然ながら複数のフォーマットがあります。 C# で現在ロガーとしてデファクト的に使われている Microsoft.Extensions.Lo

最初に結論。 Example のコード そもそもログの目的とは何なのか。 W3C Trace Context Trace Context の HTTP ヘッダとフォーマット Traceparent Header version version-format trace-id parent-id trace-flags 用語 Distributed trace 要するに。 System.Diagnostics.Activity ConsoleFormatterOptions.IncludeScopes HttpClient 内での Activity のイベントを検知してログに出す。 まとめ References 最初に結論。 この記事自体はアレコレ書いていますが、結論に至るまでが長いので、先に結論というか言いたい事から入ります。 とりあえず覚えておいて欲しいのはたった1つです。 それは「Co

はじめに 登壇版 Taskの本質 C# のイテレータ async/await Compiler Transform ExecutionContext builder.Start() の重要性 IAsyncStateMachine.MoveNext おわりに はじめに C#er は呼吸するように使っている async/await。 そんな async/await について、先日 Stephen Toub 氏 (.NET の中の人。中心人物の一人。) が How Async/Await Really Works in C# という非常に面白い記事を投稿していました。 この記事では Stephen 氏の記事をベースに、C# において async/await は実際どうやって動いてるの？というお話をしていきます。 以前に C#での非同期メソッドの分析。 という翻訳記事を書いたのですが、元になった記

以前 .NET ラボで 「C# と HTTP/2 と gRPC」というタイトルで登壇しました。その時のスライドがこちらなのですが、ちらほら反応を頂きました。その結果、HTTP/2 や gRPC について勘違いしている人がちょこちょこいる事が分かったので、少し補足を書こうと思います。 blog.neno.dev 1. HTTP/2 で向上するのはスループットであって、1リクエストあたりの応答時間ではないよ。 HTTP/2 を使うからといって、1 リクエストあたりの応答時間が短くなるわけではないのです。 まず、1 HTTP リクエストあたりにかかる時間を、RTT とかいったりします。 1 RTT の内訳はだいたいこんな感じになります。 1 RTT = ネットワーク上で往路にかかる時間 + サーバの処理時間 + ネットワーク上で復路にかかる時間 HTTP/2 になったからといって、ネットワークを

.NET 7 から dotnet user-jwts という機能が生えてきました。ASP.NET Core で認証認可に JWT を使って開発している人間にとっては大変便利なのですよ、コレが。 はじめに dotnet user-jwts の使い方...の前に下準備 dotnet user-jwts の使い方 気になるかもしれない点 ASP.NET Core の内部実装 おわりに References はじめに 今の世の中 WEB API の認証認可は JWT で行っているケースが殆どでしょう。 そんな JWT ですが開発時にも当然使いますよね。SwaggerUI とか Postman に設定したりして。 が、そのような開発時に使う JWT の生成を皆さんはどうしているでしょう？ 使っている認証プロバイダにもよると思いますが、概ね多少の面倒が付きまとうのではないでしょうか。 そこで .NET

この記事は Qiita C# Advent Calendar 2021 23日目の記事です。 マルチスレッドプログラミングにおける問題。 原子性 コンパイラによる命令の並び替え メモリバリアについて acquire / release acquire / releaseの取り扱いづらさ sequential consistency C#でのマルチスレッド関連操作 lock (statement) volatile (keyword) Volatile (class) Interlocked (class) Common Language Infrastructure (CLI)における volatile read/write の仕様 まとめ References この記事のお話の流れは、①マルチスレッドプログラミングで発生する問題、②それらの問題に対処するためのメモリバイアについて、③それ

Dissecting the async methods in C# Async method internals 非同期メソッドを手動で分解する Async machinery The original method The state machine 1. “Hot path” optimization 2.Error handling How different pieces are glued together? Execution Context Conclusion References この記事は以下の記事を私が翻訳したものです。 https://devblogs.microsoft.com/premier-developer/dissecting-the-async-methods-in-c/ Dissecting the async methods in C# C#は開発