Amazon ECS でのコンテナデプロイの高速化
Amazon ECS でのコンテナデプロイの高速化 この記事は同僚の Nathan Peck (@nathanpeck)が書いた記事 “Speeding up Amazon ECS container deployments” を翻訳し、加筆・修正したものです. 元記事を ECS ユーザに紹介する機会が何回かあったので、せっかくなので翻訳することにしました. コンテナのオーケストレーションは非常に複雑な問題の一つです. アプリケーションコンテナのデプロイのために、相互にやり取りを行う複数の異なるコンポーネントが存在します. あなたのアプリケーションを実行したオーケストレータは、その実行されたアプリケーションが Web トラフィックを受け取る用意ができているかどうかについて判断する必要があります. その後そのアプリケーションはスケールダウンされたり、あるいは新しいバージョンのアプリケーション
ネットワークプログラミングの基礎知識
ネットワークプログラミングの基礎知識 ここでは IP アドレスやポート番号、クライアントとサーバの役割などを説明し、 perl・C言語・Java などでソケット (Socket) を使った HTTP クライアントや POP3 クライアント、簡単なサーバを作成してみます。 要はネットワークプログラミングをやってみよう、ということです。 このページのサンプルプログラムは、RFC などの規格に準拠した「正しい」プログラムではありません。 また、全体的にエラー処理が不十分です (今後改善する予定です)。 あくまでも概要を理解するためのサンプルととらえてください。 もし本気でしっかりとしたクライアントやサーバを書きたいなら、このページを読んだ上で、 さらに RFC を熟読し、そして wget・Apache・ftp コマンドなどのソースを参考にしてください。 このページに間違いを見付けたら、掲示板 で
図書館クロール補足 - 最速転職研究会
なんか技術的におかしなことを言っている人がいたら追記していくかも知れません。 クロール頻度が妥当かどうかの話 ウェブサーバーはマルチスレッド、マルチプロセスなどで複数のリクエストを同時に処理できるようになっているのが一般的であるため「前回のリクエストが完了してから、次のリクエストを投げる」実装になっている限りは「サーバーの性能を100%使いきって他の利用者が利用できない状態」になることは、通常起きません。 例外的なケースもあります。 ウェブサーバーがリクエスト完了後に何らかの処理を行うような実装になっていて、リクエストのペースによっては処理が溜まっていって追いつかなくなる。 ロードバランサ、リバースプロキシを使ったフロントエンド/バックエンドの構成になっているサーバーで、フロントエンドがタイムアウトと判断して早々にエラーを返したが実際はバックエンドで処理が続いている。 例えば1秒で処理が終
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
