Real World Performance of gRPC - gRPC 利用による劇的なパフォーマンス改善 | Wantedly Engineer Blog
こんにちは、Wantedly の Infrastructure Team で Engineer をしている南（@south37）です。 先日は、「gRPC Internal」というタイトルで gRPC の設計と内部実装についてブログを書きました。 こんにちは、Wantedly の Infrastructure Team で Engineer をしている南（@south37 ）です。 今日は、WANTEDLY TECH BOOK 6 から「gRPC Internal」という章を抜粋して Blog にします。 「WANTEDLY TECH BOOK 1-7を一挙大公開」でも書いた通り、Wantedly では WANTEDLY TECH BOOK のうち最新版を除いた電子版を無料で配布する事にしました。Wantedly Engineer Blogでも過去 この gRPC ですが、Wantedly
遅すぎる日本のスマホサイトの原因を探る (1/4)
デジタル機器の利用動向で知られるコムスコアの調査によると、2011年12月時点の日本における携帯電話に占めるスマートフォンの割合は16.6%でしたが、2012年6月には23.5%になり、半年で約7ポイントも増加しました。「まだ4人に1人の割合じゃないか」と思う方もおられるでしょう。 しかし、有名な「キャズム理論」によれば、普及率がイノベーターとアーリーアダプターを合わせて16%を超えると、一般大衆が技術を受け入れます。2012年12月時点の普及率はまだわかりませんが、すでに半分を超えていてもおかしくありません。スマートフォン未対応の企業サイトは、「時代遅れ」といっても過言ではないのです。 日本のスマートフォンサイトの問題点 すでにスマートフォン対応を済ませた日本の企業サイトは「マーケットに素早く対応して流石だ！是非、お手本として見習おう」といえるでしょうか？ 先行してスマートフォンに対応し
kernel: TCP: time wait bucket table overflow の解消とTIME_WAITを減らすチューニング - 気ままにインフラエンジニア
整理がてら。 httpdが動いているあるホスト上で、 /var/log/messages に以下のようなメッセージが出ていた。 kernel: TCP: time wait bucket table overflow kernel: printk: 50078 messages suppressed. "netstat -tna |grep TIME_WAIT"すると、10万以上の数でTIME_WAITが出ている。これを解消するまでの流れ。 そもそもこの値は、カーネルパラメータの net.ipv4.tcp_max_tw_buckets で設定されている。デフォルトは16384。 （↑の通り、エラーが出た環境では既にかなり大きな値が設定されていたのだが。） /proc/sys/net/ipv4/tcp_max_tw_buckets システムが同時に保持する time-wait ソケットの最大
Iperfの使い方 - TECHNERD::INIT
ネットワークの帯域を計測する場合、非常に便利なツールです。 UNIX系ではnetperfが有名かと思いますが、UDPの計測に関してはIperfの方が使いやすいと思います。 WindowsやLinuxなど各種OSで使用できます。 ダウンロード NLANR/DAST : Iperf - The TCP/UDP Bandwidth Measurement Tool http://sourceforge.net/projects/iperf 使い方 下記に、コマンドの使い方を記しておきます。 ユニキャストモード TCPの場合 サーバー $ iperf -s クライアント $ iperf -c <受信側ホスト名> または <受信側IPアドレス> 例1)TCP通信での最大レートを測定する。Netperfでの測定とほぼ同様。 $ iperf -c 192.168.1.100 例2)100Mbyteのデー
高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋
はじめに アクセスが急増すると、応答時間が著しく悪化するサイトはありませんか？ 普段は200ミリ秒以内で安定してアクセスをさばいているのに、イベントやらキャンペーンやらを開始した瞬間から、普段の２倍や３倍のアクセスが殺到し、その結果、レスポンスタイムが3秒とか9秒とかかかるようになってしまうことってありますよね。 あるサイトの実状 つい先日まで、そんなサイトが私の目の前にもありました。自社で運営している某ソーシャル系のサイトなんですが、イベント開始時刻と同時にアクセス数が急増するのです。とはいえ、所詮は普段の2倍とか3倍程度の数なのだから、少なくとも1秒以内にレスポンスを返せるくらいの性能は維持したいものです。 しかし実際は困ったことに、応答に3秒以上もかかってしまう処理が大量に発生してしまう状況に陥ってしまっていました。これはきっと、どこかにボトルネックがあるに違いありません。 仮説を立
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
