2015年11月アーカイブ

メルカリのオフィスにて開催された 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自体を長く続けることはできません。過去の出題者として、問題作成のスケジュールの持ち方や出題チームでの役割分担、事前解答といった面で協力できるのではないかと思っています。

このアーカイブについて

このページには、2015年11月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2015年9月です。

次のアーカイブは2015年12月です。

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

ウェブページ

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