Subversionの小技
覚えておくと便利。
(ノ・・)ン。。。。。。(((●コロコロッ
無視リスト入り
$ svn propedit svn:ignore [direcotory name]
cgi実行属性追加
$ svn propedit svn:executable *.php
リポジトリ変更
$ svn switch FROM TO
リポジトリサーバ変更
$ svn switch --relocate FROM TO
まだまだ、使いこなす道は遠いな。
Apache1系でもできるキャッシュコントロールによる負荷対策法
共有レンタルサーバでも効果ありそう
(ノ・・)ン。。。。。。(((●コロコロッ
＿〆(。。) ヨクカンガエレバソウダヨネェ…
(ノ・・)ン。。。。。。(((●コロコロッ
# 1 YEAR
<FilesMatch "\.(ico|pdf|flv)$">
Header set Cache-Control "max-age=29030400, public"
</FilesMatch>
# 1 WEEK
<FilesMatch "\.(jpg|jpeg|png|gif|swf)$">
Header set Cache-Control "max-age=604800, public"
</FilesMatch>
# 2 DAYS
<FilesMatch "\.(xml|txt|css|js)$">
Header set Cache-Control "max-age=172800, proxy-revalidate"
</FilesMatch>
# 1 MIN
<FilesMatch "\.(html|htm|php)$">
Header set Cache-Control "max-age=60, private, proxy-revalidate"
</FilesMatch>
＿〆(。。) ヨクカンガエレバソウダヨネェ…
XREAをSubversionリポジトリにする。
いけるな！これは。
(ノ・・)ン。。。。。。(((●コロコロッ
格安サーバXREAはそれはもうガンガン使っています。
最近は新しいサービスCoreServerも利用してます。
それはそれは快適。
お隣さんの調査は念入りにしないと、
重たいサーバを選んでしまうのが欠点か。
関連記事:
Category: XREA.COM
Xrea(Coreserver)でサービスを開始するにあたって、
開発の際のSVNのリポジトリをどうにかこちらに遷したいなぁと思った。
強力なXREAサーバがSVNリポジトリになれば最強と言える。
これにtracが載ればもう完璧。
(まぁそれは無くても良いけど)
以前の記事、
XREAで最初にやったことで言ったように、
XREAにはsvn, svnadminコマンドがデフォルトで導入されている。
(昔のサーバは知らんが。)
svnserveコマンドも実装済みのようなので、
理屈で言えばsvn+sshでいけるはずだ。
というのでちょっとやってみた。
(ノ・・)ン。。。。。。(((●コロコロッ
格安サーバXREAはそれはもうガンガン使っています。
最近は新しいサービスCoreServerも利用してます。
それはそれは快適。
お隣さんの調査は念入りにしないと、
重たいサーバを選んでしまうのが欠点か。
関連記事:
Category: XREA.COM
Xrea(Coreserver)でサービスを開始するにあたって、
開発の際のSVNのリポジトリをどうにかこちらに遷したいなぁと思った。
強力なXREAサーバがSVNリポジトリになれば最強と言える。
これにtracが載ればもう完璧。
(まぁそれは無くても良いけど)
以前の記事、
XREAで最初にやったことで言ったように、
XREAにはsvn, svnadminコマンドがデフォルトで導入されている。
(昔のサーバは知らんが。)
svnserveコマンドも実装済みのようなので、
理屈で言えばsvn+sshでいけるはずだ。
というのでちょっとやってみた。
PHPのセッションを考える
難しいな。
(ノ・・)ン。。。。。。(((●コロコロッ
結論・・・というか落としどころは、
ってところか。
Yahoo!は正しいな。
セッションって言う概念はどのぐらい前から定着したのか。
今ほどセキュリティについて敏感になっていない頃は、
FormタグやURLにID、パスワードがゴンゴンかいてあった。
URLにPHPSESSIONIDというのを見かけるようになったのはPHP3のころ。
確かphplibというライブラリ集があって、
その中の一つだった記憶がある。
PHP4になって内部に組み込まれたんだったか。
クエリストリングからクッキー利用に仕様変更されていた。
そのころから今に至るまで、
PHPのセッションの仕組みって変わっていない。
CookieにIDを格納して、
それをキーにストレージからデータを取ってくる。
「そんなの[セッション]じゃねーよ」とJAVAユーザーに散々けなされた記憶もあるな。
(だったらjsessionってなんだよといいたい。)
確かに厳密な意味でのセッションではないが、
単発アクセスの集合体であるWebアプリではこの手法が主流になっていると思う。
さて、今回考えようと思ったのは、
私はセッションストレージにはmemcachedを使っていた。
これ自体にも議論は必要かもしれないが、
アプリケーションの規模からいうとこれで事足りる。
つまり、サーバが壊れたら「バックアップから復旧」状態で、
フェイルオーバーできるほど台数がないのだ。
(これで一日数百万ぐらいなら捌ける。)
が、そう言うわけにも行かないアプリケーションを作成することになり、
もう一度考えることにしてみた。
セッションを実装するとして、
そのストレージの選択肢として
ファイル(NFS)、データベース、memcachedとあると思う。
これらで最適なものってどれかちょっと考えて、
今後の指標にするか。
(ノ・・)ン。。。。。。(((●コロコロッ
結論・・・というか落としどころは、
ストレージはデータベース
ってところか。
Yahoo!は正しいな。
セッションって言う概念はどのぐらい前から定着したのか。
今ほどセキュリティについて敏感になっていない頃は、
FormタグやURLにID、パスワードがゴンゴンかいてあった。
URLにPHPSESSIONIDというのを見かけるようになったのはPHP3のころ。
確かphplibというライブラリ集があって、
その中の一つだった記憶がある。
PHP4になって内部に組み込まれたんだったか。
クエリストリングからクッキー利用に仕様変更されていた。
そのころから今に至るまで、
PHPのセッションの仕組みって変わっていない。
CookieにIDを格納して、
それをキーにストレージからデータを取ってくる。
「そんなの[セッション]じゃねーよ」とJAVAユーザーに散々けなされた記憶もあるな。
(だったらjsessionってなんだよといいたい。)
確かに厳密な意味でのセッションではないが、
単発アクセスの集合体であるWebアプリではこの手法が主流になっていると思う。
さて、今回考えようと思ったのは、
セッションストレージ
私はセッションストレージにはmemcachedを使っていた。
これ自体にも議論は必要かもしれないが、
アプリケーションの規模からいうとこれで事足りる。
つまり、サーバが壊れたら「バックアップから復旧」状態で、
フェイルオーバーできるほど台数がないのだ。
(これで一日数百万ぐらいなら捌ける。)
が、そう言うわけにも行かないアプリケーションを作成することになり、
もう一度考えることにしてみた。
セッションを実装するとして、
そのストレージの選択肢として
ファイル(NFS)、データベース、memcachedとあると思う。
これらで最適なものってどれかちょっと考えて、
今後の指標にするか。
powered by 
