忍者ブログ

STEP UP BLOG

Home > ブログ

[PR]

×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

Laravelの開発環境でカスタムエラーページを表示させないために

Laravel 5.2対象。
Laravel 5.2では、
resources/views/errors
以下に
resources/views/errors/404.blade.php
resources/views/errors/500.blade.php
のようにHTTPステータスコードのビューファイルを置くことで、独自のエラーページを表示させることができます(ステータスコードでなくてもできますが)。
しかし、開発環境では小綺麗なエラーページでなく、どんなエラーがどこで起きたか知りたいのが常。
というわけで本番環境ではないときに、カスタムエラーページではなくLaravelのエラースタックトレース画面を表示させるにはどうすればいいか。
Laravel 5.2でのエラーハンドリングは、
app/Exceptions/Handler.php のHandlerクラスが取り扱っています。
このクラスはExceptionHandlerクラスを継承していて、ExceptionHandlerクラスにはrenderHttpExceptionメソッドといういかにもそれっぽいメソッドがあります。
このrenderHttpExceptionメソッドがカスタムエラーページを描画しています。
そこでrenderHttpExceptionメソッドをHandlerクラスでオーバーライドしましょう。
/**
 * Render the given HttpException.
 *
 * @param  \Symfony\Component\HttpKernel\Exception\HttpException  $e
 * @return \Symfony\Component\HttpFoundation\Response
 */
protected function renderHttpException(HttpException $e)
{
    if (!App::environment('production')) {
        return $this->convertExceptionToResponse($e);
    }

    return parent::renderHttpException($e);
}

上記をHandler.php内に記述すれば、本番環境以外でカスタムエラーページが表示されなくなります。
という感じで快適なLaravelライフを(^人^)
PR

サーバが増えるとつらい

最近行なった七面倒な作業にサーバ10台以上にSSL証明書をインストールするというものがありました。
めんどー！泣
sshログインして証明書を更新してApacheを再起動して、と1台目のサーバで作業した時点でこれは大変だと気付いたので、インストール用のシェルプログラムを書いて出来る限り自動化したのですが、それでもそこそこの時間がかかりました。
サーバ毎に確認も必要で、なんですべてのサーバに証明書を置かないといけないのかと。。。
こういう複数サーバ構成だと、やはりロードバランサーにSSL証明書を起きたいものです。
即ちELB。(E)えげつないほど(L)楽ちんで(B)便利なロードバランサーことELB。
ELB使うと楽ですよね。
AWSにロックインされてしまいますが。
操作もシンプルですし、唯一リダイレクトループにさえ気をつければこれほど便利なサービスはないと思います。
ELBを使えばSSL証明書もELBに置きさえすればいいのでサーバ毎のインストールは必要ありません。
というわけで、これから規模の大きいサーバ構成にしたいときはAWSをメインに検討していきたいですね。

CentOS6以前とCentOS7でのよく使うコマンドのメモ

主にWebサーバを動かすときによく使うコマンドを挙げています。

・サービス一覧
CentOS6以前
$ chkconfig --list

CentOS7
$ systemctl list-units --type=service


・サービスの状態、起動、停止、再起動(例:httpd)
CentOS6以前
# service httpd status
# service httpd start
# service httpd stop
# service httpd restart

CentOS7
# systemctl status httpd.service
# systemctl start httpd.service
# systemctl stop httpd.service
# systemctl restart httpd.service


・ファイアウォール
CentOS6以前
# iptables -nvL
# iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

CentOS7
# firewall-cmd --list-services --zone=public --permanent
# firewall-cmd --add-service=https --zone=public --permanent

firewalldはサービス名で追加削除できるのでわかりやすいですね。

Font Awesome

仕事でFont Awesomeを使ってます。
Font AwesomeはフリーのWebアイコンフォントです。
商用利用可能です。
http://fontawesome.io/
味気ない業務サイトも見出しやメニューなどにアイコンが付くと、とたんにフレンドリーに見えてきます。
使い方も簡単です。
http://fontawesome.io/examples/
アイコンの種類も豊富で日々増えています。
だいたい欲しいアイコンは揃っています。
http://fontawesome.io/icons/
バッテリーアイコンなど残量に応じて11種類のアイコンが用意されています。
これさえあれば他に何も要らないレベルです。
もうアイコンだけで会話ができるレベルです。
サイトにもう一味わかりやすさを求めているときに活用してみてはどうでしょうか。

MySQLのSQLプロファイリング

MySQLの実行が遅いときはチューニングが必要です。
MySQLのSQLチューニングですが、基本中の基本がexplainです。
スロークエリログで見つけた遅いSQLをexplainで実行して、適切なインデックスが使用されているか調べるのが、まずはチューニングの第一歩です。
それでも高速化したいSQLのどこが遅いのかわからないときはSQLのプロファイリング情報を調べます。
プロファイリングは以下のようにして表示できます。
mysql> SET PROFILING = 1;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT ...
...
...
117 rows in set (6 min 54.15 sec)

mysql> SHOW PROFILE;
+------------------------------+------------+
| Status                       | Duration   |
+------------------------------+------------+
| starting                     |   0.000246 |
| checking permissions         |   0.000004 |
| checking permissions         |   0.000003 |
| checking permissions         |   0.000002 |
| checking permissions         |   0.000002 |
| checking permissions         |   0.000002 |
| checking permissions         |   0.000002 |
| checking permissions         |   0.000002 |
| checking permissions         |   0.000002 |
| checking permissions         |   0.000005 |
| Opening tables               |   0.000030 |
| System lock                  |   0.000005 |
| Table lock                   |   0.000094 |
| optimizing                   |   0.000032 |
| statistics                   |   0.000051 |
| preparing                    |   0.000033 |
| Creating tmp table           |   0.000026 |
| executing                    |   0.000003 |
| Copying to tmp table         |   0.161709 |
| Sorting result               |   0.000767 |
| Sending data                 |   0.002630 |
| removing tmp table           |   0.000008 |
| Sending data                 |   0.000007 |
| init                         |   0.000112 |
| optimizing                   |   0.000022 |
| statistics                   |   0.000041 |
| preparing                    |   0.000030 |
| Creating tmp table           |   0.000066 |
| executing                    |   0.000003 |
| Copying to tmp table         |   0.050874 |
| converting HEAP to MyISAM    |   0.033028 |
| Copying to tmp table on disk | 103.846074 |
| Sorting result               | 158.297312 |
| Sending data                 | 151.018799 |
| end                          |   0.000026 |
| removing tmp table           |   0.807298 |
| end                          |   0.000016 |
| query end                    |   0.000004 |
| freeing items                |   0.000045 |
| removing tmp table           |   0.000009 |
| freeing items                |   0.000010 |
| removing tmp table           |   0.000004 |
| freeing items                |   0.000005 |
| removing tmp table           |   0.000006 |
| freeing items                |   0.000033 |
| removing tmp table           |   0.000007 |
| closing tables               |   0.000011 |
| logging slow query           |   0.000002 |
| logging slow query           |   0.000006 |
| cleaning up                  |   0.000007 |
+------------------------------+------------+
50 rows in set (0.00 sec)

上記のように調べたいSQLを実行した後にSHOW PROFILEします。
これはJOINの多いSQLを実行したときですが、めちゃくちゃtmpテーブルを作ってますね。。。
この場合はそもそもJOINがここまで必要とするテーブル構成でいいのか疑問となってきます。
また、"Sorting result"に時間がかかっているのでORDER BYかもしくはGROUP BYがボトルネックとなっていると思われます。
これ以外に手軽にできるチューニングというと、あとはバッファサイズの変更でしょうか。これはサーバスペックなどとにらめっこしながら適正値を探っていかないとなりません。
という感じで、今回はMySQLのSQLプロファイリング情報を調べてボトルネックを突き止めるということをまとめてみました。

PAGE TOP