Home > アーカイブ > 2010-04

2010-04

Skypeで毎度出て来るアイツを消す方法

この記事の所要時間: 045

Skypeを使ってて毎度出てきて気になるアイツの話です。

気が付くとイベント一覧に上がってくるこれ。

これはムードメッセージフィード更新のお知らせです。それほど頻繁では無いのですが、ちょろちょろとイベント一覧に通知が来るので何となく気になります。

ずーと放置していたのですが、やっぱり気になるので表示させない方法を探してオフにしました。

まずムードメッセージフィード更新を一切通知しない方法。

「設定」-> 「詳細」にある「コンタクトのムードメッセージフィードをチャットで表示」にあるチェックを外せばok。

これでムードメッセージが更新されてもイベントが上がらなくなりました。

特定のコンタクトだけ通知をオフにするにはコンタクトの設定にある「ムードメッセージをフォロー」のチェックを外します。

あーすっきり。

朝Twitterにメッセージが届く「ついもーにん!」を作りました。

この記事の所要時間: 354

お知らせ:2010/04/26

「ついもーにん!」をご利用頂きありがとうございます。

サービスイン当初は、毎朝全てのユーザさんにメッセージを送信することを想定していましたが、今後は一日数十ユーザさんに変更したいと思います。

結果、メッセージが届く頻度はばらつきはありますが、数日に一度程度となります。

主な理由としては、Twitterのpost制限の回避、そして多くのpostによってタイムラインが @twmorning の発言で埋まってしまう問題を回避するためです。

なおDMでメッセージを登録頂くと、投稿者アカウントがメッセージに含まれますので、よりmentionが反応する機会が増えます。是非これを機会にメッセージを登録下さい。

まだまだ生まれたばかりのサービスですが、今後とも「ついもーにん!」をよろしくお願いします。

朝あなたのTwitterにメッセージが届く「ついもーにん!」を作りました。


@twmorning

朝起きた時、通勤電車の中、会社についた時、ついつい見てしまうのがTwitter。誰かのつぶやきを見るのも面白いですが、やはり自分宛に投稿があると嬉しいもの。それが誰からのステキなつぶやきやお役立ち情報なら尚更です。

そんなほんの少しだけ朝を彩るサービスが「ついもーにん!」です。

朝メッセージを受け取る

メッセージを受け取るにはTwitterで @twmorning をフォローして下さい。

朝あなた宛にメッセージが届きます。

朝天気情報を受け取る

メッセージの他に天気情報を受け取ることもできます。

@twmoringをフォローした後に、@twmoringあてにreplyで以下のコマンドをつぶやいて下さい。

すると翌朝から天気情報が届きます。

なお「大阪」の部分は天気予報を知りたい地方名を入力します。

地方名はこのエントリ下部のリストから一つ選択して入力して下さい。

メッセージを送る

朝届くメッセージを登録することができます。

このメッセージが誰にいつ(どの朝に)届くかは分かりません。見知らぬ誰かの朝をステキなメッセージを届けて下さい。

メッセージの内容は @twmorning に DM を送って下さい。

登録されたメッセージは翌朝以降に @twmorning をフォローしている人に届けられます。

なおメッセージには送信者であるあなたのTwitterアカウントが記載されます。これをきっかけに良い関係が気付けるようにステキなメッセージを送って下さい:D

ご質問、ご要望は

@shin1x1まで。

天気情報の地方名

以下から一つ選択して@twmorningあてにつぶやいて下さい。

天気予報を設定する

  • 稚内
  • 旭川
  • 留萌
  • 札幌
  • 岩見沢
  • 倶知安
  • 網走
  • 北見
  • 紋別
  • 根室
  • 釧路
  • 帯広
  • 室蘭
  • 浦河
  • 函館
  • 江差
  • 青森
  • むつ
  • 八戸
  • 秋田
  • 横手
  • 盛岡
  • 宮古
  • 大船渡
  • 仙台
  • 白石
  • 山形
  • 米沢
  • 酒田
  • 新庄
  • 福島
  • 小名浜
  • 若松
  • 水戸
  • 土浦
  • 宇都宮
  • 大田原
  • 前橋
  • みなかみ
  • さいたま
  • 熊谷
  • 秩父
  • 東京
  • 大島
  • 八丈島
  • 父島
  • 千葉
  • 銚子
  • 館山
  • 横浜
  • 小田原
  • 甲府
  • 河口湖
  • 富山
  • 伏木
  • 金沢
  • 輪島
  • 福井
  • 敦賀
  • 新潟
  • 長岡
  • 高田
  • 相川
  • 長野
  • 松本
  • 飯田
  • 静岡
  • 網代
  • 三島
  • 浜松
  • 名古屋
  • 豊橋
  • 岐阜
  • 高山
  • 尾鷲
  • 大津
  • 彦根
  • 京都
  • 舞鶴
  • 大阪
  • 神戸
  • 豊岡
  • 奈良
  • 風屋
  • 和歌山
  • 潮岬
  • 岡山
  • 津山
  • 広島
  • 庄原
  • 松江
  • 浜田
  • 西郷
  • 鳥取
  • 米子
  • 下関
  • 山口
  • 柳井
  • 徳島
  • 日和佐
  • 高松
  • 松山
  • 新居浜
  • 宇和島
  • 高知
  • 室戸
  • 清水
  • 福岡
  • 八幡
  • 飯塚
  • 久留米
  • 大分
  • 中津
  • 日田
  • 佐伯
  • 長崎
  • 佐世保
  • 厳原
  • 福江
  • 佐賀
  • 伊万里
  • 熊本
  • 阿蘇乙姫
  • 牛深
  • 人吉
  • 宮崎
  • 延岡
  • 都城
  • 高千穂
  • 鹿児島
  • 鹿屋
  • 種子島
  • 名瀬
  • 那覇
  • 名護
  • 久米島
  • 南大東島
  • 宮古島
  • 石垣島
  • 与那国島

Twitter @Anywhere はAPI制限に注意

この記事の所要時間: 214

先日Twitterが公開した@Anywhere。Twitterの機能を手軽に自分のサイトに組み込めるとあって早速試してみました。

follow okに設置

いくつか提供されている機能のうち、一番気になったのはフォローボタン。これを設置すると自分のサイトにフォローするボタンが利用できます。

これは良い、ということで、早速follow okに設置してみました。

検索結果のユーザ一覧にフォローボタンを設置したところ、ほんと簡単にサイト上からフォローができるようになりました。

いやあこれは便利と思ってしばらく使ってみるとフォローボタンが not found という表示に。。。

Firebugで見てみると

何が起こったかとFirebugで見てみると見事に真っ赤っか。というかボタン表示の度にTwitter APIを呼びに行っている。。。

レスポンスを見るとエラーメッセージに「Rate limit exceeded. Clients may not make more than 150 requests per hour」が返ってきています。

これは Twitter APIの呼び出し制限で、1 クライアントIP あたり 150/h 以上の API が実行できないようになっています。(申請により拡張可能。OAuth認証済みは別。また、APIによって制限の有り無しがある。詳しくはこちら。)

API制限に引っかかると他サイトの@Anywhereフォローボタンも同じように制限を受けるので「not found」となりました。

ちなみにAPI制限を受けているPCのグローバルIPを変える(emobileで繋いだ)とフォローボタンが表示されました。

@AnywhereフォローボタンはAPIを叩いてる

これを見るとおそらく@Anywhereは、Twitter APIを叩くJavaScriptライブラリということなのでしょう。よって通常の API 制限と同じ制限がかかります。

特にフォローボタンは表示だけで Twitter APIを呼んでしまうので注意が必要です。

blogに一つフォローボタンを置くぐらいなら問題にはならないでしょう。あくまでクライアント環境からのAPI通信なので、150/h を超えることは少ないかもしれません。

ただ follow ok でやったように 1 ページに多数のフォローボタンを置くようなことをやるとページを閲覧しているだけでAPI制限にかかってしまうので、サイト管理者としてはむやみに置かない方が良いでしょう。

CakePHPとnginx+memcachedで手軽にキャッシュを活用する

この記事の所要時間: 439

nginx+memcachedがめちゃ気になったので試してみました。

元ネタは下記です。

A 53,900% speedup: Nginx, Drupal, and Memcache bring concurrency up and page load time way down | TechnoSophos

nginxをリバースプロキシに利用した構成で、バックエンドの出力をmemcachedにキャッシュしておけば、次回リクエストではnginxがそのキャッシュを読み取ってそのまま出力してくれます。

つまりバックエンドにリクエストを経由させずにnginxから即出力するのでかなりの高速化が見込めるという優れものです。

リンク先ではバックエンドにDrupalを利用していたのですが、ここではCakePHPを利用してみます。

1. 全体構成

リバースプロキシにnginx(Port: 80)を使い、バックエンドにはapache+mod_php(Port: 8080)を使います。

nginxはリクエストが来るとURLをキーとしたキャッシュがmemcachedにあるかを調べます。キャッシュがあればそれをレスポンスとしてそのまま返します。

キャッシュが無い場合はバックエンドにリクエストが飛びます。バックエンドではページ生成処理を行い、出力内容をmemachedURLにキャッシュします。

これにより次回リクエストからはこのキャッシュがnginxから出力されます。

試したバージョンは以下。

  • nginx 0.7.65
  • memcahed 1.2.8
  • apache 2.2.14
  • PHP 5.2.10
  • CakePHP 1.2.6

2. nginx+memcached設定

nginxのmemcached連携を行うためにNginxHttpMemcachedModuleを利用します。NginxHttpMemcachedModuleはnginxをデフォルトでインストールすれば含まれています。

nginx.confを以下のように設定します。

# バックエンド
upstream backends {
    server 127.0.0.1:8080;
}

http {
    #(snip)

    server {
        #(snip)

        location / { 
            # POSTはそのままバックエンドへ
            if ($request_method = POST) {
                proxy_pass http://backend;
                break;
            }

            # memcachedにキャッシュがあればキャッシュを
            # 無ければバックエンドへ
            set $memcached_key $uri;
            memcached_pass     127.0.0.1:11211;
            default_type       text/html;
            error_page         404 502 = @fallback;
        }

        location @fallback {
            proxy_pass         http://backend;
        }
    }
} 

ここで注意が必要なのが「error_page 404 502 = @fallback;」の箇所。

memcachedにキャッシュが無い場合はバックエンドへリクエストを投げるのですが、この箇所を[=]抜きにすると404(キャッシュが無い)や502(memcachedが繋がらない)がステータスコードとして出力されてしまいます。

つまりキャッシュが無い場合だとページ自体はバックエンドが生成した内容が出力されるのですが、ステータスコードが404となってしまいます。

[=] を付けるとバックエンドで出力されたステータスコードがそのままレスポンスとして出力されるので、[=]を忘れないようにしましょう。(はまりました。。。)

3. バックエンドでキャッシュ処理

次にバックエンドで生成した内容をmemcachedにキャッシュします。

まずPHPからMemcacheにアクセスするために、pecl::memcacheをインストールします。

$ sudo pecl install memcache

ここではCakePHPでの処理を想定しており、MemcacheViewHelperというヘルパを作成してキャッシュを行います。

MemcacheViewHelperはafterLayoutメソッドでビューからの出力全体をmemcachedにキャッシュします。

ちなみにHelper#afterLayout()はフレームワークから呼ばれるフックメソッドで、下記のように出力全体に対して処理を行うことが出来ます。例えば文字エンコーディングを変換する時などなかなか便利なメソッドです。

[app/views/helpers/memcache_view.php]

<?php
class MemcacheViewHelper extends AppHelper {
  public function afterLayout() {
    if (!empty($this->params['memcache_view']['is_cache'])) {
      $view = ClassRegistry::getObject('view');

      $memcache = new Memcache();
      $memcache->addServer('localhost', 11211);
      $memcache->set(Router::url(), $view->output, false, 3600);
    }   
  }
}

コントローラでMemcacheViewHelperを読み込みます。キャッシュを有効にするアクションでは$this->params[‘memcache_view’][‘is_cache’]にtrueをセットします。

下のUsersControllerの場合、indexアクションはキャッシュされますが、viewアクションはキャッシュされません。

[app/controllers/users_controller.php]

<?php
class UsersController extends AppController {
  public $name = 'Users';
  public $helpers = array('MemcacheView');

  public function index() {
    $this->User->recursive = 0;
    $this->set('users', $this->paginate());
    // キャッシュする
    $this->params['memcache_view']['is_cache'] = true;
  }

  public function view($id = null) {
    if (!$id) {
      $this->Session->setFlash(__('Invalid User', true));
      $this->redirect(array('action' => 'index'));
    }   
    $this->set('user', $this->User->read(null, $id));
  }
}

これでブラウザからnginx(ex. http://localhost/users/index)にアクセスすると 1 回目はバックエンドにリクエストが飛びますが、2回目以降はmemcachedのキャッシュが出力されます。

4. パフォーマンス

キャッシュの効果を見るために、nginx+memachedを使ったパターンとバックエンドに直接接続した場合とでパフォーマンスを計測してみました。

計測はabで行っています。(-c 100 -n 1000)数値はRequests per secondで、5回行った平均値です。

参考にキャッシュをファイルに出力してnginxから出力するパターンも計測しました。

構成 Requests per second
apache+mod_php+CakePHP
(ダイレクト)
13.814 100%
nginx+memcached 2034.262 14726%
nginx+ファイル(参考) 5806.798 42037%

やはりapache+mod_php+CakePHPよりnginx+memcachedが圧倒的に早いですね:D ここまで大きな差があると使ってみたくなります。

5. memcached or ファイル

上記パフォーマンスを見るとmemcachedよりfileの方がより多くのリクエストを捌いています。

パフォーマンスだけを見るとファイルが有利ですが、memcachedの方はnginxサーバやWebサーバが複数台になった場合にキャッシュの取り扱いが簡単(複数台で共有しやすい)という利点があります。また、memcachedなら有効期限が簡単に付けられるというのもあります。

どちらを使うのが良いかはケースバイケースですが、キャッシュの取り扱いを考えると個人的にはmemcachedが良いバランスかなと思っています。更新頻度が少ないがアクセス数が多いページだけはファイルに出力してしまうという方法もあります。

いかに遅い箇所を経由させずにレスポンスを返すかという視点で見るとnginx+memcachedはまさに願ったり叶ったりの構成です。ここではバックエンドにCakePHPを使いましたが、他のフレームワークでも他のシステムでも他の言語でも何でも理屈は同じです。

多くの環境から操作できるmemcachedをキャッシュエンジンに使うということは、バックエンドを選ばずにキャッシュ機構が使えるということで、これはよく考えられていますね。

Home > アーカイブ > 2010-04

検索
フィード
メタ情報

Return to page top