App Service にデプロイした .NET アプリの応答遅延を分析する - Qiita
はじめに この記事ではApp Service にデプロイした .NET アプリの応答遅延を分析します。 下記の記事で事前準備してあります。 応答遅延の再現 10秒スリープするエンドポイントの例 ランダムに1~10秒遅延するリクエストを5分送ります。 import http from 'k6/http'; import { sleep } from 'k6'; export default function () { http.setResponseCallback(http.expectedStatuses(200)); // Generate a random sleep time between 1 and 10 seconds const sleepTime = Math.floor(Math.random() * 10) + 1; http.get('https://toshida
R3のコードから見る実践LINQ実装最適化・コンカレントプログラミング実例
C#パフォーマンス勉強会 https://cs-reading.connpass.com/event/309714/
今日からできる！簡単 .NET 高速化 Tips -2024 edition-
C# / .NET における、パフォーマンス改善の Tips をお届けします。 これを見れば、効率良く 80 点を取ることができるようになるはずです！
【C#】構造体(struct)を完全に理解する - Annulus Games
今回の記事はC#における構造体(struct)について。 複合的なデータを扱う際、多くの場面ではクラス(class)が用いられるかと思います。しかし、パフォーマンスが重要な場面や、GCによる影響が大きいUnityなどでは、状況に応じてクラスではなく構造体を使用した方が良いこともあります。 近年はC#においてもパフォーマンスが重視されるようになり、構造体が用いられる機会も多くなっています。またUnityのDOTSにおいても、C# Job SystemやBurst Compilerに最適化されたコードを書くために構造体を多用することになります。 ここでは構造体に関する基礎的な知識から、クラスと構造体のメモリ管理について、そして実際に構造体を用いる際の注意や活用方法についても解説していきたいと思います。 ただ今回の記事、調子に乗って色々な内容を詰め込んだ結果、めちゃくちゃに長くなってます。そのた
useCallbackはとにかく使え！ 特にカスタムフックでは - uhyo/blog
Reactには、パフォーマンス最適化のためのAPIがいくつかあります。具体的にはReact.memo、useMemo、そしてuseCallbackです。 React.memoで囲まれた関数コンポーネントは、propsが以前と変わっていない場合に再レンダリングが抑制されます。 また、useMemoやuseCallbackは、関数コンポーネント内での値の再計算を抑制する効果を持ちます。 これらは最適化のためのツールなので、「過度な最適化」を避けるように啓蒙する言説がよく見られます。 すなわち、ちゃんと本当に最適化のために必要なところにだけこれらを使おうということです。 特に、React.memoはpropsが以前と変わっているかどうかを判定するためのオーバーヘッドがあるし、useMemoやuseCallbackもフック呼び出しのオーバーヘッドがあります。 意味がないところでReact.memo
システムの負荷の原因を切り分ける方法 - Qiita
サーバのボトルネックを探る サーバが重い時、主に以下の4つがボトルネックとなる。 CPU使用率 メモリ使用量 ディスクI/O TCPコネクション数 この記事では、これらのうちどれがボトルネックとなっているかを突き止める方法について書く。 ロードアベレージを見る まずはロードアベレージを見ることで、おおまかに問題を切り分ける。 ロードアベレージの確認方法はload averageを見てシステムの負荷を確認するに書いた。 ロードアベレージが高い場合 現在のホストの「1. CPU使用率」, 「2. メモリ使用率」, 「3. ディスクI/O」を疑う。 ロードアベレージが1以下であれば軽く、1〜3くらいだとやや重く、それ以上だとこれらがボトルネックの可能性が高い。 ロードアベレージが低い場合 「4. TCPコネクション数」か、リモートホストがボトルネックになっていないか疑う。 特定のホストの問題を解
500点出す！ - ゆーすけべー日記
「Web Speed Hackathon 2022」という「非常に重たいWebアプリをチューニングして、いかに高速にするかを競う競技」があります。 リモート参加で11月1日から27日まで開催されています。 ここで言う「高速」とはCore Web Vitalsのスコアが高いことを言い、Lighthouseのスコアをベースにした500点満点の争いです。 ISUCONのフロントエンド版ですね。 以前にも同じ課題で「学生向け」と「社内（サイバーエージェント）向け」が行われたらしく、まだ500点を出した人はいません。 そこで僕は「満点を出したい」と思い、初日から、いやむしろフライングしていたからその前から頑張ってきました。 そして、先日（17日）、ついに500点満点を出しました！ たぶん、レギュレーションはクリアしている、はずです（もし違反してたらすいません…）。 自動で行われる「Visual Re
Performance Improvements in .NET 7 - .NET Blog
A year ago, I published Performance Improvements in .NET 6, following on the heels of similar posts for .NET 5, .NET Core 3.0, .NET Core 2.1, and .NET Core 2.0. I enjoy writing these posts and love reading developers’ responses to them. One comment in particular last year resonated with me. The commenter cited the Die Hard movie quote, “‘When Alexander saw the breadth of his domain, he wept for th
Performance Improvements in .NET 6 - .NET Blog
Great. But now let’s make a small tweak: [Benchmark] public int GetLength() { ITuple t = (5, 6, 7); Ignore(t); return t.Length; } [MethodImpl(MethodImplOptions.NoInlining)] private static void Ignore(object o) { } Here I’ve forced the boxing by needing the object to exist in order to call the Ignore method, and previously that was enough to disable the ability to devirtualize the t.Length call. Bu
Performance Improvements in .NET Core - .NET Blog
The biggest .NET virtual event is back, join-in now for the launch of .NET 8! Update (2017/06/12): Added BenchmarkDotNet blog post link. There are many exciting aspects to .NET Core (open source, cross platform, x-copy deployable, etc.) that have been covered in posts on this blog before. To me, though, one of the most exciting aspects of .NET Core is performance. There’s been a lot of discussion
なぜReactは標準でComponentをmemo化しないのか？
はじめに 普段はスタートアップでBtoB SaaSの開発をしているtaroと申します。 今回は、Reactのmemo化について考えている中で抱いた 「なんでReactは標準でComponentをmemo化していないんだろう？」 という疑問を解消するために、色々と調べたり考えたりした内容をまとめました！ 途中でrenderのタイミングや、memo化で再renderが抑えられる理由などの前提知識の復習も含めていて、memo化について詳しくない方もmemo化の勉強にもなると思うので、ぜひぜひ読んでみてくださいー！ なぜこんな疑問を抱いたのか？ まずはそもそも僕がタイトルにあるような疑問を抱いた背景です。 疑問を抱くまでの思考プロセスはこんな感じです。 「再renderが余分に走ってて画面が重いから最適化したいなー」 →「React.memo()を使ってComponentをmemo化しよう！」 →
neue cc - AlterNats - ハイパフォーマンスな.NET PubSubクライアントと、その実装に見る.NET 6時代のSocketプログラミング最適化のTips、或いはMagicOnionを絡めたメタバース構築のアーキテクチャについて
タイトルはここぞとばかりに全盛りにしてみました！今回NATSの.NETクライアント実装としてAlterNatsというライブラリを新しく作成し、公開しました。 github - Cysharp/AlterNats 公式の既存クライアントの3倍以上、StackExchange.RedisのPubSubと比較して5倍以上高速であり、通常のPubSubメソッドは全てゼロアロケーションです。 そもそもNATSとはなんぞやか、というと、クラウドネイティブなPubSubのミドルウェアです。Cloud Native Computing Foundationのincubating projectなので、それなりの知名度と実績はあります。 PubSubというと、特にC#だとRedisのPubSub機能で行うのが、StackExchange.Redisという実績あるライブラリもあるし、AWSやAzure、GCP
Chrome Devtools による フロントエンドパフォーマンスの計測
こんにちは。株式会社スタメンでFANTSのフロントエンドを担当している@0906kokiです。 今回の記事では、皆さんおなじみの Chrome Devtools にある Performance タブで、フロントエンドのパフォーマンスを計測する方法について書きたいと思います。 はじめに フロントエンドのパフォーマンス・チューニングと言うとバックエンドと比べて後回しになりがちですが、フロントエンドにアプリケーションの複雑性が寄ってきている現在、フロントエンドがボトルネックでレスポンスのレイテンシーが発生することは往々にしてあると思います。 バックエンドではユーザー数の増加や大量の同時接続に耐えられる負荷対策やパフォーマンス・チューニングが中心となりますが、フロントエンドではプロジェクトサイズの増加による JavaScript ファイルのダウンロードやスクリプティング、レンダリング速度の低下等が
パフォーマンス向上で知っておくべきコンピューターサイエンスの基礎知識とその実践
はじめに こちらの記事をZenにも共有してコミュニティに貢献したいと思います。 ネット上には様々な記事が溢れていますが情報が断片化していてプログラムを始めた初心者には全体像を掴むのが難しいです。コンピューターサイエンスの基本的な理解とパフォーマンスTIPSをまとめた記事があまり見当たらないのでまとめてみました。 ※コードの例はC#ですがホットパスやネットワーク通信の部分などはどの言語（Python、PHP、Javaなど）でもそのまま活用できます。 全てを計測する パフォーマンスチューニングの最も大事な原則は計測することです。 計測用のツールをまとめておきます。 ■BenchmarkDotNet C#コードの計測をするツールです。Nugetから利用できます。Stopwatchクラスではなくこちらを使いましょう。StopwatchではGCなどの影響を正しく計測できません。 ■Visual St
SQL Server / SQL Database パフォーマンスチューニングのための基礎知識 - Qiita
本投稿について 本投稿は、Microsoft Learn で公開されている、「SQL Server でクエリのパフォーマンスを最適化する 」を確認していた際に、いくつかの情報を補足しながら日本語化したものとなります。 SQL Server / Azure SQL Database のパフォーマンスチューニングには様々な方法があり、「このケースであればこの方法」ということを断定することは難しいのではないでしょうか。 そのため、様々なケースで利用することが可能な、チューニング方法の基礎知識 (一般論) はとても重要です。 本投稿で、確認を行った「SQL Server でクエリのパフォーマンスを最適化する 」は、チューニングに対しての体系的な考え方を無償で学ぶのには適しているコンテンツではないかと思いました。 チューニング系の講義は様々なノウハウが絡みますので有償が多く、ノウハウがない状態で体系
Webアプリ負荷試験ガイド - withgod's blog
Webアプリ負荷試験ガイド 目次 Webアプリ負荷試験ガイド 目次 前置き 時間がない人向け要約 about me 何故負荷試験を行うのか 負荷試験ツール 負荷掛けるツール 負荷計測 負荷の可視化 負荷試験の流れ 負荷試験スケジュールについて 注目すべきポイント シナリオ作成 アカウント情報は自動生成出来るようにする DB分割を行ってる場合はDB分割を意識したシナリオを用意する。 負荷試験元 http or https サーバ1台 サーバ単体での負荷 アプリの正常性の確認 サーバ複数台 KVS Memcached Redis RDB 問題になりやすいDB キャッシュの話 大前提 注意すべき点 CDNやProxyレベル local cache or remote cache local cache or memory cache(in app cache) references 更新情報 前
1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary
自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CEDEC 2023 モダンハイパフォーマンスC# 2023 Edition
パフォーマンス向上で知っておくべきコンピューターサイエンスの基礎知識とその実践 - Qiita
WEBアプリケーションのパフォーマンスをUPするために知っておくべき技術と知識 - Qiita
