AWSのCloudSearchを使ってみているけれども、これで使われているインスタンスって、m1.smallとかm3.mediumなんだよなぁ。どうせなら、コストパフォーマンスよさげなt2インスタンスとか使えるようにならないかなぁと思うけど、t2インスタンスのCPUクレジットを使い切って性能がガクッと落ちたら切ないか。うん、それは切ない。…みたいなアホなエントリーを書いているけれど、一向にindexingが終わらない…。うーむ、とりあえず安いsearch.m1.smallインスタンスだと、何やらせても時間かかるなぁ(遠い目)
月: 2015年2月
zabbixのagentでphp-fpmの監視をどうするかなぁと思ったけど、Google先生に聞いてみたら、テンプレートがあった。php-fpmでステータスを吐き出させるようにしておいて、zabbixエージェントとphp-fpmのステータス表示をつなげるシェルを置いておく、という方式のようで。
Template php-fpm：
https://github.com/jizhang/zabbix-templates/tree/master/php-fpm
まぁ、このサイトはサーバが物理的に遠いところにあるので、ネットワークのレイテンシーが大きいとはいえ、SPDYの効果は多少はありそうなので、SPDYを使えるシーンではできるだけ対応してみたいと思った…が、しかし。
今、運用している別サイトでは、AWSのELBを使ってSSLの処理をオフロードしているんだけど、その状態ではSPDYは使えない。ELBがSPDYしゃべってくれないもんなぁ。
というわけで、ELBではHTTPSのコネクションの振り分けだけやってもらって、SSLの処理は配下のnginxとかApache httpdで受けなきゃいけないってことになり、SPDYを使えるようにするためにSSLの処理を配下に持ち込むのもなんかなぁ…(いやまぁ、たいしたトラフィックじゃないけど、ELBの料金のなかでSSLのオフロードもしてもらっていると思うと、できればSSLの処理はELBに押しつけたいような)
…というわけで、AWSのELBでSPDYをしゃべれるようになって欲しいなぁと。ここまで書いて、ふと思ったのは、ELBからユーザーの環境までをSPDYにしても意味ないんだっけ…あれ(汗)
SPDYに対応させるとどうなるか試してみたかったので、このサイトのコモンネームでSSL証明書を買ってきて、nginxのspdyモジュールを使ってspdyを利用可能にしてみた。
ブラウザにSPDY Indicatorとかのアドオンを入れると、SPDYを使っていることが確認できる。まぁ、このサーバは米国の西海岸にある物理サーバで動いているVPSなので、通信部分のレイテンシーが大きいせいか、「多少は早くなったかなぁ…」という印象。まぁ、いっか(遠い目)
WordPressをSSL化するときには、とりあえず、「設定」から「一般」を開いて、「WordPress アドレス (URL)」と「サイトアドレス (URL)」のsheme部分をhttpsに変更すると基本的には対応が完了しそうな雰囲気ではあるけれど、過去に貼っちゃった画像なんかはhttpで参照されそう。うーむ、まぁ、SSL化は最初からやった方がいいんだなと思いつつも、WordPressもschemeなしのURLで画像のURLを書いておいてもらえると便利なんだけどなぁと。
あとは、nginxでHSTSを返すようにしてみた。検索エンジンなんかも、HSTSを参照してSSLで参照してくれたりするんだろうか。ちょっと試してみるか。
memcachedをビルドした後、make testを実行するために、いくつかperlのモジュールが必要なので、そのPerlモジュールをメモ。実行環境はAmazonLinux 2014.09。
sudo yum install perl-Test-Harness
sudo yum install perl-Test-Simple