100万回のWebSocket接続とGo | POSTD
こんにちは。私はSergey Kamardin（セルゲイ・カマルディン）です。Mail.Ru（ロシアの電子メールサービス会社）で開発者をしています。 この記事では、どのように私がGoを使って高負荷対応のWebSocketサーバを開発したかについて説明したいと思っています。 パフォーマンス最適化のアイデアやテクニックを通じて、WebSocketの知識はあるもののGoについてはほとんど知らないという方のお役に立てれば幸いです。 1. はじめに まずは開発に至った経緯について、どうして私たちがこのサーバを必要としたのかを説明しておきましょう。 Mail.Ruには多くのステートフルなシステムがあります。ユーザのeメール保存もその1つです。システム内、およびシステムイベントの状態変更を追跡する方法にはいくつかの種類がありますが、それらは主に状態変更に関するシステム通知、または周期的なシステムのポーリ
サーバの負荷テストのための、何百万ものHTTPリクエストを発生させる方法 | POSTD
(注記：6/9、いただいた翻訳フィードバックを元に記事を修正いたしました。) 今回の記事は毎秒300万ものリクエストを処理できるほど強力で高性能なWebクラスタの構築についてのパート1になります。まず初めに、あまり多くはありませんが、私がこれまで使用したことのあるロードジェネレータツールをいくつか紹介します。私のようにてこずって時間をかけてしまわないよう、今回の記事が理解の手助けになれば幸いです。 ロードジェネレータはテストを目的とした数種類のトラフィックを発生させるプログラムです。それによって高負荷においてサーバがどのように動いているか、そのサーバの弱点はどこなのか、などが見えてきます。負荷テストを通じてサーバの限界を知ることは、サーバのレジリエンシーを測定する最適な方法であり、あらゆる問題に対する準備の手助けにもなります。 ロードジェネレータツール 負荷テストをする際に頭に入れておくべ
スレッドプールのサイズを調整する
この他にも "サービスを受けるのを待つ人が，キューの中に立っている平均時間はどれくらいか？" といったような疑問に，Littleの法則で答をだすといった内容のゲームは，他にもたくさんあります。 図１. Littleの法則 同じようにLittleの法則は，スレッドプールサイズの決定にも使うことができます。私たちがしなければならないのは，リクエストの到着率と，サービスに必要な平均時間を測定することです。そうすれば，これらの値をLittleの法則に挿入して，システムの平均要求数が計算されます。その数値がスレッドプールのサイズよりも小さければ，その結果に従ってプールのサイズを小さくすることが可能なのです。逆に計算結果がスレッドプールのサイズよりも大きい時には，問題はもう少し複雑になります。 実行中のリクエストより待ち状態のリクエストの数が多い場合，まず最初に判断しなければならないのは，もっと大きな
ApacheとNginxの性能比較でevent_mpmの本気を見た
はい、これは僕がいつも良く見るApacheとNginxの性能差に見えます。大体、ApacheはNginxの75%程度の性能に落ち着きます。数十バイトの静的コンテンツに対するリクエスト処理はNginxの得意分野だと思っていたので、大体こんなものです。 そこで、真面目にevent_mpmのチューニングを行ってみました。で、幾度となくベンチを試した結果導き出した、静的コンテンツに対する同時接続数100程度に対して最高のパフォーマンスを示すevent_mpmの設定は以下のようになりました。 [program lang=’apache’ escaped=’true’] StartServers 4 MinSpareThreads 4 MaxSpareThreads 4 ThreadsPerChild 2 MaxRequestWorkers 2 MaxConnectionsPerChild 0 [/p
なぜあなたがウェブサイトをHTTPS化するとサイトが遅くなってユーザーが逃げていくのか - 射撃しつつ前転 改
完全に釣りタイトルですけど中身は真面目に書くよ。 近年、ウェブサイトのHTTPS化が流行のようになっている。私の知る限り、Googleの各種サービスやTwitter、Facebookなどが完全にHTTPSで通信を行うようになっている。HTTPS、つまりSSLによる通信の暗号化によって、ユーザにこれまでよりも安全なウェブサイトを提供できる。 しかし、あなたが作っているサイトをふと思いつきでHTTPS化してしまうと、たぶん、これまでよりもサイトが遅くなる。ここでは、HTTPSで通信する場合の問題を解説する。 なぜ遅くなるのか HTTPで通信する場合、クライアントがサーバへと接続するためにはTCP/IPの3ウェイハンドシェイクという手順が必要になる。めんどくさいのでここでは詳しくは説明しないが、要するにクライアントがリクエストを投げる前にパケットを１往復させないといけないのである。パケットの往復
HTTPリクエストの削減とWebサイト高速化まわり - Archiva
Make a note of it: Web tech, montaineering, and so on. Note: この記事は、3年以上前に書かれています。Webの進化は速い！情報の正確性は自己責任で判断してください。 メモ書き。社内説得用。「HTTPリクエストを減らすと高速化できるよ！」てのはよく聞くけど、それが「どうしてか」ってのを(読込待機時間まわりで)具体的な数字を出してることが意外と少なかったので。詳しくは参考リンクにGo! Webサイトを分析するWebアプリ PageSpeed Insights WebPagetest 参考資料など Webパフォーマンス最適化のためのコーディング手法, MOL @importを使うべきでない理由, Screw-Axis まずHTTPリクエストがコストが高い理由ですが、まあ同時読込できないからですよね。読込に1秒掛かる画像A,B,Cがあると
おそらくはそれさえも平凡な日々: #isucon で優勝させてもらってきました
まずは、ライブドアの皆様、素晴らしいイベントの提供本当にありがとうございました。めちゃくちゃ楽しかったです。 Kayacのエンジニア3人 @fujiwara @sugyan @songmu の3人でチームfujiwara組を結成し、結果優勝することができました。 実際は周りの認識通り、@fujiwaraさんに優勝させてもらったようなもので、@sugyanと僕は手を動かしていただけです。まあ、空気にならずには済んだので、そこは安堵しています。 修正したisuconソースはフォークしてGithubに置きました。プログラムの修正部分のみで、my.cnfの修正なんかはここには反映されていません。 さて、@fujiwaraのコンテストでの動きや、帰宅後のBlogアップまであらゆる仕事が速くてビビるんですけど、詳しくは、#isucon で優勝してきましたを見てもらうとして、 どういうドタバタがあったの
最速TCPサーバーの条件 〜逆襲の Erlang と Haskell の挑戦〜 : DSAS開発者の部屋
釣った反響に応えて echo サーバーを改良していて PyCon JP の発表資料作成が進みません。 自業自得です。 methane です。 Erlangとは何だったのか でのベンチマーク結果では Erlang のスコアが奮わなかったのですが、 github で 性能改善する pull request をいただきました。 性能が悪かった原因ですが、実は backlog がデフォルトだと 5 で、ベンチマーク開始時の 大量の接続要求を捌ききれていないという状況でした。 高負荷サイトのボトルネックを見つけるには で紹介されている事例と同じ現象ですが、こちらのほうが backlog が小さく、 しかもベンチマーク用クライアントはほぼ同時に大量に接続をしてくるという条件で よりシビアに現象が発生してしまいました。 この問題が修正された Erlang は、 Go を超えて一気にランキング上位に踊り出
The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software
The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software The Free Lunch Is Over A Fundamental Turn Toward Concurrency in SoftwareBy Herb Sutter The biggest sea change in software development since the OO revolution is knocking at the door, and its name is Concurrency. This article appeared in Dr. Dobb's Journal, 30(3), March 2005. A much briefer version under the title "The Concur
NoSQLとしてMySQLを使うDeNAが、memcachedよりも高速な75万クエリ／秒を実現
モバゲーで知られるDeNAは、バックエンドデータベースにNoSQLを使っていません。なぜか？ それはMySQL/InnoDB 5.1の環境で秒間75万クエリという、多くのNoSQLでも実現できないような高性能を実現しているから。DeNAの松信嘉範（まつのぶよしのり）氏は、自身のブログにこんな内容のエントリ「Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server」（英語）をボストしています。 Yoshinori Matsunobu's blog: Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server 松信氏が指摘するように、大規模なネットサービスを提供している企業の多くは分散環境で
Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server
UPDATE: Oracle officially released memcached daemon plugin that talks with InnoDB. I'm glad to see that NoSQL+MySQL has become an official solution. It's still preview release but will be very promising. Let's try it to make it better! Most of high scale web applications use MySQL + memcached. Many of them use also NoSQL like TokyoCabinet/Tyrant. In some cases people have dropped MySQL and have sh
コンピュータサイエンス史上最大の課題「並列処理による性能向上」～情報処理学会創立50周年記念全国大会の招待講演
「いま、並列処理の壁というコンピュータサイエンス史上最大の課題に直面しています。しかしこれはチャンスでもあります。新しい時代を切り開いていきましょう」。IBM名誉フェローのFran Allen氏は、昨日3月10日に行われた日本の情報処理学会創立50周年記念全国大会の招待講演の演壇からこんなメッセージを聴衆に投げかけました。 Fran Allen氏は、コンパイラやプログラミング言語が専門で、女性で初めてチューリング賞を受賞した人。今回の招待講演のためにわざわざ来日したと紹介されました。 講演のタイトルは「The Challenge of the Multicores」。ここからは、Allen氏の講演の内容を紹介しましょう。 （この講演は英語で行われたものです。内容にはできるだけ正確を期したつもりですが、理解不足のところや聞き取れなかったところもありました。もし誤解や不正確なところがありました
アプリケーションがマルチスレッドでもマルチコアCPUを活かせない件 - blog.nomadscafe.jp
もっと詳しい方のフォロー募集です アプリケーションがマルチスレッドになってもネットワーク処理が分散されなければマルチコアを活かせない典型的な例です。id:viverの古橋さんがs100kpsとしてあげていた件にも近いかも。 memcachedで現象を確認します。最近のmemcachedはマルチスレッドで動くようになっているので、まずはそれを確認します。 $ memcached-tool localhost stats|grep threads threads 4 スレッドが4つで起動しています。 負荷がそれなりにある状態(8000req/sec程度)で、コマンドラインでtopを開き、「1」キーを押して、CPUごとの使用率を表示します。(例はFedora8 kernel-2.6.23) Tasks: 77 total, 1 running, 76 sleeping, 0 stopped, 0
Facebookが大規模スケーラビリティへの挑戦で学んだこと（前編）～800億枚の写真データとPHPのスケーラビリティ問題
Facebookが大規模スケーラビリティへの挑戦で学んだこと（前編）～800億枚の写真データとPHPのスケーラビリティ問題 全世界で3億人を超える会員を抱え、世界最大のSNSとなったFacebook。同社の巨大なシステムは、3つのデータセンターにある約3万台のサーバと、PHP、C++、Memcache、MySQLなどのソフトウェア群によって支えられています（同社のデータセンターの巨大さは、記事「3億のユーザーを抱えるFacebookのデータセンター。移動は自転車、希望は100Gbイーサネット 」を参照）。 同社の技術担当バイスプレジデント Jeff Rothschild氏は、Facebookが実現している大規模なスケーラビリティを、いかにしてこれらのソフトウェアで実現しているのか、10月8日に米カリフォルニア大学サンディエゴ校で行ったセミナー「High Performance at Mas
Kazuho@Cybozu Labs: 「サーバ書くなら epoll 使うべき」は、今でも正しいのか
多数のTCP接続をハンドリングするサーバを書くなら、1コネクション1スレッドのモデルではなく、epollやkqueueのようなイベント駆動型のI/O多重化を行うべきだ、と言われます。だが、そのような主張は、「C10K問題」が書かれた2002年から7年経過した今でも有効なのでしょうか？ echoサーバを書いて、ベンチマークを取ってみることにしました。 ふたつのグラフは、いずれも接続数とスループットの関係を表しています。最初のグラフは、全接続がアクティブに通信した場合、あとのグラフは、全接続のうち小数のコネクションが順次アクティブになっていく、というモデルです。これらのグラフから、以下ようなことが読み取れます。 epoll も per-thread モデルも、良くスケールする epoll は、ワークセットが小さい場合に (最大50%) per-thread モデルよりも高速 少なくとも、1コネ
How FriendFeed uses MySQL to store schema-less data - Bret Taylor's blog
Background We use MySQL for storing all of the data in FriendFeed. Our database has grown a lot as our user base has grown. We now store over 250 million entries and a bunch of other data, from comments and "likes" to friend lists. As our database has grown, we have tried to iteratively deal with the scaling issues that come with rapid growth. We did the typical things, like using read slaves and
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プログラムを高速化する話
Effective Concurrency: Choose Concurrency-Friendly Data Structures
SSDとTokyoTyrantやMySQLの性能検証
http://1978th.net/tech/promenade.cgi?id=31