ghq/peco/hubを組み合わせてローカル・リモートリポジトリに即座にたどり着く
はじめに
あまりにも有名な下記ツールを組み合わせて、ストレスなく、リポジトリにたどり着くような設定にしたのでまとめておきます。
あまりにも有名なので、ツールの説明は割愛します。が、ざっくりいうと、
Go製のリポジトリ管理ツール
github.com
同じくGo製の使い勝手のいいフィルタリングツール
github.com
GitHubをCLIで操作するツール
github.com
ですw
ローカル編
ローカルにcloneしたリポジトリを一覧して選択したリポジトリに移動する 操作を素早く行えるようにしています。
zshだとこんな感じの設定になります。
function peco-src () { local selected_dir=$(ghq list -p | peco --query "$LBUFFER") if [ -n "$selected_dir" ]; then BUFFER="cd ${selected_dir}" # pecoで選択中, Enter を押した瞬間に実行する zle accept-line fi zle clear-screen } # 関数をウィジェットに登録 zle -N peco-src bindkey '^]' peco-src
"ghq list -p" で、"ghq get"でローカルにクローンしたリポジトリ一覧を表示します。
パイプでつないだ'peco --query "$LBUFFER"'で、その一覧をpecoのコンソールに表示させます。
このようなやり方は、他のQiitaの記事でも紹介されている(というかほぼパクリ)ので、目新しいことはありません。
リモート編
リモートリポジトリを一覧し、選択したリポジトリをブラウザで表示します。
下記は、先程のローカル用の関数をカスタマイズして作成した関数です。
function peco-src-remote () { local selected_repo=$(ghq list -p | peco --query "$LBUFFER" | rev | cut -d "/" -f -2 | rev) echo $selected_repo if [ -n "$selected_repo" ]; then BUFFER="hub browse ${selected_repo}" zle accept-line fi zle clear-screen } zle -N peco-src-remote bindkey '^^' peco-src-remote
解説
hubツールに"browse"というコマンドを使って、リモートのリポジトリページをブラウザで開くことができます。
$ hub browse [ユーザ名/リポジトリ名]
なので、下記のようなローカルリポジトリのパス文字列を分解して"hub browse"に渡すということをしたいとおもいます。
$ /Users/kitakitabauer/.ghq/github.com/ユーザ名/リポジトリ名
しかし、$GOPATHやghqのルートによって、パス階層がどのぐらいになるのかわからないので、渡す文字列を固定で切り出すことがめんどくさそうです。
- /Users/kitakitabauer/.ghq/github.com/kitakitabauer/dotfiles
- /Users/kitakitabauer/go/src/github.com/kitakitabauer/dotfiles
- /Users/kitakitabauer/go/src/bitbucket.org/kitakitabauer/dotfiles
自分は以前の記事でご紹介しましたが、".ghq" や "go/src" のように、cloneするディレクトリを分けているので、単純に前者と後者で階層に1つ差が生まれます。
そこで、今回の記事のポイントなのですが、汎用的に"hub browse"に渡したい文字列を整形できるようにしました。
ポイントは下記の部分です。
rev | cut -d "/" -f -2 | rev
1. rev で文字列をひっくり返す
名リトジポリ/名ザーユ/moc.buhtig/qhg./reuabatikatik/sresU/
2. cut -d "/" -f -2 で、スラッシュ区切りで先頭から2フィールド目までを取り出す
名リトジポリ/名ザーユ
3. rev で再び逆にして、ユーザ名/リポジトリ名の順番に戻す
ユーザ名/リポジトリ名
最後に作成した関数を"bindkey"コマンドで、割当がないキーにあてることで一発呼び出しができます。
bindkey '^]' peco-src bindkey '^^' peco-src-remote
今回のzshの設定を含めたdotfilesはこちらにコミットしています。
github.com
rev は使い道に迷いますが、cut と組み合わせることで他にも面白いことができそうです。
おしまい。
Goのことはじめ その1:GOPATHとghqのルート指定
はじめに
業務でGoを触ることになったので、Goに関して気になったことをまとめていこうと思います。
GOPATH
GOPATHはGoで使う環境変数なのですが、2つの役割があります。
- ビルド時のインポートパスのルート(正確には$GOPATH/src配下)
- go getコマンドで外部パッケージをインストールしたときの、ダウンロードルートディレクトリ
詳細は公式ドキュメントに記載されています。
How to Write Go Code - The Go Programming Language
ghq
id:motemen さん作の、Go製のリポジトリ管理ツールです。
github.com
$ ghq get (GitHubの)ユーザ名/リポジトリ名
とすると、ローカルの "~/.ghq" というディレクトリにデフォルトでインストールされます。
"ユーザ名/リポジトリ名"の部分ですが、GitHub以外、例えばbitbucketは"https://ユーザ名@bitbucket.org/…"のように一から指定する必要があります。
Goにはgetコマンドがあるので、事足りるような気もするのですが、他にもクローンされたリポジトリを一覧したり、指定したローカルのリポジトリにcdできるので、重宝しています。
GOPATHとghqのルートをどこに設定するか
「GOPATHは適当に決めて問題ない」という記事もありましたが、個人的には適当に決めてあとで地雷を踏みたくないのが性分です。
例えば".ghq"の下にgetしたけど、やっぱりこのライブラリをインポートしたいから"go/src"の下に入れたい…となったときにシンボリックリンクを貼るのか、同じものをgo getするのかなど、色々困りそうです。
それを踏まえて、自分はこのようにしようと思います。
$GOPATH
export GOPATH=~/go
.gitconfig
[ghq] root = ~/.ghq root = ~/go/src
Go 言語のソースだけは go get で 取得し "$GOPATH/src" 以下に
そうでないものは ghq get で "~/.ghq" 以下に取得するようにしています。
今回はここまでです。
次回はGoのバージョン管理システム選定について書きたいと思います。
dotfiles整理 その2:zshrcから分割した設定ファイルが読み込まれない問題への対処
kitakitabauer.hatenablog.com
前回の記事はこちら。
この構成に変えたあと、.zprofileに記述した部分が読み込まれなくなりました。
ターミナルアプリで起動されるのは、ログインシェルではなく、インタラクティブシェル
という事実を下記記事にて知りました…!
qiita.com
自分はターミナルアプリにiTerm2を使っており、下記の通りbrewインストールしたzshを起動しています。
前回の記事で「zshが起動時に読み込むファイルとその順番」について記述しましたが、
ログインシェルでないと、$ZDOTDIR/.zprofile は読み込まれません。
かといって、"Send text as start: "に "source $HOME/.zprofile" を入れて毎回読み込むのも、インタラクティブシェルのときに毎回読み込むことになるので、zsh標準の仕様と外れるので気持ち悪いし、セッションを起動するたびにそのコマンドが毎回出力されるのも嫌です。
ログインシェル変更
ターミナルアプリ上ではなく、ローカル設定からzshを指定するようにして対応することとします。
(なので、iTerm上の設定は"Command"→"Login shell"に変更しておきます)
まずは現在のインストールシェル一覧を確認
$ cat /etc/shells # List of acceptable shells for chpass(1). # Ftpd will not allow users to connect who are not using # one of these shells. /bin/bash /bin/csh /bin/ksh /bin/sh /bin/tcsh /bin/zsh
/etc/shellsに、brewインストールされたzshのパスを追加
デフォルトインストールされたzshはバージョンが少し古いため、brewインストールしたzshのパスをroot権限で追加します。
$ sudo vi /etc/shells … /bin/zsh /usr/local/bin/zsh # 追加
ログインシェル変更
デフォルトのシェルを先ほど追加したzshに変更します。
下記コマンドによって、/etc/shellsの一番最後に記述されたzshに変更します。
$ chsh -s "$(command -v zsh)" "${USER}"
確認
読み込んだ順番を確認するために、それぞれの設定ファイルにechoを入れたあと、
ターミナルアプリの別セッションを立ち上げると、
~/.zshenv ~/.zsh/.zshenv ~/.zsh/.zprofile ~/.zsh/.zshrc
問題なし!
尚、ログインシェル変更の方法は色々あるらしいです。
rcmdnk.github.io
dotfiles整理 その1:zshの構成を見なおそう
はじめに
最近ちょっと時間ができたので、随分放置してきたdotfilesを整理をすることにしました。
まずはzsh。
これまでは.zshrcに全て記述していたので、前々から役割毎に分けたいと思っていました。
大まかな方針は下記の通りです。
構成はこんな感じを想定しています。
/Users/kitakitabauer/. ├── .zshenv -> /Users/kitakitabauer/dotfiles/.zshenv ├── .zsh │ ├──.zprofile -> /Users/kitakitabauer/dotfiles/.zsh/.zprofile │ ├──.zshenv -> /Users/kitakitabauer/dotfiles/.zsh/.zshenv │ └──.zshrc -> /Users/kitakitabauer/dotfiles/.zsh/.zshrc └── …
環境変数 ZDOTDIR の設定
ホームディレクトリがzsh関連のファイルで埋まるのが嫌なので、ZDOTDIR を指定して、zsh関連の設定ファイルを別フォルダにて管理します。
ZDOTDIR は$HOME/.zshenv に記述します。
export ZDOTDIR=$HOME/.zsh source $ZDOTDIR/.zshenv
これで、$HOMEに置く必要があるのは.zshenvだけになります。
zshが起動時に読み込むファイルとその順番
zshには様々な設定ファイルがあり、それらは決まった順番で読み込まれます。
ログインシェルは下記の順番で読み込まれます。
/etc/zshenv $ZDOTDIR/.zshenv /etc/zprofile $ZDOTDIR/.zprofile /etc/zshrc $ZDOTDIR/.zshrc /etc/zlogin $ZDOTDIR/.zlogin
インタラクティブシェルは下記の順番で読み込まれます。
/etc/zshenv $ZDOTDIR/.zshenv /etc/zshrc $ZDOTDIR/.zshrc
ログインシェルとしてzshを使うので、前述の通り.zshenv、.zprofile、.zshrcの構成でいきます。
.zloginは今のところ使用しないので作成しません。
尚、全てのユーザに影響するため、etc配下の設定ファイルは変更しません。
それぞれの設定ファイルに何を記述するか
$ZDOTDIR/.zshenv
環境変数系。ヒストリー系もここで記述します。
$ZDOTDIR/.zprofile
ログインシェルだけで使いたいaliasを記述します。
$ZDOTDIR/.zshrc
上述以外の全てを記述します。
dotfilesのシンボリックリンク生成
最後にsymlink.shにて、gitリポジトリのdotfilesに対して、$HOMEにシンボリックリンクを貼ります。
basepath=$(cd $(dirname $0);pwd) # symlink dotfiles into ~files=.* for file in $files do if [ ! -d $file -a $file != "." -a $file != ".." -a $file != ".git" ] ; then ln -sf $basepath/$file ~ fi done # symlink zsh configuration files into ~/.zsh if [ ! -d ~/.zsh ] ; then mkdir ~/.zsh fi for file in .zsh/.* do if [ $file != "." -a $file != ".." -a $file != ".git" ] ; then ln -sf $basepath/$file ~/.zsh/ fi done
完成
まだ工事中ですが、一旦こんな感じになりました。
github.com
次の記事はこちら
kitakitabauer.hatenablog.com
きたるISUCON6向け武者修行その4 -kataribeでHTTPリクエストのパフォーマンスを可視化しよう-
kitakitabauer.hatenablog.com
前回はNginxのチューニングを行いました。
今回はISUCONの過去問でも登場してきたプロファイリング用のツールを予習しておきます。
kataribeとは?
"Nginx/Apache/Varnishncsa Log Profiler"と書かれている通り、
アクセスログに出力されたリクエスト時間を元に、時間がかかっているアクセスをランキング化してわかりやすくしてくれるツールです。
github.com
インストール
このサイトから実行元OSのものをダウンロードします。
Releases · matsuu/kataribe · GitHub
$ wget https://github.com/matsuu/kataribe/releases/download/v0.3.0/linux_386.zip ~
unzipがなかったので、yumインストールして展開します。
$ sudo yum install unzip $ unzip ~/linux_386.zip Archive: /home/vagrant/linux_386.zip inflating: LICENSE inflating: README.md inflating: kataribe inflating: kataribe.toml
ログフォーマット確認、プロファイル用ログの準備
nginx.confに定義するログフォーマットは前回設定しましたが、kataribeのREADMEに記載された通りなので問題ありません。
上記フォーマットでログを出力するために、ベンチマーカーを一度動かしておきます。
$ ./benchmarker b
アクセスログをkataribeでプロファイル
終わったら、nginxのアクセスログをkataribeに噛ませます。
$ cat /var/log/nginx/access.log | ./kataribe Top 20 Sort By Total Count Total Mean Stddev Min P50.0 P90.0 P95.0 P99.0 Max 2xx 3xx 4xx 5xx Request 587 46.784 0.079700 0.027365 0.004 0.092 0.102 0.109 0.134 0.182 0 587 0 0 POST /login HTTP/1.1 1 23.642 23.642000 0.000000 23.642 23.642 23.642 23.642 23.642 23.642 1 0 0 0 GET /report HTTP/1.1 3519 14.101 0.004007 0.001516 0.001 0.004 0.006 0.007 0.009 0.013 3519 0 0 0 stylesheets 1173 4.765 0.004062 0.001323 0.001 0.004 0.006 0.006 0.008 0.014 1173 0 0 0 images 113 3.293 0.029142 0.012153 0.002 0.033 0.037 0.039 0.047 0.054 113 0 0 0 GET /mypage HTTP/1.1 1060 1.645 0.001552 0.000827 0.001 0.001 0.002 0.002 0.005 0.009 1060 0 0 0 GET / HTTP/1.1
単純なリクエスト数や中央値など色々な指標で出力されますが、上記のTotalが、最も時間がかかっているリクエストパスのランキングになります。
なので、ここでは/loginを改善すればパフォーマンスが出そう!ということが考察できます。
おまけ
リクエスト時間には関係ないですが、最も多いHTTPリクエストを昇順に表示するワンライナーです。
kataribeでも"Top 20 Sort By Count"で出力されますが、ワンライナーでさくっと表示したい場合はこちらで。
$ cat /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -n 1 /report 113 /mypage 587 /login 1060 / 1173 /images/isucon-bank.png 1173 /stylesheets/bootflat.min.css 1173 /stylesheets/bootstrap.min.css 1173 /stylesheets/isucon-bank.css
Node学園 22時限目メモ
eventdots.jp
こちら、参加してきたのでメモる。
「Node学園祭 2016の告知」by yosuke furukawa さん
11/12(土)
- dotsイベント会場で開催する予定。13日とは異なるので注意。
- ハンズオンメイン
- 今年もpaypalがスポンサー
11/13(日)
- サイバーエージェントオフィスにて開催
- 豪華なゲストスピーカー
- Douglas Crockford:JSONを再定義した人/JavaScript Good Partsを書いた人
・James M Snell:IBMのエンジニア
・Bradley Meck:ESモジュールのCompatibleを取ってる人。ES6とNode.jsの相互運用をしている人。
・Cheng Zhao:今日本のGitHubにいる。今をときめくErectronの作者。
・Yoshua Wyuts:ChuというフロントエンドFWを作っている人。
・Mathias Buus:サンフランシスコのNode confarenceとかでよく登壇している。MongoDB Driver、Node Tetrisとか書いている。
今月中にCFP(Call For Paperpage)/sponsor pageを出します!って宣言してた。
今年もNode学園祭参加せねば!
「Stream b/w node.js & whatwg」by Jxck さん
Streamを制するものはNodeを制す から 5年
Stream APIがブラウザにやってくる!
先に結論:Node.jsのものとwhatwgのものとは互換性などない
両者の供述を聞く
In Node.js
- 非同期はCallbackが基本
- 引数にルールを決めて扱いやすくしよう
- 連続するイベントはEventEmitter
- EventEmitterの上位APIがStream
- Multi-Consumer
- カスタマイズは継承
In whatwg
- 非同期はPromiseはPromiseを返してこう
- Async/Awaitでそれを便利にしよう
- もちろんStreamはPromiseのジェネレータ:無限にPromiseが湧いてくる
- (≠ES6 Generator)
- Single-Consumer:同じPromiseは得られないので
- カスタマイズはコンストラクタ:これがなんでかはわからないらしい
あまり業務でStreamを触ることがないのでなんとも。。
「IntelのEdisonで最新版のNodeを動かす」 by niccolli さん
niccolliさんはアキバの家電メーカーで電気回路の設計をしている
Intel Edison is 何?
- 小型Linuxボード、各種無線LAN、Bluetooth
- Arduino互換の言語 / Node.jsで書ける
- 組み込まれているNode.jsが古い
- 今年6月ではv0.12、最新FWでやっとv4.4.3
組み込まれたNode.jsをアップデートしよう!
Node.jsを更新するには?
公式のLinux Binariesの32bitを落として入れれば動く。
Edisonの中身はx86のLinuxで、Edision内部でビルド必要なしで、公式バイナリがそのまま動く。
USB接続で、Node.jsバージョンの切り替えを実演してた。あんなに小さいのにすごい!
「プロセスをしょうもないErrorで落とさないように頑張る」 by mookjp さん(古川さんの同僚)
要約
- Node.jsでサーバをつくってるときに難しいと感じた点
- 具体的にどういうことが起こったか
- エラー処理をどう書くか
下記Qiitaを元にしたLT
qiita.com
TL;DR
プログラマが想定していなかった例外でプロセスが落ちる問題にPromiseで対処する
想定外のエラーでプロセス終了事案
- WebSocketのクライアントとサーバがあり、サーバではイベントループ中に様々な処理をしている。
- JSON.parseがうまくいかなかったなど想定外のエラーで巻き添えで死んでしまう。
- 利用しているライブラリから想定外のErrorをthrowされると…
プロセスを無駄に落とさずに処理できる現実的なエラー処理
1.try-catchで書く
いわずもがな
2.非同期処理はPromiseで書くこと
同期処理時のthrowsも、非同期処理時のエラーオブジェクトも両方Promise.catch()でつかむことができる。
Promise内部でtry-catchをしてくれている。
Errorがトップレベルまで突き抜けることはなくなる。
3.unhandledRejectionイベントでログ出力
Promiseがrejectされたが、Promise.catch(func)処理がなかった場合に発火されるイベント。
Promise.catchし忘れの凡ミスでプロセスが落ちないように。
process.on('unhandledRejection', func)を書いておいてログ出力する。
最悪ログを出しておけば後で直せる。
これがないとNodeに握りつぶされるので、バグに気づかないかも・・・
4.uncaughtExceptionで終了処理させる
ログ出力してプロセスを終了させる。
uncaughtExceptionはV8レイヤでキャッチされているので、無理に継続するとイベントやプログラムの状態がおかしくなる可能性があるので復旧しないほうがいい。
yosuke furukawa さんの 「Node.js における Promise を使った例外処理」で詳しく
yosuke-furukawa.hatenablog.com
現場のコードはES6だけど、まだPromiseを使っていないので今後の参考にさせていただく!
きたるISUCON6向け武者修行その3 -Nginxのチューニングをしてみよう-
kitakitabauer.hatenablog.com
前回MySQLのチューニングを行いました。
今回はNginxのチューニングを行います。
Nginxのバージョン確認
$ nginx -v
nginx version: nginx/1.6.1
古すぎないので問題なさそうです。
デフォルトのnginx.confを確認
/etc/nginx配下のnginx.confが読み込まれるので、そちらの内容を確認します。
$ sudo vi /etc/nginx/nginx.conf
worker_processes 1; events { worker_connections 1024; } http { upstream app { server 127.0.0.1:8080; } server { location / { proxy_pass http://app; } } }
尚Nginxは、conf.dディレクトリに.confを作成すると起動時に読み込むので、default.confの内容も読み込まれています。
今回は /etc/nginx/nginx.conf の方をチューニングしていきます。
worker_processes変更
ワーカープロセスの数を変更します。
応答するマシン次第ですが、Nginxは複数のプロセスの要求処理を分散させることができるので、CPUが複数コアのときも対応できるように auto にします。
worker_processes auto;
keepalive追加
バックエンドサーバと保持するコネクション数を指定します。
upstreamブロックに記述します。
upstream app { server 127.0.0.1:8080; keepalive 128; }
静的ファイルのNginxキャッシュ
デフォルトだと、スタイルシートや画像ファイルに対してもアプリケーションからHTTPアクセスしているので、Nginxからリクエストしてキャッシュするように設定します。
serverブロックにcssとimagesの設定を記述しますが、
まず各locationディレクティブの上に、rootディレクティブでドキュメントルートを設定します。
root /home/isucon/webap/public; location /stylesheets { open_file_cache_max=100 inactive=20s; expires 1d; } location /images { open_file_cache max=100 inactive=20s; expires 1d; }
expiresディレクティブ
応答のキャッシュ関連ヘッダを操作します。
クライアントに送られるExpiresとCache-Controlの値を操作します。
現在から1日がファイルの有効期限として設定されます。
open_file_cacheディレクティブ
オープンファイルについての情報を格納するキャッシュを定義します。
max=X:Xはキャッシュが格納できるエントリ数で、この数に達すると、新しいエントリのためのスペースを作るために、古いエントリは削除されていきます。
inactive=Y:Yは、キャッシュエントリを格納しておく秒数です。平たくいえば、アクセスがないキャッシュの有効期限です。デフォルト60秒でキャッシュエントリをクリアします。キャッシュエントリにアクセスがあると、タイマーはリセットされます。
最終的なnginx.conf
こんな感じになりました。
worker_processes auto; events { worker_connections 1024; # accept_mutex_delay 100ms; accept_mutex off; } http { upstream app { server 127.0.0.1:8080; keepalive 128; } log_format main '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" $request_time'; access_log /var/log/nginx/access.log main; include /etc/nginx/mime.types; server { listen 80; server_name localhost; root /home/isucon/webapp/public; location /stylesheets { open_file_cache max=100 inactive=20s; expires 1d; } location /images { open_file_cache max=100 inactive=20s; expires 1d; } location / { proxy_http_version 1.1; proxy_set_header Connection ""; proxy_pass http://app; } } }
設定ファイルの記述ルールに違反していないかチェック
設定ファイルの記述ルール上問題ないか確認します。
$ sudo /etc/init.d/nginx configtest
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
nginx.confリロード
これまでの変更をNginxに適用します。
$ sudo service nginx reload
nginxログのパーミッション変更
admグループに所属しないユーザが見れないので、isuconユーザでも読み取り権を与えます。
$ ll -lrt /var/log/nginx/ -rw-r----- 1 nginx adm 0 Jul 14 03:14 error.log -rw-r----- 1 nginx adm 0 Aug 19 08:42 access.log $ sudo chmod o+r /var/log/nginx/* $ ll -lrt /var/log/nginx/ -rw-r--r-- 1 nginx adm 0 Jul 14 03:14 error.log -rw-r--r-- 1 nginx adm 0 Aug 19 08:42 access.log
access.log確認
ベンチマーカーを実行するかブラウザアクセスで指定したフォーマットになっているか確認します。
$ sudo tail -f /var/log/nginx/access.log … 10.0.2.2 - - [01/Jul/2016:11:31:58 +0000] "GET / HTTP/1.1" 200 2233 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36" 0.003 … 10.0.2.2 - - [01/Jul/2016:11:31:58 +0000] "GET /images/isucon-bank.png HTTP/1.1" 304 0 "http://localhost:3333/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36" 0.000
ベンチマークスコア確認
改めてベンチマーカーを実行します。
[isucon@localhost ~]$ ./benchmarker b 14:14:17 type:info message:launch benchmarker 14:14:17 type:warning message:Result not sent to server because API key is not set 14:14:17 type:info message:init environment 14:14:20 type:info message:run benchmark workload: 1 14:14:27 type:fail reason:Response code should be 200, got 500 method:POST uri:/login 14:14:29 type:fail reason:Response code should be 200, got 500 method:POST uri:/login 14:14:32 type:fail reason:Expected location is miss match /, got: /mypage method:GET uri:/mypage 14:14:34 type:fail reason:Response code should be 200, got 500 method:POST uri:/login 14:14:38 type:fail reason:Response code should be 200, got 500 method:POST uri:/login 14:14:41 type:fail reason:Expected html text is match: Wrong username or password, got This account is locked. method:GET uri:/ 14:14:42 type:fail reason:Response code should be 200, got 500 method:POST uri:/login 14:14:47 type:fail reason:Response code should be 200, got 500 method:POST uri:/login 14:14:59 type:fail reason:Response code should be 200, got 500 method:POST uri:/login 14:15:01 type:fail reason:Response code should be 200, got 500 method:POST uri:/login 14:15:20 type:info message:finish benchmark workload: 1 14:15:25 type:info message:check banned ips and locked users report 14:15:49 type:report count:banned ips value:2 14:15:49 type:report count:locked users value:2555 14:15:49 type:fail reason:Missmatch banned Users message:Report checking is failed. Do not send score. 14:15:49 type:score success:5860 fail:10 score:1266
failが出るようになった…
とりあえず、Nginxのチューニングはいったんここまでとします。
次回記事はこちら