Tsuyoshin blog

所属団体とは関係なく、個人的なblog

Googleデータスタジオを使って見てBIツールについて考えた

はじめに

下記の記事でちょっと触れてて現状の業務に少し導入してみた。

tsuyoshi-nakamura.hatenablog.com

数日後、下記のニュースが出てヨッシャー無料で使いまくれるじゃないかと思ってもっと業務に取り入れてやってみた analytics-ja.googleblog.com

ほとんど数値は隠してますが、下記のような感じで使ってました

example

1

f:id:tsuyoshi_nakamura:20170226180023p:plain

2

f:id:tsuyoshi_nakamura:20170226180037p:plain

3

f:id:tsuyoshi_nakamura:20170226180047p:plain

このあたりのBIツールに関して思うこと

世の中にはBIツール系はたくさんありますが、今の業務と照らし合わせて考えてみる。

現在PCとスマホのブラウザ版でのサービスを提供している状況で考えるとwebのアクセスログが一番重要だったりする。

UIを改善してみたり、Designを変えてみたり、メルマガのセグメントを変えて見たりという日々の改善の効果測定はGoogle Analyticsから取るデータが一番指標になる。

そのアクセスログ系のデータとDBなどにストアしているデータをかけ合わせて数値を追える事が一番重要だなと感じてる

そういった視点で考えると繋ぎこむ事ができるデータソースにGoogle Analyticsがある事が重要だなーと思っている。

以上を踏まえて最近のBIツールを見てみる

Re:dash

  • 直接Google Analyticsには繋ぎこむ事は出来ない
    • Google AnalyticsのデータAPIで取得して一度Spreadsheetに落としてから活用する感じになる
  • OSSでの提供なので自身が管理するネットワーク内のサーバにインストールして内部のDBに対してSQL投げてデータが取れる

Amazon QuickSight

  • 直接Google Analyticsには繋ぎこむ事は出来ない
  • 主にAWS内にあるデータに対して簡単に分析が出来るのが特徴
    • RDS,RedShift,S3,Kinesis,EMRとかこの辺に色々データが溜まってると非常に便利だと思う

Tableau

  • 直接Google Analyticsに接続出来る様子
  • もちろんMYSQLなどのデータにもつなげてSQLを投げれる

Google Data Studio

  • 直接Google Analyticsに接続出来る
  • ただDBへの接続が出来るけど、セキュリティ周りの設定項目があまり出てこなかったのでちょっと心配

まとめ

  • Tableauは周りでの評価も高いし、一番良いんだろうなと感じてる。セキュリティ周りも少し調べた感じだとしっかり考慮されてる感あったし、安心して使えそう
    • ただ当然有料
  • Google Data Studioは無料で使えてGoogle Analyticsのデータも自由に使えるので👍だと思ってる
  • いきなりお金のかかるツールの導入って決済者目線で言うとちょっとok出しづらいと思ってる
    • 使ってみたいと思う人も本当に活用しきれるか不安でもあるし、失敗した時の事考えるとちょっと止めとこうっと思ったりする
    • 無料のもので出来る事はたくさんあって、まづはそこで活用してみて、もっとこういう情報を分析する必要があって、その分析が進むとこういった施策が打てて….といった所まで使い込んで見るとよいと思う
    • そうすると本当に自分たちのチームにとって必要なツールで必要な投資かどうか自信を持って言えると思う
    • 有料の額にもよる部分もあるけど、こういった思考、実際にやってみた後の評価・判断が出来る事が自体が良い経験だったりするし😁

xhprofとphp-quick-profilerを使って改善した話

対象のシステム

  • PHP
  • Fulephp使ってる
  • PHP-fpm使ってる
  • Nginx使ってる

はじめに

  • PHPを使っててPHP重いなーとかサーバのメモリ使いすぎだよなーとかいろんな不満を抱えていました
  • PHP自体はそこまで古くないのになーとかFWのversionも上げてるしなーとかざっくり思って見たり
  • でもPHPが本当に原因なのかなーっと疑問を感じながらずっと過ごしてた
  • チームの他のエンジニアがpmapを使ってプロセス (群) のメモリマッピングを表示してくれて、anonという匿名メモリー?へのメモリ割り当てが多く存在する事が分かった。
    • これPHP-fpmの再起動直後と数日間運用してからもう一度計測したりして見比べるとやっぱりPHP側で色々とメモリ使ってるんだろうなーっという感じ
    • Newrelicとかでの指摘は合ってたのかと思ったり

んーこれは少々ばかりDeep Driveして向き合わねばならん

まずは調査

Newrelicを使ってるんですが、契約のplanとNewrelic側の対応FWでfulephpが非対応になってて、詳細が分からずという状態だったので別の解析ツールが必要だったので色々ググった

ただ、一つのツールだけではちょっと分かりづらく、結局下記の2つのツールを活用することがよさげと思って試した

その他

調査結果~考案

自分のローカルマシンで調査しました

一応色々数値自体は隠しておきます。🙇🏽

php-quick-profiler

f:id:tsuyoshi_nakamura:20170214111003p:plain

  • どの画面でprofilingしてもMemory Usedが高い😨
  • アクセスをさばく時に毎度通るロジックの部分が怪しいと分かった

xhprofのグラフから

  • 一番ボトルネックになってる箇所を見つけた。下記グラフの赤くなってる箇所 f:id:tsuyoshi_nakamura:20170214111014p:plain

    • でもここFWのcore部分で手つけづらい…😨
    • その手前の赤マルで記した部分がアクセスの度に必ず通過するメソッドで黄色くなって指摘されてた
      • ここに改善の余地があるのではないかと考えた🤔

xhprofの表から

f:id:tsuyoshi_nakamura:20170214111023p:plain

EWall%でソートして表示しています

項目

  • Calls… 呼びされて回数
  • Incl Wall Time … その関数全体の処理時間
  • IWall% … 全体の実行時間に対する割合
  • Excl Wall Time … その関数から呼ばれた関数の実行時間を除外した、関数の純粋な処理時間
  • EWall% … 全体の実行時間に対する割合(関数の純粋な処理時間 version)

赤で囲った部分はExcl Wallの%で、わりと高いと指摘されてる。且つ手の入れやすい部分。アクセスがある度に動くロジックの部分でもある。

xhprofのグラフの赤マルで囲ったfunctionだった🙄

こいつを改善できれば良いんじゃないかと思った🤔

それより上位はPHPのネイティブ関数の部分だったり、そのPHPのネイティブ関数をFWのcoreクラスで使ってたりでちょっと深い部分。

ここを改修となると影響範囲が大きいのでちょっと一旦パス。

以上を踏まえて主な対策方針

  • アクセスされる度に動く共通のロジックの部分を見直した方が効果が高いのでやろう
  • いきなりFWのCore部分に手をいれるとそれなりのリスクがあるので、Coreから切り離せる部分がまずは良いだろう

対策した内容

  1. アクセスがある度に毎回動くクラスAがfuelphpAutoloaderに設定されていて、クラスAはCoreクラスをextendしていたが、extendを止めた
    • xhprofの表の赤で囲ったfunctionです
    • なぜかと言うと
    • 親クラスのメソッドを全く使っていなかったので必要無いだろうと
    • fuelphpの仕様でAutoloaderで設定されてるクラスを辿り、_initメソッドが存在した場合はそれを動作させるみたい。つまり、クラスAの親クラスの_initメソッドが毎回動いていた
      • 無駄な処理で且つ、中身を見ると結構重そうな処理だった…😰
  2. preg_match関数じゃなくても良い部分はstrposに置き換えた

    • 下記の公式に書いてるようにstrposで置き換え可能な場合は置き換えた方が早くなるよって
    • PHP: preg_match - Manual

      Tip Do not use preg_match() if you only want to check if one string is contained in another string. Use strpos() instead as it will be faster.

  3. cookieを活用してpreg_matchの判定する場面を減らした

    • どうしてもpreg_matchを使わなければ行けない部分はあって、cookieを活用することで効率的に処理するようにした

対策してみた結果

Newrelic

f:id:tsuyoshi_nakamura:20170214113344p:plain

😀

Latency

f:id:tsuyoshi_nakamura:20170214113356p:plain

😀

CPUの数値

f:id:tsuyoshi_nakamura:20170214113432p:plain

😀

LoadAverage

f:id:tsuyoshi_nakamura:20170214113425p:plain

😀

もちろん

xhprof,php-quick-profilerの数値も改善が見られました😀

まとめ

  • 施策を3つほどやりましたが、結局はアクセスがある度に毎回動くクラスAのチューニングが一番効果が高かった🙌
  • xhprofで指摘された処理の中で一番遅く時間が掛かってるものをチューニングしたのが良かった(FWのcoreを除外して) 😀
    • あえてcore部分を一度除外したことで影響範囲も限定されるし、リードタイム短くリリースまでいける❗❗何気にここ良かったと思ってる😀
  • やっぱり時間を取って絶対改善するという心意気重要💪🏽
  • 思ったよりもいろんな数値の改善が見られたのでインスタンスのタイプ一つ下げれるなぁーと思った
    • このシステムが動いているサーバは4台あるので削減できる金額も結構でかく見えると思われる💰
  • やった事はそんなに難しい事ではないので早くやればよかったという結果論😅
  • どんどん改善していきましょー🚀

memcached1.4系、redis2系、redis3系でHTTPレスポンスのベンチマークまとめ

はじめに

そもそもVarnishも検討した方は良いよという話はあるんですが、AWSでELBとか使ってたりすると中々構成がムズいなぁーと考えていて、まぁ別エントリーで詳しく書く事にして…今回はmemcached1.4系、redis2系、redis3系でHTTPレスポンスの性能比較をしたのでまとめておく

検証した構成

f:id:tsuyoshi_nakamura:20170206190503j:plain

利用module

Nginx to Memcached

Module ngx_http_memcached_module

Nginx to Redis

HTTP Redis | NGINX

Nginx version

nginx version: nginx/1.10.1

負荷内容

GitHub - wg/wrk: Modern HTTP benchmarking tool

を使って、2スレッドから50接続でアクセス,2スレッドから100接続でアクセス,3スレッドから100接続でアクセスと3パターンの負荷をかけて計測した

ベンチマーク結果

Requests/sec

f:id:tsuyoshi_nakamura:20170206191234p:plain

  • Memcached1.4系とRedis2系ではMemcached1.4系のがより多くアクセスを捌ける
  • だけどMemcached1.4系とRedis3系ではRedis3系の方がより多くのアクセスを捌ける
  • 負荷が高い時により顕著に現れる

Latency

f:id:tsuyoshi_nakamura:20170206191236p:plain

  • そんなに大差は無いけどRedis3系のがLatencyが小さい

その他

まとめ

  • 結果から言うとRedis3系を使った方が良さそう😁
    • パフォーマンス結果も😀
    • 可用性も😀
  • 後はAWSのメンテナンスウィンドウ時の対応や監視のCloudWatchの設定等々を見ておけば良いんじゃなかろうか…

キャッシュ戦略を考えた

はじめ

もっともっとキャッシュをうまく活用することでよりスケーラブルに、よりレスポンシブにしたいなーと考えていて幾つかのパターンを考えたのでまとめておこうと思う

キャッシュといえども広義になってしまうけどここではhtml全体をキャッシュさせてレスポンスさせるキャッシュを指して書きます

設計する上のでポイント

  • ユーザ毎の情報をいかにキャッシュから返すか
    • staticなデータはまぁ良いとしてユーザ毎のデータのキャッシュはしくると情報漏えいとなってしまい大事故になるので慎重に!!
  • キャッシュをさせたくないデータ(ex:ECサイトだったら在庫数とか)をどう扱うか

考えたパターン

varnishを活用した場合

f:id:tsuyoshi_nakamura:20170117142512j:plain

説明

  • varnishはpostやget、urlによってキャッシュするしないという設定が柔軟で😃
  • varnishの設定によりキャッシュさせるページ=データを設定する
  • 図の流れのように順番に上からアクセスをさばくが、varnishの部分でキャッシュが存在していればそこからレスポンスされる
  • なのでキャッシュがあればELB→Nginx→Varnishだけでレスポンスをする
  • ESI(Edge Side Includes)とvcl-hashingの機能を使えばユーザ毎のデータも部分的にキャッシュ可能で効率的にキャッシュできる😃
  • キャッシュのクリアは特定のIPからのcurlでrefreshする仕組みを作り、必要に応じてcurlする

Memcachedを活用した場合

f:id:tsuyoshi_nakamura:20170117143659j:plain

説明

  • まぁ手軽😃
  • ngx_http_memcached_moduleを活用してキャッシュが存在すればレスポンスするようになる
  • ngx_http_memcached_module自体にはキャッシュさせる仕組みは無く、どのページ、どのデータをキャッシュさせるかはバックエンド=PHP側で行い、ngx_http_memcached_moduleはキャッシュがあればそのデータをレスポンスをする
  • ただVarnishのようにユーザ毎のデータのキャッシュを作ってそれぞれにレスポンスする仕組みは整っておらず、ちょっと厳しい😂
  • キャッシュのクリアはバックエンドからkeyを特定してmemcachedのデータをdeleteする

AWS CloudFrontを活用した場合

f:id:tsuyoshi_nakamura:20170117153331j:plain

説明

  • 前の2つとはちょっと毛色がかわる
  • AWS CloudFrontを活用する
  • Nginxで特定のURLの場合にリバースプロキシ設定でCloudFrontへ飛ばす
  • CloudFrontのoriginにはバックエンドのサーバを指定してhtmlのキャッシュを作り、CDN配信する
  • ユーザ毎に必要なデータはすべてAPI経由で配信する
    • Cookieからユーザを特定してjsonで返却するイメージ
    • APIのコール元は自社で提供しているアプリ(ブラウザ)なのでCookieからユーザ特定は問題ないのでは無いかと思っている(セキュリティ的に)
    • Authorization: Bearer ヘッダあたりを使えば良いんじゃないかなぁー
      • このへんもっと調べる必要あり...
  • キャッシュのクリアはそもそもAPIから都度配信しているので考慮不要

最後

Nginx with Goのパフォーマンスを検証した

はじめに

そろそろAPIをちゃんと切り出して運用したほうが良いよなーとか、ネイティブアプリやる時に必ず必須だしなぁーとか思ってた。 でせっかくならGolangでやった場合どんな感じになるかなと思いながらかる~く調べていた。

Golang自体の書き方云々はまぁ良いとして、実際のAPIを公開して運用するときにさてどんな構成が一番良いんだろうとかちょっと疑問に思った。

んで何通りかあって、どれが一番ベストパフォーマンスが出るんだろうなーと疑問に思ったのでそのあたりのbenchmarkとったのでまとめる

検証環境

f:id:tsuyoshi_nakamura:20161222222201j:plain

  • NginxでまずはHTTP通信を受ける
    • GoのフロントにNginxを置くのはキャッシュ、Logging等々、インターネットからのアクセスを受け付ける役割としてはNginxを使ったほうが最終的に良いだとうと最終的になりそうだったので入れた
  • その後、Golangに投げて、Golangではmysqlからサンプルデータをselectしてレスポンスするという環境にしている
    • Hellow Worldでは無くて少しでも実際のパターンに近づけた😀
  • nginx version: nginx/1.10.2
    • worker_processes 1;
    • worker_connections 1024;
    • keepalive_timeout 65;
  • go version go1.7.4 darwin/amd64
  • gomaxprocs=4 いつからのバージョンからはわからないけど動かしているマシンのCPUの数がセットされる様子
  • 自身のローカルマシーンのmacで完結させている

検証ツール

GitHub - wg/wrk: Modern HTTP benchmarking tool

GitHub - tsenart/vegeta: HTTP load testing tool and library. It's over 9000!

検証パターン

NginxとGoをつなぐ方法として下記のパターンを試した

Go(http.ListenAndServe) + Nginx(proxy)

一番サンプルででてくるパターンかな

vegetaでの検証結果

echo "GET http://localhost:8081" | vegeta attack -rate=100 -duration=30s | tee results_8081.bin | vegeta report

Requests      [total, rate]            3000, 100.03
Duration      [total, attack, wait]    29.996695502s, 29.98999987s, 6.695632ms
Latencies     [mean, 50, 95, 99, max]  8.262946ms, 6.36174ms, 16.602405ms, 20.103509ms, 249.542167ms
Bytes In      [total, mean]            486000, 162.00
Bytes Out     [total, mean]            0, 0.00
Success       [ratio]                  100.00%
Status Codes  [code:count]             200:3000
Error Set:

cat results_8081.bin | vegeta report -reporter='hist[0,2ms,4ms,6ms]'

Bucket         #     %       Histogram
[0,     2ms]   0     0.00%
[2ms,   4ms]   18    0.60%
[4ms,   6ms]   1108  36.93%  ###########################
[6ms,   +Inf]  1874  62.47%  ##############################################

cat results_8081.bin | vegeta report -reporter=plot > results_8081.html f:id:tsuyoshi_nakamura:20161225170707p:plain

wrkでの検証結果

wrk -t1 -c100 -d30s http://localhost:8081/

Running 30s test @ http://localhost:8081/
  1 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   205.13ms  207.27ms   1.96s    95.27%
    Req/Sec   524.92    143.15     0.90k    72.44%
  8261 requests in 30.02s, 2.50MB read
  Socket errors: connect 0, read 0, write 0, timeout 14
Requests/sec:    275.16
Transfer/sec:     85.18KB

Go(net.tcp) + Nginx(fastcgi_pass)

fastcgiTCP通信

vegetaでの検証結果

echo "GET http://localhost:8071" | vegeta attack -rate=100 -duration=30s | tee results_8071.bin | vegeta report

Requests      [total, rate]            3000, 100.03
Duration      [total, attack, wait]    34.148993246s, 29.989999849s, 4.158993397s
Latencies     [mean, 50, 95, 99, max]  786.786891ms, 6.547174ms, 6.418549209s, 7.619790263s, 7.978296865s
Bytes In      [total, mean]            486000, 162.00
Bytes Out     [total, mean]            0, 0.00
Success       [ratio]                  100.00%
Status Codes  [code:count]             200:3000
Error Set:

cat results_8071.bin | vegeta report -reporter='hist[0,2ms,4ms,6ms]'

Bucket         #     %       Histogram
[0,     2ms]   0     0.00%
[2ms,   4ms]   31    1.03%
[4ms,   6ms]   1116  37.20%  ###########################
[6ms,   +Inf]  1853  61.77%  ##############################################

cat results_8071.bin | vegeta report -reporter=plot > results_8071.html f:id:tsuyoshi_nakamura:20161225170704p:plain

wrkでの検証結果

wrk -t1 -c100 -d30s http://localhost:8071/

Running 30s test @ http://localhost:8071/
  1 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   312.64ms  258.32ms   1.97s    83.26%
    Req/Sec   330.31    225.29     0.92k    68.49%
  9786 requests in 30.08s, 3.11MB read
  Socket errors: connect 40, read 0, write 0, timeout 21
  Non-2xx or 3xx responses: 1607
Requests/sec:    325.37
Transfer/sec:    105.89KB

Go(net.unix) + Nginx(fastcgi_pass)

fastcgiUNIXドメインソケット通信

vegetaでの検証結果

echo "GET http://localhost:8061" | vegeta attack -rate=100 -duration=30s | tee results_8061.bin | vegeta report

Requests      [total, rate]            3000, 100.03
Duration      [total, attack, wait]    29.99792736s, 29.989999868s, 7.927492ms
Latencies     [mean, 50, 95, 99, max]  7.824538ms, 5.861618ms, 16.640207ms, 29.212751ms, 231.643738ms
Bytes In      [total, mean]            486000, 162.00
Bytes Out     [total, mean]            0, 0.00
Success       [ratio]                  100.00%
Status Codes  [code:count]             200:3000
Error Set:

cat results_8061.bin | vegeta report -reporter='hist[0,2ms,4ms,6ms]'

Bucket         #     %       Histogram
[0,     2ms]   0     0.00%
[2ms,   4ms]   121   4.03%   ###
[4ms,   6ms]   1484  49.47%  #####################################
[6ms,   +Inf]  1395  46.50%  ##################################

cat results_8061.bin | vegeta report -reporter=plot > results_8061.html f:id:tsuyoshi_nakamura:20161225170701p:plain

wrkでの検証結果

wrk -t1 -c100 -d30s http://localhost:8061/

Running 30s test @ http://localhost:8061/
  1 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   221.23ms  300.71ms   1.99s    89.90%
    Req/Sec   552.81    243.08     1.09k    72.54%
  16298 requests in 30.01s, 5.20MB read
  Socket errors: connect 1, read 0, write 0, timeout 52
Requests/sec:    543.11
Transfer/sec:    177.28KB

vegetaでの検証結果のまとめ

  • レイテンシーのグラフではぱっと見ちょっと良くわからなかった。ちゃんと追うと少し差異があるのがわかるんだけど...
  • Go(http.ListenAndServe) + Nginx(proxy)Go(net.tcp) + Nginx(fastcgi_pass)の比較はだいたい同じかんじ
  • Go(net.unix) + Nginx(fastcgi_pass)との比較ではちょっと差異がでた

少し差異がでた部分のLatency比較

4ms, 6ms 6ms, +Inf
Go(net.tcp) + Nginx(fastcgi_pass) 37.20% 61.77%
Go(net.unix) + Nginx(fastcgi_pass) 49.47% 46.50%

Go(net.unix) + Nginx(fastcgi_pass)ではレイテンシーが少々いいのかな😀

wrkでの検証結果のまとめ

Req/Sec
Go(http.ListenAndServe) + Nginx(proxy) Requests/sec: 275.16
Go(net.tcp) + Nginx(fastcgi_pass) Requests/sec: 325.37
Go(net.unix) + Nginx(fastcgi_pass) Requests/sec: 543.11

秒間でさばけるリクエストはGo(net.unix) + Nginx(fastcgi_pass)は一番良かった😀

まとめ的な

  • Golangをメイン言語にしてフルスタックなFWを使うパターンよりはバッチやAPIに使う場合が結構あると思う
    • そのときに https://github.com/gin-gonic/ginのうなFWは使わずに内包されてるnet/httpで作ってしまってパフォーマンスを優先するパターンが結構あるんだなーと色々と調べて感じた😁
  • 今回の検証結果的にはnet/httpGo(net.unix) + Nginx(fastcgi_pass)でやると一番良いんじゃないかという結果になった
  • 今回は対象外にしたけど grpc / grpc.ioあたりも触ってみたいなーと余談💪🏽
  • AWS gatewayを利用するけどヘッダー認証系やスロットリングAPIキー認証、レスポンスキャッシュなどが低コストでさくっと実装できたりできるので組み合わせるとなお良いかなーっと思ったけど内部のAPIサーバには使えなかったり...うーんおしい😅
    • 使い勝手良く改善されることを願う
  • golangでgraceful-restartも運用を考えると必要だなぁと感じたけどAPIの上位にロードバランサがいればいらないかもって感じてる。どうなんだろう🤔

Google データスタジオを試してみた

はじめに

日々色々な情報が流れてきますが、たまたま目に止まったのがGoogle データスタジオ。Google Analyticsは日々使ってるし、アクセス分析に関連した分析データをサクッと簡単に且つなるべく横断的に見れるのは求めてたし、使ってみた。それなりに良かったので使用感レポートとして残し置く

Google データスタジオとは

www.youtube.com www.google.com

  • もともと有償版であるGoogleアナリティクス360スイートがあってそのうちのGoogleオプティマイズ360Googleデータスタジオ360がある
  • そのGoogleオプティマイズ360Googleデータスタジオ360を無償版としてGoogleオプティマイズGoogleデータスタジオを発表された
  • MicrosofltのPowerBIという同様のツールの対抗として発表された模様

主な特徴

データソースは下記が選択できる

実際の画面の使い方は下記のサイトが詳しい

Googleデータスタジオの使い方 #GoogleDataStudio

速報!Google Data Studio(グーグル・データ・スタジオ)使用感レポート | 株式会社プリンシプル

実際に使ってみた

データソースはGoogle Analyticを活用 f:id:tsuyoshi_nakamura:20161207161843p:plain

所感。良いところ

  • サクッとできた😃
  • グラフがキレイ😃
  • 印刷ボタンがないところが良い😄
    • 印刷した瞬間からどんどんゴミになっていきますからね...
    • 常にこのレポートで最新を見る。過去を見たければカレンダーを操作する💪🏽
  • データソースが豊富😃
  • 広告のデータも一緒に出せるので費用対効果が一発で見れる😃
    • 今回は使ってないけど
  • フィルターが使えるので色々な視点で絞って分析が可能😃
  • 前年比とかできて良い😃

イマイチなところ

  • データスタジオ上で数式計算とかはできない😢
  • CV系のデータはBigQueryに入れてそこから引いたほうが良さげ😢
    • Google AnalyticsにもCVデータ保存できるけど、正しい数値とはちょっとズレが生じるので別口でBigQueryにデータを入れて引いたほうがデータが正確になる

まとめ

この手軽さからしてまず良い!!GCPにあるデータとかと繋げられたらまた広がるなぁーと感じた

社内勉強会でキャッシュサーバのVarnishのベンチマークをレポートした

久しぶりに毎週金曜日にやっている社内の勉強会で話す機会を得たので発表した内容を残しておく

発表資料

speakerdeck.com

ざっくり感想

  • memcachedとvarnishの単純なキャッシュ性能を計測した。恐らくvarnishのが良いんだろうなーと思ってたけどその通りの結果になった😅
  • Benchmarkの数値を集計して評価するのに色々と設定が面倒で今回はレイテンシーのみを Vegeta(https://github.com/tsenart/vegeta)見てた😃
  • これからも定期的に発表していこうと思います💪🏽