API構築の基礎を学んだ。QConは、開発者コミュニティにおける知識とイノベーションの普及を促進することで、ソフトウェア開発に力を与える。実務者主導のカンファレンスであるQConは、チーム内のイノベーションに影響を与える技術チームのリーダー、アーキテクト、エンジニアリングディレクター、プロジェクトマネージャー向けにデザインされている。Sheehy氏は、人工知能ハイプ時代における責任ある開発者としてのあり方について、洞察に富んだ開会基調講演をした。Grizzanti氏が、「スタッフ・プラス」への道と、それを「科学」というより「芸術」としてとらえ、芸術を創作することとソフトウェアを創作すること、そして組織のダイナミクスに対処することの類似性について語っている。Codeを採用する:確認するべき6つの適性LCNC(ローコード/ノーコード)プラットフォームは、プログラマーだけでなくプログラマーでなくても、最小限のコーディングとワンクリックのデプロイメントで、アプリケーションソフトウェアを開発できるよう設計されている。ドラッグ&ドロップ方式のインターフェースなどを利用することで、開発・デプロイメントプロセスを簡素化し、効率的なアプリケーション開発とデプロイメントを実現する。Xiao氏は先日,自社の公式技術ブログに,NetflixのWebサイトのUIをNode.jsに移行する作業で氏のチームが直面した,遅延の問題に関する記事を書いた。記事中で氏は,その根本原因を突き止めるために使用した複雑な技術プロセスと,それに伴って,基盤となるAPIフレームワークのリプレースを決意した経緯について説明している。問題が明らかになった最初の徴候は,APIのいくつかのエンドポイントにおいて要求の遅延時間が増加していること(10ms/時),その時にアプリケーションが予想以上にCPUを消費していることを,チームが認識したことだった。当初の予想は,チームが開発した要求ハンドラに何らかの問題(メモリリークのような)があって,遅延の増加を起こしているのではないか,というものだった。これを確認するためにチームは,コントロール可能な実行環境を立ち上げて,要求ハンドラが発生させている遅延時間と要求全体の遅延時間の両方を測定することにした。合わせてNode.jsのヒープサイズを32GBに拡大した。観測の結果,試験全体を通じて遅延時間とヒープサイズは一定であったにも関わらず,全体的な要求遅延とCPU使用率は上昇を続けることが分かった。Graph)とLinuxのPerfイベントを使って,アプリケーションのCPU使用率のプロファイルを取得することにした。そのフレームグラフ(下図参照)を詳細に調査した結果,Express.jsがrouter.handleとrouter.handle.next関数を頻繁に参照していることが判明した。Express.jsのコードベースを詳細に調査したところ,次のようなことが明らかになった。すべてのエンドポイントのルートハンドラは,ひとつのグローバル配列に格納される。適切なハンドラが見つかるまで,Express.jsは,すべてのハンドラの再帰的な参照と起動を行う。これについて氏は,次のように述べている。グローバル配列は,このユースケースの理想的なデータ構造ではありません。Express.jsがハンドラの保存に,なぜmapのような,検索時間が一定のデータ構造を使わなかったのかは分かりません。配列形式のルートから,要求それぞれのルートハンドラをルート配列で見つけるには,負荷の高いO(n)参照が必要になります。悪いことに,この配列は再帰的に探索されます。フレームグラフに高いスタックが見られるのは,このような理由からです。ように,同一のルートハンドラをいくつも設定することが可能になっています。ルートcの要求は,最初のcハンドラの位置(この配列では3番目)で終了しますが,dの要求は配列の7番目まで終了しません。a,b,それにcの複数のインスタンスでは,無駄な時間を費やすことになるのです。Express.jsがルートを格納する方法についてもう少し詳しく知るために,チームは次のようなExpress.jsのサンプルを作った。app.listen(3000);結果は次のようになった。]この試験からは,Express.jsはルートの重複を適切に処理できていない,という結論が得られた。氏は次のように指摘する。“/fooに2つの同じルートハンドラがあることに注意してください。Express.jsが,ひとつのルートに複数のルートハンドラチェーンがある場合は,必ずエラーをスローしていればよかったのですが。”自分たちのソースコードを詳細に調査した結果,チームは問題を特定した。問題は,1時間に10回実行される周期関数の中にあった。外部のソースを参照して,ルートハンドラをリフレッシュすることを主な目的とする関数だ。チームがそのコードをフィックスすると,重複するルートハンドラが追加されなくなり,遅延とCPU使用率の上昇も解消した。この出来事の結果としてチームの得た結論を,氏は次のように要約している。第1に,サードパーティのソフトウェアを製品に採用するには,事前にそれらを完全に理解しておく必要があります。私たちはコードベースの詳細な調査をせずに,Express.jsのAPIについて,誤った仮定をしていました。APIの誤った使用が,パフォーマンス問題の根本的な原因となったのです。第2に,パフォーマンスの問題に対しては,観測することが最も重要です。アプリのCPU時間の大部分を消費している場所を特定する上で,フレームグラフが素晴らしい洞察を与えてくれました。Node.jsのスタックをサンプリングしてフレームグラフとして視覚化できなかったとしたら,この問題が解決できたとはとても思えません。私たちは観測性をさらに向上させるべく,さらに優れた洞察と可視性,アプリケーションのコントロールを提供してくれる,Restifyへの移行を行っています。毎週火曜日に前週のまとめコンテンツをお送りいたします。(日本語版は不定期リリース)25万人のシニアな開発者コミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。毎週火曜日に前週のまとめコンテンツをお送りいたします。(日本語版は不定期リリース)25万人のシニアな開発者コミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。Inc.プライバシーBT。