Yahoo! JAPAN における HTTP/2 への取り組み
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog はじめに こんにちは。システム統括本部 プラットフォーム開発本部 エンジニアの大久保諒です。 Yahoo! JAPAN のサービス利用者の皆様に、より高速にコンテンツをお届けするためのキャッシュ・プロキシサーバー関係の開発業務に携わっております。 本記事ではオープンソースの HTTP キャッシュ・プロキシサーバー Apache Traffic Server で HTTP/2 通信を可能とする為の機能追加を行いましたので簡単にご報告致します。 HTTP/2 の基本的な解説に関しては 前回の記事 にまとまっています。ぜひそちらをご覧の上で本記事をご覧ください。 本件の実装は Apache Software Foundation にパッ
Trasis Lab » apache, tomcatで負荷分散
概要 apache+tomcat サーバ2台で負荷分散環境設定の記録。 要件 正常時は2台のtomcatサーバで負荷分散。 セッションは DB(postgresql) に格納する。 負荷分散時、stickysession 機能により、一ユーザのアクセスは可能な限り、１つの tomcat サーバに固定する。 1台あたりのtomcatサーバで扱うセッション数はなるべく少なくし、余計なメモリを消費しないようにする。 Apacheサーバ設定 /etc/httpd/conf.d/tomcat.conf を作成し、次のように記述した。 LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_balancer_module modules/mod_proxy_balancer.so LoadModule proxy_http_modul
JVNDB-2011-002351 - JVN iPedia - 脆弱性対策情報データベース
CVSS v2 による深刻度 基本値: 5.0 (警告) [NVD値] 攻撃元区分: ネットワーク 攻撃条件の複雑さ: 低 攻撃前の認証要否: 不要 機密性への影響(C): 部分的 完全性への影響(I): なし 可用性への影響(A): なし Apache Software Foundation Apache HTTP Server 1.3.x から 1.3.42 Apache HTTP Server 2.0.x から 2.0.64 Apache HTTP Server 2.2.x から 2.2.21 アップル Apple Mac OS X v10.6.8 Apple Mac OS X v10.7 から v10.7.4 Apple Mac OS X Server v10.6.8 Apple Mac OS X Server v10.7 から v10.7.4 オラクル Oracle Applic
mod_proxy_httpとmod_proxy_ajpとmod_jk — ありえるえりあ
Recent entries Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23 Herokuの発音 inoue 2010-12-20 雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18 IPA未踏のニュース inoue 2010-12-15 労基法とチキンゲーム inoue 2010-12-06 フロントエンドエンジニア inoue 2010-12-03 ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25 技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24 雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22 RESTの当惑 inoue 2010-11-22 「プ
Apacheのmod_proxy_balancerを使うときはretryを設定すべき - 射撃しつつ前転
今作っているサービスは、Apacheのmod_proxy_balancerを使ってロードバランシングしている。しかし、バックエンドのサービスサーバを一旦落としてから復帰させると、コネクションがしばらくつながらないという問題に悩んでいた。1分ぐらい放置するとつながるようになるんだけど、1分は結構長い。 よくわからないのでソースを読んでみたところ、mod_proxy_balancer.cを眺めた感じ、ap_proxy_retry_workerという関数がコネクションの再確立をしているのではないかと思えた。しかし、関数の定義を眺めてみると、現在時刻がエラー発生時刻とworker->retryを足した数字よりも大きければworkerのstatusからPROXY_WORKER_IN_ERRORのビットを下ろしているだけで、コネクションの確立がどうのこうのなんて関数はまったく呼ばれてない。ここでなにが
既知の問題およびHowToまとめ - たごもりすメモ
結論を先に書くと「trunk使え」か？(ぇー まあ2.2.4でもなんとかなるかも。2.2.3以前だとかなり注意しないと、道を踏み外した瞬間に穴にハマりそう。 で、以下リスト。 trunkで修正されているもの Critical: リクエストが間違ったワーカーに配送される Bugzilla 40910 ポート番号に限らずホスト名(/IPアドレス)の部分一致でも発生する はてなの中の人が発見 追試済み 配送先が ajp:// の場合は正常に動作する？ らしいという情報がある(未確認) stickysession/routeによるルーティングが有効でもこのバグにひっかかる 部分一致するホスト名のうち長いものを設定ファイル上で先に書いておくと回避できる 2.2.4で修正済みのもの Critical: 一度エラーになったセッションがTimeoutを過ぎてもエラーから復帰しない Bugzilla 389
MODULE.JP - リソースプール適材適所
Apacheにmod_rpafモジュールを組み込んでKeepAliveを有効にするとIPアドレスに変なゴミが入るけどなんで？なお話。まだ仮説の段階ですが原因と解決策。(レポート後2004/03/17にリリースされたmod_rpaf v0.5で改修されています) naoyaさんのWeblogを読んでいてmod_rpafモジュール(version 0.4)がKeepAlive Onの際に変な動きをするというお話を知りました。かなり今更な感じの反応でアレですが、ちょっと興味が在ったので調べてみたところmod_rpaf version 0.4のマズそうなところを見つけたのでご報告。 mod_rpafの概要 通常のWebサーバへのリクエストは [client] -- request --> [Web server] と、クライアント(Webブラウザ等)がWebサーバに直接リクエストを発行します。この
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
