小さな勉強会の始め方、広げ方、あるいは友達の作り方 / How to Start, Grow, and Build Connections with Small Study Groups

昨年末からずっとこんなことをしてまして、この時期になってようやく今年初のブログ記事です。 進捗的なアレがアレでごめんなさい。そろそろ3年目に突入の @pandax381です。 RTT > 100ms との戦い 経緯はこのへんとか見ていただけるとわかりますが「日本と海外の間を結ぶ長距離ネットワーク（いわゆるLong Fat pipe Network）において、通信時間を削減するにはどうしたらいいか？」ということを、昨年末くらいからずっとアレコレやっていました。 送信したパケットが相手に到達するまでの時間（伝送遅延）を削減するのは、光ファイバーの効率の研究とかしないと物理的に無理なので、ここで言う通信時間とは「TCP通信」における一連の通信を完了するまでの時間です。 伝送遅延については、日本国内のホスト同士であれば、RTT（往復遅延時間）はだいたい10〜30ms程度ですが、日本・北米間だと10

近年，汎用計算の高速化のためのアクセラレータとして注目されているGPUを，ネットワーク処理に適用する一環として，サーバサイドのSSL処理に注目した論文を読んだので，内容を軽く紹介します． SSLShader - GPU-accelerated SSL Proxy SSLShader SSLShader: Cheap SSL acceleration with commodity processors Proceedings of the 8th USENIX conference on Networked systems design and implementation 2011 なお，評価に使われた実装の一部のソースコードが公開されています． http://shader.kaist.edu/sslshader/libgpucrypto/ 紹介 背景 SSL(Secure Socket

はじめに こんにちは、クラスメソッド株式会社でWebを担当している野中です。これから身につけるWebサイト高速化テクニック第2回目です。 第1回の「Webサイト高速化対策の現状」は読んでいただけましたか？「Webサイト高速化対策の現状」では高速化対策がなぜ必要なのかを紹介しているので、この回を読む前にぜひ読んでおいてください。 今回は、Webサイトの高速化に大きく関係するHTTPについて復習したいと思います。高速化対策と言ってもWebサイトが遅延する原因はさまざまです。 読み込むファイル数が多いことやサーバー側の処理に時間がかかっている、またはエンドユーザーが利用しているネットワークが原因かもしれません。 ところが原因を探っていくと、Webサイトが遅くなってしまう要因の多くにHTTPが関係しています。 実際の高速化手法も大事ですが、事前知識としてHTTPについて知っておきましょう。 対象読

はい、これは僕がいつも良く見る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

11月25日、「mobidec 2011」においてコナミデジタルエンタテインメントのスタジオITセンター長である正延光弘氏によるセッション「大ヒットSNSゲーム『ドラゴンコレクション』を支えるコナミのクラウド技術の活用」が行われました。 ドラゴンコレクションは、GREEで提供されている携帯電話向けのカードゲームタイプのRPG。プレイヤーは、エリアごとにある複数のクエストをクリアしていき、モンスターカードや「秘宝」を手に入れ、さらに「ドラゴンカード」を集めていきます。また、ほかのプレイヤーとバトルすることでも秘宝を入手できるというSNS要素も取り入れられていました。2010年9月のサービス開始後、順調にプレイヤー数を伸ばし、現在では登録人数が500万人を超えています。 サービス開始当初は社内でサーバを構築し、フロントエンドに6台のサーバ、バックエンドに3台のデータベースサーバ、そしてロードバ

ざっくり概要 ピークで3000req / sec 毎分コンテンツ更新要求 コンテンツ更新の際は他所からデータをapi経由で受け取る コンテンツ更新にはTheSchwartzを使用 なコンテンツを色々してきたログ。 尚、ここに書く技術は大半が周囲のギークな方々にサポートしてもらったもので、僕自身が何かしたわけではない。残念すぎる。 構成 internet -> www(squid -> apache) -> app(memcached -> app) -> db フロントエンド wwwサーバがapacheとsquidを動かしている。apacheがリクエストを受け、squidのキャッシュが有ればそれを返し、無ければバックエンドのappサーバへproxy。 バックエンド appサーバがmemcachedとアプリを動かしている。 それぞれ冗長化してるけど、リクエスト数の割に台数は少ない。 技術があ

はじめに アクセスが急増すると、応答時間が著しく悪化するサイトはありませんか？ 普段は200ミリ秒以内で安定してアクセスをさばいているのに、イベントやらキャンペーンやらを開始した瞬間から、普段の２倍や３倍のアクセスが殺到し、その結果、レスポンスタイムが3秒とか9秒とかかかるようになってしまうことってありますよね。 あるサイトの実状 つい先日まで、そんなサイトが私の目の前にもありました。自社で運営している某ソーシャル系のサイトなんですが、イベント開始時刻と同時にアクセス数が急増するのです。とはいえ、所詮は普段の2倍とか3倍程度の数なのだから、少なくとも1秒以内にレスポンスを返せるくらいの性能は維持したいものです。 しかし実際は困ったことに、応答に3秒以上もかかってしまう処理が大量に発生してしまう状況に陥ってしまっていました。これはきっと、どこかにボトルネックがあるに違いありません。 仮説を立

ユーザビリティの改善や検索エンジン対策としてウェブページの読み込みスピードの高速化は非常に重要です。ということで、ページの読み込みスピード向上のために役立つサイトをまとめてみます。 ページ読込速度の重要性 次の事例にあるように、ユーザーは表示速度に敏感です。 Googleによるとページの読み込みが0.5秒遅くなると、検索数が20%減少する Amazonによるとページの読み込みが0.1秒遅くなると、売り上げが1%減少する そして、Googleのアルゴリズムにウェブページの読み込み速度が追加されて以降、サイトの高速化への注目度は高まっています。 Google、ウェブページの読み込み速度をアルゴリズムに取り入れたことを発表 | 海外SEO情報ブログ Googleがついに順位決定に表示速度を使い始めた（公式発表） | Web担当者Forum Google、検索順位にページ読込速度の考慮を開始 [詳

はい、今さら聞けないウェブ開発者の基礎知識のお時間です。 ブラウザには3つの読み込みモードがあることはご存知ですか？ 2つくらいはわかるけど、3つ目が出てこないって方は少なくないかもしれません。 リロード 一番オーソドックスなのがブラウザのリロードボタンを押したときの挙動ですね。普通ですね。 スーパーリロード ブラウザによっては、スーパーリロードという機能を備えています。IEの場合Ctrl+F5(Ctrl+更新ボタン)、Firefoxの場合Ctrl+F5(Shift+更新ボタン)、Chromeの場合Shift+更新ボタン(Ctrl+Shift+R)などでスーパーリロードを呼び出すことができます。スーパーですね。 ページ遷移(リフレッシュ) 3つ目はちょっと良い名前が思いつかないのですが、リロードではなく、通常の画面遷移での読み込みのことです。アドレスバーにフォーカスしてenterするといっ

インターネットでデータを送るときには、あたりまえだが、必ずいくらかの時間がかかる。これを遅延(latency)という。 よくインターネットのサービスで独自の技術により低い遅延（low latency）を実現したとかいう記事がでる。これがなにを意味するか、ネットワーク技術が専門のはずのIT企業の社員でも、全然わかってないひとが多い。 というわけで今回はインターネットでの遅延についてよくある誤解を紹介して、本当はいったいなんなのかということを説明しようと思う。 まず、よくサイトが重いとか、インターネットがめちゃくちゃ遅いというのと遅延が高いというのとは本質的には別の現象なんだが、よく混同されている。もちろんインターネットが遅くなっている場合には結果的に遅延も大きくなっていたりする。しかし、サイトが重くなったり、インターネットが遅くなっている本当の理由は、だいたいサーバの処理が追いついていないか

比較的大きいサイズのファイルをSCPで転送することがあって、できるだけ高速化してみたかったので、色々試してみたメモ。 scpというかsshには、暗号化方式と圧縮有無の指定があるので、それらのベンチマークを。 尚、以下は、SSH v2が対象です。v1はかなり遅かったのと、そもそも使っていないので試していません。 (追記: 2019/11) 本エントリの情報は既に古いため、以下のエントリにて再検証しています。あわせてご覧くださいませ。 ベンチマークで利用した環境 [Server1] <=> [Gigabit Switching Hub] <=> [Server2] Server1 (HP ML115 G5) AMD Phenom 9950, 8GB, RAMディスク使用, Gigabit Ethernet Server2 (HP ML115 G1) AMD Opteron 1210, 4GB,

yubitterという携帯向けTwitterクライアントサービスで、ユーザーのアイコンを携帯電話向けに変換している(※1)、いわゆる画像変換サーバーのhttpd部分をApacheからnginxへ変更しました。 処理は単純に以下の流れです。 クライアントからアイコン画像のリクエストが来る 既にハードディスクにキャッシュファイルがある場合は、それをそのまま返す ファイルがない場合は、PHPプログラムがアイコン画像がアップロードされているTwitterのサーバー（現在はAmazon S3/CloudFront）へ取りに行く PHPプログラムが取得した画像データをGDライブラリを利用して加工、ハードディスクに保存、レスポンスを返す 変換するにあたり、以下の2パターンを検討しました。 リプレイス案1は、Apacheのレイヤーを一つ下げてAPサーバーに専念してもらう案で、2案は、Apache+mod_

本のページをめくるように、どんなWebページも素早く表示できるようにする。グーグルは以前からWebの高速化に取り組んできました。 6月22日から、米サンタクララで行われていたWebサイトのパフォーマンスと運用に関するオライリーのイベント「Velocity 2010」では、グーグルのUrs Hölzle氏がWebの高速化技術について「Speed Matters」（スピードの重要性）というセッションで紹介ています。 Webを高速化するためにどのような技術があり、あるいはどのような技術が検討されているのか、このセッションの内容を紹介しましょう。 スピードは重要だ 私が話そうとしているのは、「Speed matters｣（スピードの重要性）についてだ。Webは空飛ぶジャガイモより速くなれるだろうか？ どのくらい速くなれるだろうか？ （参考：オペラがやってくれた！ グーグルの空飛ぶジャガイモに対抗）