“SRE”がテーマで2016/03/12に開催されたRetty Tech Cafe #5 で「メルカリにおける、継続的なアプリケーション改善を支える技術」という発表をしてきました。

私の発表資料はspeckerdeckにて公開しました。


デプロイや監視まわりでメルカリのSREがやっていることをまとめてみました。参考になれば幸いです。

元GoogleのSREであるRettyのCTO、樽石さんの発表では、SREが目標とする指標について簡潔にまとめられていて、とても参考になりました。自動化やクラウドが提供するサービスが中心となりやすいインフラとはちょっと違う切り口で、アプリケーションのパフォーマンスやサービスの信頼性を確保する方法、その考え方について短い時間でしたが情報交換できました。ありがとうございましたー。

SREの活動についてもっと喋れる場があるといいなー。

書いてなかった。

RubyKaigiに初参加して高速Rackサーバの Rhebok について喋ってきました。

内容は

  • Rhebokの概要
  • Hot Deployの仕組み
  • ベンチマーク
  • rackの基本
  • 高速なRackサーバの作り方とRhebokで使っている技術
    • prefork_engine による prefork
    • io timeout の戦略
    • PicoHTTPParser による高速なHTTP処理
    • TCPの最適化

となります。わりと盛りだくさんに喋りました。

Rhebokはもちろん、アーキテクチャや使っている技術にも興味をもって貰えたらうれしいです。YAPC::Asia 2013でMonocerosについて喋ったときの資料を一部使っているのはここだけの秘密

RubyKaigiのスタッフの皆さん、通訳の方、参加者の皆さんありがとうございました。金曜日土曜日と帰るのが遅くなったので家族にも感謝。

メルカリのオフィスにて開催された PHP BLT#1 でLTしてきました。

PHPの勉強会なので、いままでお会いしたことのない方とお話ができてよかったです。

発表内容は大きくなってしまったmaster.phpファイルをどうやって高速に読むかというお話です。PHPではリクエストの終了とともに全てのメモリを捨ててしまうので、変わらないデータもリクエストの度にキャッシュからロードしなくてはいけません。大きなphpファイルがあれば当然毎回の読み込みがオーバーヘッドとなってきます。そんな環境でどうやってアプリケーションのパフォーマンスをあげていったのかを紹介しています。

スライドの中でfile sizeを小さくする必要があると書きましたが、@hnwさんによると、VM命令が多過ぎるのが問題で、構造を簡単にしたことでVM命令が減ったのがよかったのではとのことでした。非常に参考になりました。ありがとうございました

そろそろ傷が癒えてきた。。

ISUCON5の本選にメルカリのインフラ改めSite Reliability Engineerで結成したチーム「GoBold」で参加して、最も速く決められた得点に到達したチームに与えられる特別賞と最終的に3位となりました。チームメンバーは @cubicdaiya、@shmorimo、@kazeburo の3人です

出題のtagomorisさん、kamipoさん、運営の941さん、LINEの皆様、テコラスの皆様ありがとうございました。

ソースコードとやったこと。

こちらにて公開しています

https://github.com/kazeburo/isucon5-final-public

構成は、Nignx + Perl + PostgreSQL + memcachedです。

課題となったサイトは、データベースに格納してある情報からいくつかのAPIに問い合わせて、その結果をまとめてクライアントに返すというもの。流行のマイクロサービスを間違った形で実装したものということでした。題材としてはかなり面白いものでした。

最初にアプリケーションの動作やコードを確認し、3人でどのような実装方法にするか、落書き帳に雑に書きながら相談しました。

Slack for iOS Upload-4.jpg

方針としては

  • 与えられた3台で動作するように変更
  • cache時間の調整は必要になるだろうが、APIの問い合わせを全てmemcachedにcache
  • cacheはDBを変更するタイミングで行う
  • PostgreSQLへの問い合わせを出来る限り減らしていく

という感じです。

やった事と時系列を整理してみる

 11:09:59 106211:23:09 1116 < rubyの初期スコア 11:53:25 84 FAIL: 11:58:22 2595 < perlの初期スコア 12:00:45 84 FAIL: 12:08:24 84 FAIL: 12:11:57 2817 12:17:50 2566 12:29:32 2700 12:35:46 10268 < ここで3台で動かす事に成功。usersとsubscriptionがmemcachedに 12:41:46 10274 12:52:32 0 FAIL: < このあたりはapiのcacheとuserのcacheを実装 12:52:46 0 FAIL: 12:58:55 10310 13:04:14 0 FAIL: < end_pointのcacheの実装 13:05:30 0 FAIL: 13:10:16 0 FAIL: 13:13:39 10291 13:16:32 65 FAIL: < ログイン周りもmemcachedに 13:37:11 10292 13:39:28 10732 13:42:13 0 FAIL: 13:46:49 90068 < apiのcacheが完成 13:49:06 0 FAIL: 13:55:56 40 FAIL: 14:01:01 98672 14:11:22 0 FAIL: 14:14:00 70209 14:16:22 100058 < nginxのログを切って特別賞get 14:19:52 87753 14:22:37 93487 14:31:43 102180 14:38:34 0 FAIL: 14:39:55 0 FAIL: 14:42:07 84 FAIL: 14:47:22 84 FAIL: 14:49:51 75 FAIL: 14:54:16 0 FAIL: 14:55:51 84 FAIL: 15:01:34 109671 15:10:21 97975 FAIL: 15:13:12 108082 < ここら辺でtenkiのcacheを1秒に 15:16:17 99331 15:17:29 80 FAIL: 15:23:16 100742 15:28:36 99526 15:32:58 103129 15:40:24 89299 FAIL: 15:45:53 0 FAIL: 15:49:46 38564 FAIL: 1秒に。keepaliveもやめる 17:41:45 86611 17:47:03 65252 < tenkiのcacheを3秒に 17:49:59 74 FAIL: 17:51:41 84084 17:54:44 80924 17:58:35 65422 

特別賞以降は何をしてもダメでした。自分たちの作ったbugだったり、ベンチマーカの挙動が変わったり、再現しないエラーが発生したり、初期チェックの段階でのAPIの問い合わせエラーが発生したりとかなり右往左往してしまいました。正直1回通ったベンチマーカの挙動は変えないで欲しいなと。。

ベンチマーカの競技中での動作変更や自分たちが感じたAPIサーバの不安定さは、事前解答など、出題側でのQuality確保の時間ががあれば、ある程度回避できたのではないでしょうか。ISUCONの準備には多くの時間がかかり、通常業務への影響も少なからずありますが、それでもデスマーチが前提ではISUCON自体を長く続けることはできません。過去の出題者として、問題作成のスケジュールの持ち方や出題チームでの役割分担、事前解答といった面で協力できるのではないかと思っています。

ISUCON5 の予選にメルカリのインフラ系エンジニアで結成したチーム「GoBold」で参加して、無事2位で通過しました。チームのメンバーは、@cubicdaiya、@shmorimo、@kazeburoの3人で、普段から横にならんで座って、メルカリのパフォーマンス改善やサーバ環境の整備に携わっています。

今回の予選問題、ずいぶん盛ってきたなーというのが最初の印象。モリスさんも予選問題を本選のようにしたいと言っていたし、その通りになっていました。マシンの性能に対しての扱うデータ量もメモリに乗り切らないであろうスレスレのラインでkamipoさんの調整も神だなと思いました。おかげでやることが満載だし、素晴らしい問題でした。運営の941さんも含め本当にお疲れさまでした。本選もよろしくお願いします。

チームのメンバーのblog

ISUCON5予選 2位で通過しました - 考える人、コードを書く人

やったこと

最終的なソースコードといくつかの設定はgithubで公開しました

https://github.com/kazeburo/isucon5-elimination-public

構成は、Nignx + Perl + MySQL + memcachedです。PHPは使ってないです。はい

課題となったサイトは、ISUxiというSNSサイト、日記、日記のコメント、足跡、そしてhome.plのようなトップ画面。元m社のたんぽぽチームとアプリ運用チームの2人いるチームとしては負けてはならない課題でした。結果はfujiwara組に負けましたが。。あーくやし

やったこととスコアを時系列に整理してみると、こんな感じ。全部で72回ベンチマークを実行。

 time score 11:22:12 52 <rubyの初期スコア 11:43:41 557 <perlの初期スコア 12:30:23 818 12:55:18 1121 <userのrequest単位のcache、パスワードのhashの計算をperlで行うように 13:05:18 0 13:08:44 0 13:18:33 0 13:22:56 19 13:25:04 0 13:26:37 794 <ようやくsuccess 13:30:04 882 13:34:47 1191 13:37:15 1191 13:41:08 1223 13:43:06 1198 13:46:40 0 13:48:00 0 13:52:11 916 13:54:03 19 13:55:23 19 13:59:30 1883 <is_friendsがmemcachedとなる, commentsテーブルにentry_user_idカラムを追加 14:02:33 0 14:04:29 1967 14:07:46 1926 14:10:31 1947 14:22:49 4 14:26:09 2144 <userをin memory化 14:29:41 2137 14:38:35 20 14:41:18 2160 14:48:39 1088 <enqueueが2つされる 14:48:39 1117 14:51:26 2182 15:06:01 17 15:13:24 2026 15:18:41 4277 <comments_of_friendsのクエリ改善と足跡の集計をperlで行うように 15:23:25 4305 15:25:50 4242 15:29:41 4372 15:32:21 4376 15:36:00 7134 <relationsのクエリからOR anotherを削除 15:40:29 0 15:44:02 8166 <comments_of_friendsのクエリ改善。limit 1000がなくなる 15:49:47 18439 <entries_of_friends,comments_of_friendsのクエリ改善、relationsをつかう 15:53:24 18873 15:56:05 18561 16:00:03 18167 16:07:13 19525 16:11:47 22126 <nginxのoptimize、unix domain socketを使ったり 16:18:35 21333 16:22:58 21378 16:28:49 18497 <再起動。このあたりから再起動とwarmupの試験 16:45:34 16823 16:51:06 0 17:06:42 17623 17:10:21 19950 17:13:38 20102 17:28:07 18107 17:37:25 17 17:44:09 16217 17:49:53 14297 17:55:28 1571 <友達のいないユーザからのアクセスでエラー多発 18:00:17 0 18:17:52 0 18:20:51 21243 < warmupをcatで行うようになって再起動後もスコア安定 18:27:54 21622  18:30:27 22719 18:34:52 22845 18:39:46 23553 <comments_of_friends limitの調整 18:46:30 24118 18:53:47 26300 < comment数のN+1を改善 19:00:00 25861 < 最後の再起動試験 

MySQLのクエリ数が多いので、そこを減らすことから取りかかり、relationsのmemcached化とuserのin memory化を先に進め、その後に比較的重いクエリをひとつひとつ解決していきました。fujiwara組と逆かも。

アプリケーションのコード変更は3人で話し合い、次に解決する課題を整理し @shmorimo と自分とで分担して作業を行っていきました。直接masterにpushしていたけど、p-rベースにしてコードの確認をやっていた方が手戻りが少なかったかなと思う。

MySQLの設定とwarmup

今回のデータは3GB近くあり、それに対してサーバのメモリが3.5GB、HDDはSSDではなく超遅いというのが特徴。そこで再起動試験で安定したスコアを出そうしたら、warmupが重要になる(ならなかったけど)ということで、いくつか工夫をしました。

my.cnfは以下

 innodb_buffer_pool_size = 800M innodb_flush_log_at_trx_commit = 0 innodb_flush_method=nosync innodb_doublewrite = 0 

bufferpoolを減らして、ODIRECTは使っていません。innodbのbuffer_poolだけに頼るのではなくdisk cacheで行う戦略をとりました。まるでMyISAMのようですね。

そしてアプリケーションの起動スクリプトには

 /bin/cat /var/lib/mysql/isucon5q/*.ibd > /dev/null exec /home/isucon/.local/perl/bin/carton exec -- start_server --path /tmp/app.sock --backlog 16384 -- plackup -s Gazelle --workers=10 --max-reqs-per-child 500000 --min-reqs-per-child 400000 -E production -a app.psgi 

のように書いて、メモリに乗っけてからアプリケーションを起動するようにしました。おかげでアプリケーションサーバさえ起動していれば満足のいくスコアがでるようになっています。

反省

22000がでたところで、安心してしまいGo Boldに行かなかったところが反省。アプリケーションを変更するプロセスもよくしていって、本選は(fujiwara組に)勝ちたい。

kamipoさんOracle ACEおめでとうございます。

MyNA(MySQLユーザ会)会 2015年8月 でメルカリのデータベース戦略とPHPについて喋って来たので、資料を公開します。

内容はWEB+DB PRESS Vol.88の記事に書いたこと+新ネタと、PHP(PDO)の話です。MySQL 5.7のところにみなさん驚かれていたようです。

他の方の発表では、dimSTATが面白かったですね。あのグラフをどうやって作っているのか全くしらなかったので、勉強になりました。あれはベンチマークしたくなります。また、MySQLで困っている人をみつけて助けてあげようとするkamipoさんの情熱も、どこから沸いてくるのか不思議ですが、さすがでした。

開場のyoku0825さんありがとうございました。みなさまお疲れさまでした。

実は、この会で喋る事をすっかり忘れていて、YAPC::Asiaの懇親会の時に、yokuさんに「木曜日のタイトルお願いします」僕「え??ああ、あああああ!」という会話をして思い出しました。ほんとすみませんでした。いやぁ、YAPC::Asiaで1時間のトークをしたあと中4日で40分のトークの準備は大変でした..

YAPC::Asia Tokyo 2015で「ISUCONの勝ち方」という発表をしてきました。

技術的な内容も後半にありますが、ISUCONがどうして始まったのか、ISUCONで良い成績をだすためにはどんな準備をして、チューニングのためにどんなことを考え、調査するのが良いのかについて喋ってきました。

発表が2日目の朝イチでしたが、多くの方にきて頂き、ありがとうございます。この発表でISUCONになるべく多くの方に興味を持って頂き、参加する方が増えればいいなと思ってます。

今年のISUCONの参加者募集はすでに始まってます。

ISUCON5 オンライン予選の参加登録を開始&参加チームとメンバーリスト : ISUCON公式Blog

ぜひ、ご応募ください。私はメルカリのインフラチームのエンジニアと共に出場します。よろしくお願いします。

Lightning Talk

@uzulla氏がPHPの話を所望されていたので、PHPのエラーログ周りを整理しつつNorikraの話をしました

1日目にLightning Talkができると、自分のセッションの宣伝ができるので良い

さいごのYAPC::Asia Tokyo

最高のYAPC::Asiaでした。牧さん、スタッフの皆様ありがとうございました!おつかれさまでした。 再来年(?)にまた会える事を楽しみにしています。

IMG_3757.jpg

奥さんと息子、娘が応援に来てくれたので、息子とホールの壇上でパシャリ。いつもありがとう。

久しぶりに喋ってきました。Mackerel meetup #4Shibuya.pm Tech Talk #17ではLTを、Norikra meetup #2では少し長めの話をさせて頂きました。

資料3つ貼っておきます。

メルカリでもサーバ・運用周りの仕事をしています。メルカリではzから始まるモニタリングツールをメインに使用していて、サーバ周りのさまざまなデータを突っ込んで監視に役立てていますが、カジュアルにグラフをつくって、アラートを仕掛けるという用途には向いていないなぁと思ってます。

そこで、Norikra と Mackerelを組み合わせて柔軟にログの可視化+閾値の設定を行うってのを思いついて設定したところ、結構うまく行って、それについてtwitterでつぶやいていたところ、今回のような機会を頂いたというわけです。

harukasanのログ解析ツールのまとめは非常にわかりやすく、fujiwaraさんの使い方はさすがでしたし、Gunosyの2段Norikraは目から鱗でした。みなさまありがとうございました。参考にさせて頂きます。

久々に開催されたShibuya.pmではyokohama.pmぐらいでしか紹介していなかったGazelleについて喋ってきました。前日にc4.8xlargeでベンチマークを行ったらすごい数字がでたのでびっくりした。livedoorBlogでまだ動いているようだし、安定していると思うので、ぜひ使って頂けたらと思います。

同僚のbokko氏のNginxのチューニングもよくまとまっていたし、kazuhoさんのHTTP/2の優先度制御も具体例があって参考になりました。弊社だとスマホアプリのバックエンドのAPIが中心になる訳だけど、API毎の優先度の制御とかできるのかなぁと考えてみたりしました。LTではひさびさにPerlの話がいっぱい聞けて、楽しかったです。みなさまありがとうございました。

最後に、YAPC::Asia Tokyo 2015に、「ISUCONの勝ち方」というトークを応募しています。今年も開催されることが発表され、多くの注目が集まっています。ご興味をもった方はぜひブックマークやtweet、いいねなどをして頂けるとうれしいです。

http://yapcasia.org/2015/talk/show/86ebd212-fab3-11e4-8f5a-8ab37d574c3a

1000万ダウンロードと会社の2周年という記念の日に入社しました。

iOS、Androidアプリのダウンロード数はもちろん、商品の出品数や流通額も大幅に伸びています。また、アメリカでの展開等も進んでいるので、サーバ・フロントのエンジニアを募集しています。ご興味のある方はぜひご連絡くださいませ。

3月には六本木ヒルズへのオフィス引越も予定されています。mixi入社前にlivedoorのセミナーでヒルズへ行ってから9年。ここに通うことになるとは思いもしませんでした。

今後の仕事

仕事は変わらずサーバ周りの運用・パフォーマンス改善、スケーラビリティの向上です。モニタリングツールの整備を足がかりにMySQL周りの最適化や可用性向上を行い、PHPのアプリケーションのチューニングなどに携わって行きたいなと考えております。

何よりも自分たちの選択した技術で、ユーザに信頼性の高いサービスを提供できるよう努力して参ります。引き続き、多くの皆様のお世話になると思いますので、よろしくお願いします。

ウィッシュリスト置いておきますね

去年から今年にかけて高速なPSGIサーバとRackサーバを作り、そしてPHPの会社に入ったということで、YAPC::Asia Tokyo、Ruby Kaigi、PHP カンファレンスの3つで喋ることが今年の目標です。

wrkに無理矢理なpatchをあてて、unix domain socket経由でHTTPサーバをベンチマークできるようにしてみました。

pullreqはしてない。

GazelleやRhebokといったアプリケーションサーバを作っていますが、TCP経由のベンチマークではEphemeral Portの枯渇やTIME WAITの上限にあたってしまい、ベンチマークがしづらいという問題があります。

そこでnginxをreverse proxyとして設置し、nginxとアプリケーションサーバ間をunix domain socketで繋いでベンチマークをとっていましたが、nginxがボトルネックになりやすく、直接アクセスしたいなと考えていたので、やってみました。

これを使ってRhebokとUnicornの “Hello World” ベンチマークを行ったところ、unix domain socketのベンチマーク結果はTCPに比べて、Rhebokで5倍、Unicornで3倍高速という数字がでました。

rhebok_tcp_unix.png

Rhebokは最新版でHTTP/1.1のサーバとなり、デフォルトでTransfer-Encoding: chunkedを使います。Unicornはchunked transferを行わないので、機能的にあわせるためrack middlewareを導入しているのが上記のグラフの「Unicorn + Chunked」です。

このベンチマーク結果をみると、やはりTCPの新規コネクションのコストは大きく、TCPの都度接続は避け、できるだけコネクションを使い回すか、unix domain socketの使用したいと思うでしょう。

ただ、Reverse Proxyとアプリケーションサーバ、もしくはクライアントとアプリケーションサーバ間のTCP接続をkeepaliveする場合、保持すべき接続数のチューニングが難しくなりがちなので、自分としてはお勧めしません。クライアントとのTCP接続の維持をReverse Proxyで行い、アプリケーションサーバ間との接続はunix domain socketを使うのがよいのでしょう。もちろん、両者が同じホスト上で動作していないと使えませんが。。

使い方

まずブランチ指定してcloneしてきて、make

$ git clone -b unixdomain https://github.com/kazeburo/wrk.git $ cd wrk $ make 

-P オプションでパスを指定します。

$ ./wrk -t 1 -c 30 -d 30 -P /tmp/app.sock http://localhost/benchmark 

簡単ですね

RhebokとUnicornのベンチマーク

ベンチマークはEC2のc3.4xlargeを使いました。コア数は16です。OSはAmazon Linuxです。

以下のカーネルチューニングをしました

$ sudo sysctl -w net.core.netdev_max_backlog=8192 $ sudo sysctl -w net.core.somaxconn=32768 $ sudo sysctl -w net.ipv4.tcp_tw_recycle=1 

一番下はTCPのポート枯渇対策です。ただTCPのベンチマークはどれもtimeoutのエラーが出てしまっています。

Rubyはxbuildを使って2.1.0をインストール

$git clone https://github.com/tagomoris/xbuild.git $ ./xbuild/ruby-install 2.1.5 ~/local/ruby-2.1 $ export PATH=/home/ec2-user/local/ruby-2.1/bin:$PATH $ gem install rhebok unicorn 

アプリケーションサーバのワーカー数は8とし、wrkはスレッド6個、同時接続数600で実行しました。

アプリケーションはconfig.ruに直接書いている

$ cat config.ru class HelloApp def call(env) [ 200, {}, ["hello world\n"] ] end end run HelloApp.new # run Rack::Chunked.new(HelloApp.new) 

unicornの設定はこちら

$ cat unicorn.rb worker_processes 8 preload_app true #listen "/dev/shm/app.sock", :backlog=>16384 listen 8080, :backlog=>36384 

Rhebok + unix domain socket

$ rackup -s Rhebok -O Path=/dev/shm/app.sock -O BackLog=16384 -E production -O MaxRequestPerChild=0 -O MaxWorkers=8 config.ru $ ./wrk -t 6 -c 600 -d 30 --timeout 60 -P /dev/shm/app.sock http://localhost:8080/ Running 30s test @ http://localhost:8080/ 6 threads and 600 connections Thread Stats Avg Stdev Max +/- Stdev Latency 1.73ms 244.96us 6.62ms 81.28% Req/Sec 57.64k 4.04k 66.56k 69.06% 9762337 requests in 30.00s, 1.28GB read Requests/sec: 325426.21 Transfer/sec: 43.76MB 

Rhebok + TCP

$ rackup -s Rhebok -O Port=8080 -O BackLog=16384 -E production -O MaxRequestPerChild=0 -O MaxWorkers=8 config.ru $ ./wrk -t 6 -c 600 -d 30 --timeout 60 http://localhost:8080/ Running 30s test @ http://localhost:8080/ 6 threads and 600 connections Thread Stats Avg Stdev Max +/- Stdev Latency 36.02ms 194.43ms 1.83s 97.66% Req/Sec 11.87k 2.20k 21.89k 89.91% 2021671 requests in 30.00s, 271.85MB read Socket errors: connect 0, read 0, write 0, timeout 56 Requests/sec: 67392.13 Transfer/sec: 9.06MB 

Unicorn + unix domain socket

$ unicorn -c unicorn.rb -E production config.ru TCP $ ./wrk -t 6 -c 600 -d 30 --timeout 60 -P /dev/shm/app.sock http://localhost:8080/ Running 30s test @ http://localhost:8080/ 6 threads and 600 connections Thread Stats Avg Stdev Max +/- Stdev Latency 3.21ms 170.17us 11.49ms 88.06% Req/Sec 32.71k 2.04k 43.67k 65.95% 5534941 requests in 30.00s, 543.69MB read Requests/sec: 184506.07 Transfer/sec: 18.12MB 

Unicorn + TCP

$ unicorn -c unicorn.rb -E production config.ru TCP $ ./wrk -t 6 -c 600 -d 30 --timeout 60 http://localhost:8080/ Running 30s test @ http://localhost:8080/ 6 threads and 600 connections Thread Stats Avg Stdev Max +/- Stdev Latency 33.58ms 179.94ms 1.75s 97.80% Req/Sec 11.01k 2.04k 22.00k 89.73% 1873600 requests in 30.00s, 184.04MB read Socket errors: connect 0, read 0, write 0, timeout 49 Requests/sec: 62455.78 Transfer/sec: 6.13MB 

Unicorn + chunked + unix domain socket

$ unicorn -c unicorn.rb -E production chunked.ru unix $ ./wrk -t 6 -c 600 -d 30 --timeout 60 -P /dev/shm/app.sock http://localhost:8080/ Running 30s test @ http://localhost:8080/ 6 threads and 600 connections Thread Stats Avg Stdev Max +/- Stdev Latency 5.24ms 265.60us 13.67ms 77.33% Req/Sec 19.76k 1.79k 26.00k 68.71% 3404283 requests in 30.00s, 457.77MB read Requests/sec: 113481.40 Transfer/sec: 15.26MB 

Unicorn + chunked + TCP

$ unicorn -c unicorn.rb -E production chunked.ru tcp $ ./wrk -t 6 -c 600 -d 30 --timeout 60 http://localhost:8080/ Running 30s test @ http://localhost:8080/ 6 threads and 600 connections Thread Stats Avg Stdev Max +/- Stdev Latency 555.60ms 1.10s 3.43s 81.56% Req/Sec 7.85k 5.05k 26.89k 65.28% 1339932 requests in 30.00s, 180.18MB read Socket errors: connect 0, read 0, write 0, timeout 29 Requests/sec: 44659.91 Transfer/sec: 6.01MB 

HTTP/1.1に対応したRhebok、Gazelleと共にお試しくださいませ。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

アイテム

  • Slack for iOS Upload-4.jpg
  • IMG_3757.jpg
  • rhebok_tcp_unix.png
  • rhebok.png
  • gazelle_bench.png
  • IMG_2745.jpg
  • IMG_2748.jpg
  • benchui.png
  • gf_hook_gh.png
  • gf_gh_trigger.png

ウェブページ

OpenID対応しています OpenIDについて
Powered by Movable Type 4.27-ja