デブサミ2016登壇資料。サーバ技術の評価軸、HTTP/2、サーバプッシュ、HTTPS化の負荷、Brotli、サーバ内スクリプティングを俯瞰Read less
![HTTPとサーバ技術の最新動向](https://cdn-ak-scissors.b.st-hatena.com/image/square/17ce3e062dddbf84bf9345fc6c051e5192c4ca50/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fhttpdevsumi20160219-160219052130-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
デブサミ2016登壇資料。サーバ技術の評価軸、HTTP/2、サーバプッシュ、HTTPS化の負荷、Brotli、サーバ内スクリプティングを俯瞰Read less
HTTP is the fundamental networking protocol that powers the web. The majority of sites use version 1.1 of HTTP, which was defined in 1999 with RFC2616. A lot has changed on the web since then, and a new version of the protocol named HTTP/2 is well on the road to standardization. We plan to gradually roll out support for HTTP/2 in Chrome 40 in the upcoming weeks. HTTP/2’s primary changes from HTTP/
もはやHTTP/2リファレンス実装であるHTTP/2のCライブラリnghttp2の作者であるtatsuhiro_tさんが素晴らしいベンチマーク結果を公開されました。 その中で以下のように、あまりにもH2Oやnghttpdと比べてtrusterdのTLS利用時の性能が遅かったため改善しました。 server 6 bytes 4K bytes h2o 227865 78333 nghttpd 226716 80673 trusterd 62362 44020 ref: https://gist.github.com/tatsuhiro-t/5f3b170414582ac58091#tls-with-flow-control 主に原因としては以下が考えられます。 TLS record sizeが小さすぎる それに伴いTCP_NODELAYオプションとも相まってパケットサイズも小さすぎる パケット
この記事は ドワンゴ Advent Calendar 2014 20日目の記事です 新しい年を迎える準備 もうあと10日もしたら新年です。 みなさん新年を迎える準備はできているでしょうか? ん? その前に大事なイベント? コミケのことかな??? 正月の準備といえば、家を大掃除し、しめ飾りや門松を飾り、餅を撞き、おせちを作り、色々ありますが、 これはすべて神様を迎え入れるための準備なんですね。 年神様という、元日に各家に訪れ、一年の実りと幸せをもたらしてくれるありがたい神様です。 年神様を心から歓迎し、失礼ないようおもてなしすれば、次の一年の幸福と繁栄とマネタイズは約束されたも同然です。 さて、今年は、Railsエンジニアが年神様をお迎えするにあたって、 その前に供物を捧げ荒ぶる現世神の怒りを鎮めなければなりません。 すなわち、今年のうちに secure属性がついたcookie を現世神にお
Amazon SageMaker Geospatial Capabilities Now Generally Available with Security Updates and More Use Case Samples At AWS re:Invent 2022, we previewed Amazon SageMaker geospatial capabilities, allowing data scientists and machine learning (ML) engineers to build, train, and deploy ML models using geospatial data. Geospatial ML with Amazon SageMaker supports access to readily available geospatial dat
Nginx + Luaを用いた、ハイパフォーマンスで動的なプロキシサーバを考察中です。 そのための施策の一つとして 上流サーバへのアクセスをKeepAliveする という方法がありますが その際、プロキシサーバにどの程度性能に変化があるのかを調査してみました。 リバースプロキシのkeepalive設定 前提条件として Nginx > 1.1.4 が必要。 upstreamに keepalive というattributeがあるのでそれを設定します。 それと同時に、プロキシヘッダーにHTTP/1.1設定などを行いましょう。 ちなみにproxy_passだけだとkeepaliveできないようです。upstream必須。 あと、もちろんバックエンドサーバ側もkeepalive設定しておきます。 upstream http_backend { server oreore.micro.service;
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く