Aws-lambda-dotnet: C＃Lambdaパフォーマンスvs.ノードvs. Python

パフォーマンスは、Lambdaとサポートされているすべてのランタイムで常に取り組んでいくものです。 すべての言語には長所と短所があり、それが私たちがとても楽しい言語戦争をしている理由です:)

このテストは、言語の実行時の起動時間を測定するだけです。これは、Node.jsやPythonなどの動的言語は、型チェックがなく、依存関係の読み込みが遅いため、C＃やJavaなどの静的言語と比較して常に高速です。

申し訳ありませんが、閉じるつもりはありませんでした。 気軽に会話を続けてください。

これを開いたままにしてくれてありがとう。 それは批判としてではなく、開かれた議論の基盤としての意味があります。

あなたの回答では、テストは言語の起動時間を測定すると述べました。 この声明をもっと明確にしたいと思います。 最初のヒットでは、アプリケーションがプロビジョニングされ（必要な場合）、起動されると思いましたが、その後のヒットでは、ウォームアップされます。 毎回起動する場合は、とにかくすべての呼び出しで構築されるため、run-onceコード（構成値の読み取りなど）をハンドラークラスのコンストラクターに移動するメリットはありません。 それはあなたのre：Inventプレゼンテーションから私が理解した方法ではありません。 明確にしていただけませんか。 どうも！

理解を確認するために、Lambdaコンテナがどのように機能するかをここで読み直しました： //docs.aws.amazon.com/lambda/latest/dg/lambda-introduction.html

@bjorg @normjこの点に関して、ドキュメントはかなりあいまいです:(
私は以下のフィードバックを提供しました、そしてそれが明らかになることを願っています

• 「どうすればそれを改善できますか？
  'ある時間'の実際の時間をステートメントで検索できる場所を正確に指定します。'AWSLambdaは、別のLambda関数の呼び出しを見越して、しばらくの間コンテナーを維持します。
• あなたは何をしようとしているのですか？
  パフォーマンスを予測するために、コンテナの再利用が実際に発生する可能性がどのくらいの時間かわからない

@bjorgここに投稿したのは、Lambdaの_コールド起動時間_ではありません。 しかし、_暖かい応答時間_。

C＃関数が最初に寒さから起動するとき、最大で数百ミリ秒かかる場合があります（私の場合は500ミリ秒です）。 ウォームアップされると、それは生き続け、あなたが投稿したものと同様のより速い速度でリクエストを処理します（私の場合は約0.9から1msでした）。 最終的には、その存続期間の終わりに停止するか、自動スケーリングが発生して、より多くのコールドラムダが起動します。 起動時間を取得するには、15分ほど待ってから、[テスト]をクリックします。

そうです、あなたはまだ物事をコンストラクターに入れています。 [テスト]をクリックするたびに新しいラムダを取得するわけではないためです。 ただし、1時間に1回クリックするだけで、新しいラムダを入手できます。

最適化に関しては、_コールドスタートアップ時間_に対して次のことができます。

1. ラムダが常に暖かいように、24時間365日常にリクエストが届くようにしてください
2. ラムダ（cloudwatchスケジュールまたはnewrelicなど）に定期的なpingを設定して、ラムダが常にウォームになるようにします。

_暖かい応答時間_については、実際にはあまり最適化する必要はありません。

1. 一般的に許容される人間の応答時間は200msです
2. 1ミリ秒未満は実際にはかなり良いです。 helloworldまたはtoUpper以外でこのレートを取得することはめったにありません。
3. API Gatewayをラムダの前に置き、HTTP呼び出しを世界に公開する場合。 Webからの平均キャッシュコールは約50ミリ秒になります。
4. AWSはとにかく100ms間隔であなたに請求します
5. 0.85msは、通常のpeice C＃コードの生のパフォーマンスにおそらく近いです。 mainメソッド内のマシンで関数を実行してみてください。を参照してください。

また、パフォーマンスと応答時間を混同しないでください。 手動で順番にクリックすると、ノードが20ミリ秒で応答するからといって、1秒あたり100kの自動リクエストがフラッディングし、1秒ごとに増加する場合に同じように動作するわけではありません。 実際の同時実行性と負荷テストを実行します。 JavaやC＃などのマルチスレッド言語は、負荷がかかった状態で1秒あたりにより多くの要求を処理する場合があります。 私は実際にラムダ統計をどこかで見ました：Python =最速のコールドスタートアップ、Java = 1秒あたりの最速のウォームリクエストですが、今は見つかりません。

とにかく、これはうまくいけばあなたの質問に答えるはずです。

ベンチマークを含むディスカッションが見つかりましたhttps://www.quora.com/Which-language-better-suits-for-AWS-Lambda

@yunspace 、詳細なFoo(Stream, ILambdaContext)署名は、ペイロードをPOCOインスタンスに変換するためのロジックをバイパスする事前定義されたハンドラーパターンである可能性があります。

残念ながら、呼び出しコードは検査に利用できないため、さらに最適化できるかどうかはわかりません。 ウォーム呼び出しのパフォーマンスは、他のランタイムに非常に近いと思います。

生の入力JSONをPOCOに非マーシャリングするために、デフォルトでは、ラムダは人気のあるAmazon.Lambda.Serialization.Jsonを使用します。 ただし、このデフォルトの実装を独自のシリアライザーと交換することができます。 標準データ型の処理に関するセクションを参照してください

意味がわかります。 ほとんどのシリアライザー（Json.Netを含む）は、遅いリフレクションを使用します。 この理論を証明するために、 Foo(Stream, ILambdaContext)がウォーム呼び出しの応答時間を改善するかどうかを確認できると思います。 もしそうなら、文字列とPOCOのためにあなた自身の顧客シリアライザーをロールすることはおそらく価値があります。

実際、私はデータデシリアライザーについて話していませんでしたが、ラムダハンドラーを呼び出すメソッドについて話していました。 ラムダハンドラーは（引数の型と数の両方で）異なるシグネチャを持つことができるため、ラムダハンドラーを呼び出すメソッドはリフレクションに依存する必要があります。 AFAIK、この便利な機械がバイパスされるような方法でラムダハンドラーを作成する方法はありません。

私は最近これについていくつかのテストを行いましたが、シリアライザーは実際にはそれほど大きな影響を与えていないことがわかりました。 実際、ほとんどすべての可動部分を削除して静的データまたは空のストリームを返すと、ウォーム関数で約0.85msを取得できるのが最善のようです。 C＃関数を呼び出しているコードが原因である可能性が高く、ラムダチーム（ @normj ）によってのみアドレス可能であるように思われます。

Javaを含む他のすべてのランタイムでは、ウォーム関数で0.22〜0.30ミリ秒を取得できます。 基本的に、ラムダ呼び出しのオーバーヘッドはC＃では3倍から4倍悪いことを意味します。

C＃の方が実際の作業が速くなる可能性があるため、これで全体像がわかるわけではないことに同意しますが、このフレームワークのオーバーヘッドは検討に値します。 これのいくつかは、それが新しく、パフォーマンスが最優先事項ではなかったことが原因である可能性があると思います。 また、ある種のキャッシングなしでリフレクションを使いすぎたことが原因である可能性があります。

これも初期のコードによるものだと思います。 それがどのように見えるかを見て、最適化を支援できるようにしたいと思います。 あるいは、実験するための低レベルのフックを用意することも役立ちます。

私も助けてくれたらいいのにと思います。 私は、C＃コアが無数の方法で機能するようになるのを待っています。 これは、AzureとAmazonの間の重要な定義要素です。 サーバーレスC＃アプローチは、Windows Update、パフォーマンスチェック、SQLUpdateなどで複数のEC2マシンを維持するよりもはるかに優れています。 これらの環境をクライアントにとって最新の状態に保つことは、ほぼフルタイムの仕事です。

サーバーレスC＃アプローチは、費用効果が高く、労働集約的でなく、自動的にスケーラブルで再利用可能です。

他の唯一の未解決の問題は、現在、費用効果の高いスケーラブルなRDCアプローチです:-)

このスレッドをサービスチームに渡して確認しました。 私は主に、これらのライブラリやVisual Studio統合などのクライアントツールを維持しているため、サービス側で何が起こっているかについてはあまり話すことができません。 サービスコードの表示を制限することで、リフレクションの使用が最適化されていることがわかりますが、調査する必要のある他の要因が常にあります。

@genifycom私の理解では、このスレッドは、他のランタイムと比較して、ウォームスタートの0.5ミリ秒のパフォーマンスの違いを追跡しています。 Lambdaは100ミリ秒単位で請求するので、このパフォーマンスの違いが使用を妨げていますか？ 私はこの不一致の根底に到達することの重要性を減らそうとはしていませんが、ラムダチームが現在パフォーマンスを改善するために取り組んでいる大きな領域はコールドスタート時間です。

明確にするために、それはC＃Lambda（または私たちがそれを命名したようにLambdaSharp）の採用を止めていません。 それはよりプライドの源です。 :)

完全に理解してください！

これが適切な場所かどうかはわかりませんが、現在C＃でWebバックエンドを構築しており、コールドスタート時間は数秒、場合によっては最大10秒以上になります。 しかし、その最初のヒットの後、すべてが順調です。 これは重要なC＃プロジェクトではまだ正常ですか、それともそれを減らすためにできることがありますか？ 使い慣れた.NETエコシステムで作業できることは大好きですが、これは私たちにいくつかの頭痛の種を与えています。

空のプロジェクトの方がはるかにうまくいくように見えるので、プロジェクトに含めた外部パッケージと、コールドスタート時にAmazonがそれらをどのように処理するかに関係していると思います。 私は誰かがこれに光を当てることができることを望んでいました。

@normj私たちが見ているパフォーマンスの問題に関する更新はありますか？

@SpoonOfDoom 10分ごとに叩くというアドバイスを見ましたか？ これは.Netの常識であり、90年代には、他の誰もしなかったことを知って、ホスティングビジネスを最速にしました-しかし、それはもはや非常に一般的であり、このような一般的なツールでさえも-https：//www.iis.net/downloads / microsoft / application-initialization-推奨されます。 Lambdaはコストモデルを変更しますが、エンジニアリング方法に関係なく、ある程度同じ課題に直面します。

@bitshopそれが私たちが現在行っていることです。 私たちはすべてを10分ごとに1回呼び出しますが、ほとんどの場合、それが役立ちます。 ただし、数時間ごとにスパイクが発生し、コールドスタートが再び発生します。.NetLambdasを実行しているAWSインスタンスの有効期間は最大で、現在のホット/コールドステータスに関係なく新しいインスタンスが使用されるようです。 わからない。
開発者にこれから完全に保護する機会を与えないというAmazonの奇妙な決定のようです（少なくとも価格については）。 確かに、現在は数時間ごとにピークに達していますが、スクリプトではなく顧客がヒットした場合でも、顧客はイライラし、アプリの信頼性が低い、または遅いと認識します。

@yunspaceテンプレートラムダ関数はまだ2000ms以上のコールドスタートアップ時間を必要とするようです。
REPORT RequestId: d1e5f56c-0ea9-11e7-bb5d-bb039f76a793 Duration: 2120.69 ms Billed Duration: 2200 ms

@normj何か間違ったことはありますか？

更新：関数がstring入力を受け取る場合、起動時間は約800ミリ秒になりますが、実際に別のタイプを選択すると、2000ミリ秒を超えることになります。

    // 800ms
    public string FunctionHandler(string input, ILambdaContext context)

    // 2000ms, Request being the other object type
    public string FunctionHandler(Request input, ILambdaContext context)

C＃の2つの異なるランバ機能で128MBで約21秒のコールド起動時間があり、どちらもSNSを受信して​​います。 私はS3プットトリガーとSNSでほぼ同じ時間を取得します。 暖かい、それは〜2秒です。

メモリを256Mに増やすと、タラの時間が約10秒に低下するのがわかります。

Lambdaログは、合計40MBのメモリで使用していることを示しています。

関数の1つから、合計実行時間：

128MBコールド：レポート期間：21775.92ミリ秒請求期間：21800ミリ秒メモリサイズ：128 MB最大使用メモリ：35 MB

128MBウォーム：レポート期間：1326.76ミリ秒請求期間：1400ミリ秒メモリサイズ：128 MB最大使用メモリ：37 MB

256MBコールド：レポート期間：11159.49ミリ秒請求期間：11200ミリ秒メモリサイズ：256 MB最大使用メモリ：39 MB

256MBウォーム：レポート期間：792.37ミリ秒請求期間：800ミリ秒メモリサイズ：256 MB最大使用メモリ：39 MB

384MBコールド：レポート期間：7566.07ミリ秒請求期間：7600ミリ秒メモリサイズ：384 MB最大使用メモリ：43 MB

384MBウォーム：レポート期間：850.59ミリ秒請求期間：900ミリ秒メモリサイズ：384 MB最大使用メモリ：47 MB

笑いのためだけに：

1024MBコールド：レポート期間：3309.12ミリ秒請求期間：3400ミリ秒メモリサイズ：1024 MB最大使用メモリ：38 MB

1024MBウォーム：レポート期間：677.57ミリ秒請求期間：700ミリ秒メモリサイズ：1024 MB最大使用メモリ：41 MB

これは、コールドスタートアップのオーバーヘッドが大きくなります。

比較すると、これは約半分の作業（C＃への移植前の古いバージョン）を実行するnodejs関数ですが、同じ種類の作業（SNSの取得、データベースへの書き込み、S3への保存）ですが、これは全体で当てはまるようです私たちが持っている他の機能を備えたボード：

128MBコールド：レポート期間：262.58ミリ秒請求期間：300ミリ秒メモリサイズ：128 MB最大使用メモリ：19 MB

128MBウォーム：レポート期間：134.79ミリ秒請求期間：200ミリ秒メモリサイズ：128 MB最大使用メモリ：19 MB

寒いときのオーバーヘッドの割合は、はるかに合理的と思われます。

Visual Studio AWSツールを使用してバンドルをアップロードしています-コードはアップロードされる前にターゲットプラットフォーム用にプリコンパイルされていますよね？ 私が見逃しているものはありますか、それともこれは正常ですか？ ここで報告されている他の数値は小さいですが、メモリ割り当てがわかりません。

コールドブート時間は、Slackが3,000ミリ秒後にタイムアウトするため、Slackボットを構築するときに問題になります。 インスタンスが常に利用可能であることを保証する方法があったらいいのにと思います。

この問題に関するテクニカルサポートチケットを開きました。 何か役に立つことを学んだら、ここで共有します。

Cloudwatch pingなどを使用してラムダをウォームに保つための多くの回避策がありますが、最終的にはコールドスタート時間は快適なものにする必要があります。 コールドスタートを最適化することはできますが、回避することはできません。 自動スケーリングが発生すると、新しいラムダもコールドからスケールアップすることは間違いありません。

@bjorgは、インスタンスが常に利用可能であることを保証します。おそらくEC2またはECSを検討する方がよいでしょう。

@ InsidiousForce21秒のコールドスタートが発生していることに驚いています。 ラムダ自体ではなく、あなたのコードだと強く思います。 重い初期化ブロックがありますか？ コードまたは単体テストをVSでローカルに実行する場合、どのくらい時間がかかりますか？ とにかく、私はあなたのコードを知らないので、推測しているだけです。 @SpoonOfDoomのような

@yunspace異端！ :)

さて、アマゾンで優しい技術サポートスタッフと長い前後にした後、会話の基本的なお持ち帰りはこれです：
あなたは、あなたのコードを最適化しようとすることができます - 説明したように、CPUパワーを高めるために、ファイルサイズを減らす絶対に必要ではないライブラリを捨て、少し静的および可能性として、起動時に初期化され得る他のものとして持ってしてみてください、そしてもちろんの増加割り当てられたメモリのこのスレッドインチそれを呼び出してラムダを生かし続けると問題を引き出すことができますが、それを排除することはできません。 それは信頼性の高いルールはありませんが、4分の間隔は、ほとんどの場合のために最高の価値のようですが、どうやら基本的な動作は、完全には確定的ではありません。 そしてそれでも、問題を完全には排除しません。

残念ながら、一番下の行は、これまでにこれまでに得ることができるだけであり、ある時点で割り当てが実行可能である可能性があります。 あなたは、常にこれらのコールドスタート時間を持つことになりますし、あなたがそれらを減らすことができるかもしれないが、あなたはおそらくそのように、それは公共の対面APIか何かのために合理的だポイントにそれらを軽減することができません - それはあなたの場合と思われますあなたが容易な展開と自動スケーリングをしたい場合は、Elastic Beanstalkでちょうど今、すべてを待ってから再度、その後、C＃のラムダはあなたのためではなく、あなたがより良いオフEC2インスタンスを持つか、多分（私たちが今やっているよう）している余裕はありません。
私たちは、今、私たちがまだのVisual Studioから快適な展開を行うと、いくつかの自動スケーリングオプションを維持することができますASP.NET Web APIをプロジェクトの中に私たちのラムダを変換しています。

TL; DR：この問題のまわりの信頼できる方法があるようです。 代わりに使用EBSやEC2。

活動不足のため閉会。 また、このリポジトリは主にクライアントライブラリとツールをサポートするためのものです。 このディスカッションのより良い場所は、Lambdaサービスチームが監視するLambdaフォーラムです。

こんにちは、みんな！
Python、PHP、Java、Ruby、C＃を比較した記事を作成しました。
それをチェックして、それについてあなたの意見を言うことができますか？ （これは純粋に技術的な資料ではありませんが、初心者向けにより一般化されています）
https://www.cleveroad.com/blog/python-vs-other-programming-languages

この記事は私には役に立ちませんでした。

第一に、それは比較ではありませんでした。 ページのタイトルには「他の言語よりもPythonを使用する利点」と書かれているので、明らかに比較ではありません。

第二に、すべての要件を満たす言語は1つではありません。

たとえば、スクリプト言語を使用して複雑なフレームワークを構築することは非常に困難です。 「Pythonはミニマルな言語であると言えます。読み書きは非常に簡単です。問題について考えるときは、開発者は言語ではなく問題に集中できます。その構文。」 豊富なモデルやモデルコンポーネント間の相互作用を支援し始めることすらありません。

私たちはマイクロサービスがすべてに答えるだろうと考え始めたようですが、私はそれが非常に素朴なアプローチであることを知るのに十分長い間このゲームに参加してきました。

問題にはさまざまな形があります。

genifycomに同意します。 それに加えて、間違っていないとしても疑わしいと思われる点がいくつかあります。 たとえば、Pythonで（私は手段が分散コンピューティングと仮定？）あなたは、ネットワークベースのアプリケーションを行うことができないということらしい無知、およびC＃が利用できる多くのライブラリを持っていないことを伝えると、使用可能なおおよそ100kのパッケージがあります考慮すると奇妙な文ですNugetだけで。
また、Pythonには「問題を解決する1つの方法」がありません。問題を解決する方法は常に複数あり、通常は言語とはまったく関係ありません。
次に、矛盾しているように見えるビットが1つあります。グラフで、Pythonはクロスプラットフォームアプリを実行できないと言っています（え？それは間違っているようです）。次に、テキストで「Pythonはほとんどすべての最新のオペレーティングシステムと互換性があります」 。
他にも小さな問題があります。たとえば、理論的にはメモ帳を使用してC＃でコーディングし、コマンドラインからコンパイルできます。IDEは必要ありませんが、IntelliJのような適切なIDEを使用すると、Pythonの開発もはるかに簡単になります。

それに加えて、ほぼ1年間使用されていないGitHubの問題が、ブログを宣伝する適切な方法であるかどうかはわかりません。

genifycomとSpoonOfDoomご意見ありがとうございます。これを考慮に入れます。

.NetCoreに有利な別の意見は次のとおりです。
https://read.acloud.guru/comparing-aws-lambda-performance-of-node-js-python-java-c-and-go-29c1163c2581

ラムダハンドラーの.NETの観点からc＃コードをより効率的にする方法に関するヒントはありますか？
私が対処しようとしている質問の例のいくつか：
1）ラムダ関数を静的にすると、ラムダコンテキストの再利用が増え、パフォーマンスが向上しますか？
2）Fu​​nctionsクラス（すべてのラムダハンドラーを含む）をシングルトンクラスにすると、パフォーマンスが向上しますか？
3）定数/読み取り専用変数を作成し、それをラムダ関数間で共有すると、パフォーマンスが向上しますか？

誰かが何か情報を持っているなら、提案してください

@ niraj-bpsoftwareなぜあなたはそれを試してみて、あなたの発見をここに投稿するのですか？ 目立った違いがあるかどうかを知りたいと思います。 正直なところ、これらのいずれかが影響を与えたとしたら、私は非常に驚きます。

1）関数の存続期間中の1回限りの固定費であるインスタンス化を前述することの利点は、絶対に最小限であり、測定可能なしきい値をはるかに超えているようです。

2）話せないので話せません。 ただし、ハンドラーが異なるラムダ関数である場合、私の理解では、ハンドラーはすべて別々のプロセス/コンテナーで実行されるため、そもそも何も共有しません。

3）同上。