A Day In The Boy's Life -104ページ目

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

ファーストサーバ のVPS環境では、デフォルトでPHPがセーフモード で動いており、セーフモード環境下で幾つかの関数が制限を受ける ことになります。

その制限を回避・解除する方法を紹介します。



セーフモードを回避する


もっともシンプルな方法は、PHPのセーフモードの制限に従って環境を変えてしまうことです。

例えば、ディレクトリを作成するmkdir関数はセーフモード環境では「処理を行うディレクトリが実行するスクリプトと同じ UID を有しているかどうかを確認します」という制限を受けます。


スクリプトと同じUIDというのは、実行スクリプトの所有者ではなく、Apacheの実行ユーザーになるため、Apacheの設定ファイルからなんというユーザー名で実行されているのかを調べ、そのスクリプトが操作をする範囲のディレクトリを全てApacheの実行ユーザーとすることで回避できます。


セーフモードの制限に引っかかった場合は、下記のようなエラーが出力されます。


Warning: mkdir() [function.mkdir]: SAFE MODE Restriction in effect. The script whose uid is 10001 is not allowed to access /var/www/contents owned by uid 48 

上記エラーのUIDが10001がスクリプトの所有者、最後に出てくる48はApacheの実行ユーザーのUIDです。

なので、スクリプトやmkdirを実行する対象ディレクトリのUIDをApacheの実行ユーザーに変更しておきます。

Apacheの実行ユーザーは、http.conf内に記載されているので、そこから確認すればよいでしょう。


User apache
Group apache

所有者がわかれば、後は変更してスクリプトを再実行してみます。


# chown -R apache:apache ./site_create/


セーフモードを解除する


注意) これは非推奨のやり方で、設定することによって適切なサポートを受けられなくなる可能性があります。設定する際には、自己責任でバックアップなどを取った上で実施してください。


VPS環境下では、PHPやApacheの設定の幾つかが仮想ソフトウェアによりコントロールされています。

セーフモードも同様に、PHPの設定ファイル(/etc/php.ini)を変更しても有効になりません。

というか、デフォルトでセーフモードはOFFになっているのに、phpinfo関数で見てみるとセーフモードがONで動いていることがわかります。


で、このVPS環境で強制したい設定の幾つかをまとめた設定ファイルが存在します。

設定ファイルのパスは、環境(運用しているドメインなど)で異なりますが、


/var/www/vhosts/localhost.localdomain/conf/httpd.include

あたりにあると思います。

この中で、


<IfModule sapi_apache2.c>
    php_admin_flag engine on
    php_admin_flag safe_mode on
    php_admin_value open_basedir "/var/www/vhosts/localhost.localdomain/httpdocs:/tmp"
</ifmodule>
<IfModule mod_php5.c>
    php_admin_flag engine on
    php_admin_flag safe_mode on
    php_admin_value open_basedir "/var/www/vhosts/localhost.localdomain/httpdocs:/tmp"
</ifmodule>


という箇所があるので、「php_admin_flag safe_mode on」という設定をoffに変更します。

設定を変更した後は、Apacheプロセスを再起動すればセーフモードが解除されます。





フォローする人が増えてくるにつれタイムラインの情報量が爆発的に増えてきます。

こういった場合に、リストを使えば整理しながら特定の人やグルーピングした人たちのつぶやきを追いかけることができるようになります。


このリスト機能はリリース当初から、混沌としたタイムラインを整理するのにとても便利なものだという意見がある一方で、疎外感を受ける(俺もリストに加えろという心理)という意見があります

これは、リストそのものがグルーピングするゆえに何かをまとめ、何かを排除するという意味が含まれているので仕方ないことです。

リストとは元々そういう意味があるわけですから。


ただ、Twitterのリストにおいては他とは違う疎外感を強める要因が多いんじゃなかろうかとも思ったりします。


1. リストへの登録は読むという意思表示

2. フォロー以上リスト未満

3. 何にも属していいないということの見える化


なので、フォロワーが減るよりリストから除外されるほうが凹んだり。



1. リストへの登録は読むという意思表示


ある人に興味を持った場合、フォローするだけでその人のつぶやきはタイムラインへ流れてきます。

これだけで、その人のつぶやきを読みたいという意思表示にもなるわけですが、リストというものが活用されだすと、その人に自分のつぶやきを追いかけてもらうためにはもう1ステップ必要になってきます。


ある程度フォロー数が増えてくるとタイムラインでの発見というのは偶発的になってきますので、たまたま同じ時間にいた人のつぶやきだから見れたという状況になります。

強く興味を持っている人のつぶやきは逃したくないのであれば、リストに登録しておけば追いかけやすくなります。


ここで、タイムラインにだけ表示するということとリストに登録するということの差別化が生まれてきます

フォローするだけでなく、リストに登録するという段階的な承認作業というものが出てくるわけです。

とりあえずフォローはするけど、よくやり取りしている人はリストに登録してそっちで追いかけている、というような使い方をしている人もいると思います。


これは、自分のつぶやきの重要度の1つの指標にもなったりします。

リストへ登録すると言うことは読みたいと言う心理を表れとも受け取れるわけで、逆に言えば、リストから外すというのは期待したものと違うという意思もあるのかなと。



2. フォロー以上リスト未満


フォローの後に、本当につぶやきが読まれるかどうかがリストにかかっているのだとすれば、そこに大きな隔たりが出てきます

リストというものが追いかけたい人の整理に役立つということは、フォローすることの意味というのはリストが無かったころに比べ敷居が低くなっていることにもなります。


とりあえずフォローされたの関係の先にリストに登録されたという関係があるわけで、自分が誰のどのリストに登録されているかというのが見えることで、宙ぶらりんな関係が見えてしまいます

リストに登録している人だからリプライに反応しようことはないでしょうけど、自分のつぶやきの重要性のレベルを感じてしまう要素になります。


リストが無かった頃は、誰の発言でもその人がフォローしていた人はフラットに情報が流れているのに対し、リストができたことで自然と振り分けがなされています。

フォローされたとしてもリスト未満と言う関係が見て取れるわけです。
つまり、そのフォローされた先にあるリストという超えられない壁の存在を知ってしまうことにもなります。



3. 何にも属していいないということの見える化


グルーピングした場合に、必ずその他というものは生まれます。

「エンジニアの人」とグルーピングすれば、その他は「エンジニア以外の人」になるわけです。


しかし、Twitterのリストは必ずどこかに属しているような振り分け方はされません

Aというリストに追加するかどうかという判断はされますが、A以外のリストというのは(本人が意図的に作成し、振り分けない限り)存在しません。

先に書いた宙ぶらりんな関係がそこでわかってしまったりもするわけです。


リストによって、つぶやきが重要性を帯びて振り分けがなされているとすると、自分のつぶやきがどこにも属していないと言うことを突きつけられたりもします。

リストの作り方は人それぞれでしょうけど、そのつぶやきを追いかけるために、自分の興味や考えをグルーピング化して作っているのだと思います。

どこにも属していないと言うのは、その人のどの興味にも当てはまっていないことなのかなと。


Twitterのリストは、属していることを見える化している以上に属していないことを見える化してたりもするわけです



まとめ


リストに登録することは、現状それほど簡単ではありません。

こまめに整理しようという意思が必要になりますし、わざわざその人をどのリストに登録しようかと意識しながらタイムラインを眺めているわけでもないでしょう。

または、そもそもリストをあまり活用していないという人も多いと思います。


ここで挙げたことは受けての心理であり、リストを活用する側のことはあまり触れていません。

もちろん活用する場合は、リストは便利なものです。

公にせずともお気に入りの人というのはいると思いますし、そういった人の発言は追いかけたくなるでしょう。


まぁ、Twitterの目的は誰かにとっての特別になることではないので、あまり気にすることは無いのだろうとは思います。

ただ、リストによって見えるものがTwitterのゆるいつながりと言うものを阻害する要因にもなったりしないのかな、と考えてみたわけです。





過去に、WebサーバーとDBサーバーの負荷テストに関するエントリを書いてみましたが、今回はJmeterを使ってメールサーバーの負荷テストを実行してみます。

なお、Jmeterは2010年02月時点で最新のバージョン2.3.4を利用しています。


Webサーバーの負荷テストに関しては、下記をエントリを参考にしてください。


負荷テストあれこれ-JMeterの使い方-


DBサーバーの負荷テストに関しては、下記のエントリを参考にしてください。


JmeterでDB負荷テストをやってみよう!


結果のレポートの見方に関しては、下記のエントリを参考にしてください。


負荷テストあれこれ-JMeter 負荷のかけ方、レポートの見方-


注意)
この負荷テストは大量のメールの送信、受信を行うことも可能になるため必ず自分が責任の取れるところのみで実行するようにしてください。



Jmeterでメール送受信テストをするための環境設定


まず、素のJmeterではメール送受信の負荷テストは実施できません。
必要になる、JavaMailJAF(Java Activation Framework) のライブラリを追加する必要があります。

サイトからライブラリをダウンロードしたら、ファイルを展開し必要なjarファイルをJmeterのlibフォルダへコピーします。


- コピーするjarファイル
JavaMail: mail.jar
JAF: activation.jar


A Day In The Boy&#39;s Life-Jmeterでメール負荷テスト1


これで事前に必要な環境設定は完了です。



メール受信テストをやってみる


Jmeterでメールの受信テストをするには、「Mail Reader Sampler」を利用します。

テスト計画の下にスレッドグループを作成したら、「追加」→「サンプラー」→「Mail Reader Sampler」で追加します。


A Day In The Boy&#39;s Life-Jmeterでメール負荷テスト2


追加したら上図のようにパラメータを指定していきます。


- Server Type
利用するプロトコルを指定します。「POP3」「POP3S」「IMAP」「IMAPS」から選択できます。


- Server
接続するメール(POPまたはIMAP)サーバーです。


- Username / Password
接続時のユーザー名とパスワードを指定します。


- Number of messages to retrieve
サーバー上にあるメールの受信数を設定します。「ALL」を指定すると全てのメールを受信します。


- Delete messages from the server
チェックするとメール受信後にサーバー上のメールを削除します。

繰り返しテストをする場合には、メールが削除されて空っぽになるとまずかったりするのでチェックを入れる必要は無いでしょう。


- Store the message using MIME
負荷テストの結果に、メールのヘッダ情報を含めて保存します。

リスナーに「結果をツリーで表示」を追加しておいた場合、ヘッダの詳細を確認することが可能になります。


パラメータの指定が完了したら、リスナーを追加して負荷テストの結果をレポートで見れるようにしておきます。

「グラフ表示」「結果を表で表示」「結果をツリーで表示」あたりのリスナーを追加しておけば、負荷の状況が把握できるでしょう。

リスナーの設定が完了したら「スレッドグループ」にて負荷のレベルを設定します。

メール受信に関する負荷レベルの調整は「負荷テストあれこれ-JMeter 負荷のかけ方、レポートの見方- 」を参照してみてください。


- 「結果をツリーで表示」の結果

A Day In The Boy&#39;s Life-Jmeterでメール負荷テスト3


メールサーバーから受信したメッセージを1つずつ確認することもできます。

(内容自体は文字化けして読めないですが・・・)

全体のレスポンスを確認したい場合は、「結果を表で表示」から確認し、パフォーマンスの状況を視覚化したい場合は「グラフ表示」から確認すると良いでしょう。



メール送信テストをやってみる


次は、メール送信のテストですがこちらはJmeter内に送信用のサンプラーが用意されているわけではありません。

「BeanShellサンプラー」を利用してメール送信プログラムを書いてあげます。


まずは、スレッドグループの下に「追加」→「サンプラー」→「BeanShellサンプラー」を追加します。

追加した後は、スクリプト欄に送信プログラムを記載します。

下記は、SMTP-AUTH用のサンプルコードです。

書き方は自由ですから、添付ファイルをつけたメールで負荷テストをするということもできたりします。


import java.util.Properties;
import java.util.Date;
import javax.mail.Session;
import javax.mail.Message;
import javax.mail.Transport;
import javax.mail.internet.MimeMessage;
import javax.mail.internet.InternetAddress; 

Properties props = new Properties();

// SMTPサーバーの情報をセット
props.put("mail.smtp.host", "smtp.example.com");
// SMTP-AUTHで送信する
props.put("mail.smtp.auth","true");
props.put("mail.debug", "true");

// SMTPポートの設定
props.put("mail.smtp.port", String.valueOf("25"));

Session sess = Session.getInstance (props);

MimeMessage mimeMessage = new MimeMessage(sess);

// 送信元アドレスと送信者名を指定
mimeMessage.setFrom(new InternetAddress("foo@example.com", "test","iso-2022-jp"));

// 送信先メールアドレスを指定
mimeMessage.setRecipients(Message.RecipientType.TO, "bar@example.com");

// 件名
mimeMessage.setSubject("テスト","iso-2022-jp");

// 送信日時
mimeMessage.setSentDate( new Date());

// 本文
mimeMessage.setText("テストメッセージ","iso-2022-jp");

// SMTPサーバーとコネクション確立
Transport tp = sess.getTransport("smtp");

// SMTP-AUTH用ユーザ名とパスワードを設定しコネクト
tp.connect(null,"foo@example.com","hogehoge");

// メール送信
tp.sendMessage( mimeMessage,mimeMessage.getAllRecipients());

// コネクションクローズ
tp.close();

プログラムができたら、受信のときと同様にリスナーを追加しておきます。

メール送信に関する負荷レベルは、送信プログラム内で大量送信するようなロジックもかけてしまいますが、どれくらいの負荷(コネクションやメール送信数)をかければサーバーのパフォーマンスが落ちるのかなどの結果が分りづらくなるため、基本プログラムはメールを1通送るというようなシンプルなものにして、スレッドグループで調整したほうが無難かと思います。


プログラムにエラーがある場合は、「結果をツリーで表示」内にエラー内容が出てきますので、その情報から
デバッグすることもできます。


- 「結果をツリーで表示」の結果


A Day In The Boy&#39;s Life-Jmeterでメール負荷テスト4



あまり機会はないかもしれませんが、メールの大量送信・大量受信をした際のメールサーバー側の負荷やパフォーマンスをチェックしたいというときにJmeterを利用できるかと思います。


参考: Jmeterでメール配信 @ 覚えたことを忘れない為のメモ