Webコンサルタントの愚痴とPHP,Perl,MySQL,オープンソースなどの技術的覚書。オープンソースの翻訳ファイルも作成中
Tracは標準では全てのリクエストがcgi経由なので、よほどのマシンでないかぎり動作は非常にもっさりした感じになる。
通常のcgi経由で、100回リクエストを発行した場合(abコマンド)
Connection Times (ms)
min mean[+/-sd] median max
Connect: 12 12 0.2 12 13
Processing: 381 386 3.1 386 394
Waiting: 348 353 2.7 353 362
Total: 393 398 3.1 398 406
Percentage of the requests served within a certain time (ms)
50% 398
66% 400
75% 400
80% 401
90% 403
95% 404
98% 406
99% 406
100% 406 (longest request)
平均して秒間2.5件程度はさばける感じだ。
さてチューニングだが、通常2点の対応をする。
順に手順を書く。
まずは、mod_pythonを導入する。CentOSなら
次に、apacheの設定ファイルを変更する。
cgi経由で利用する場合は、以下のような設定になっていると思われる。
単に特定のURLの場合、Tracの環境変数を設定するのと認証の設定をしているだけ。
こいつをmod_python対応にすると、こうなる。TRAC_ENVの環境変数を外して、PYTHON_EGG_CACHE以下の5行を自分の環境に合わせて変更する。
以上が終わったら、apache再起動を実施だ。
上述の通り、cssやjsもcgi経由で読み込まれているので、こいつを直接参照するように変えた方が良い。
Tracでは通常、画像やjs等の部品が/usr/share/trac/htdocs/に配置されており、こいつを直接参照するようにするには以下の手順になる。
次にtrac.iniを開く。中にhtdocs_locationという設定項目があるので、
のように設定する。
最後にまた性能を見てみる。
Connection Times (ms)
min mean[+/-sd] median max
Connect: 12 12 0.2 12 13
Processing: 19 27 50.2 19 377
Waiting: 18 26 50.2 19 376
Total: 31 39 50.3 31 390
Percentage of the requests served within a certain time (ms)
50% 31
66% 32
75% 32
80% 32
90% 35
95% 49
98% 388
99% 390
100% 390 (longest request)
ということで、10倍程度の性能向上が出来ていることが分かる。
こりゃ絶対やらないといかんでしょ。
※abコマンドでは画像やcssは読み込まないので、単純にTracのページの性能になる。
会社で、「もう俺は知らん。後は任せた。」といって、机ひっくり返して帰る。
一生の中で一度はやってみたい。
自分がいなくてもまわるチームをつくろう!
著者/訳者:山口 正人 豊田 圭一
出版社:明日香出版社/クロスメディア・パブリッシング(発行)( 2008-01-17 )
定価:¥ 1,470
単行本(ソフトカバー)
ISBN-10 : 4756911552
ISBN-13 : 9784756911551
先週末偶然行った本屋で店頭に並んでいて、タイトル買いしてしまった。
うーーん。この手の本に反応して買ってしまうということは、それだけ自分が悩んでいるということなのだろうね。あとは自己評価高すぎるかも知れないが、自分がいないとチームが回らなくなってしまう気がする。これは今のうちに改善しておかないと、安心して転職できないからな~。
何はともあれ、早く自分がいなくても回るチームを作らないといけない。
Google,オープンソースのWebブラウザ「Google Chrome」を公開へ:ITpro
米Googleは米国時間2008年9月1日,オープンソースのWebブラウザ「Google Chrome」を開発したことを公式ブログで発表した。9月2日にWindows用のベータ版を世界100カ国以上で公開する。
とりあえずWeb系の仕事をしている身としては
ってのと両方だね。
レンダリングエンジンにWebkitを使ってて、オープンソースってことなので、早速実装見てみよう。
・・・って日本時間2日23:54現在まだ公開されていない。時差か・・・。
ラクをしないと成果は出ない
著者/訳者:日垣 隆
出版社:大和書房( 2008-05-23 )
定価:¥ 1,500
単行本(ソフトカバー)
ISBN-10 : 4479792368
ISBN-13 : 9784479792369
昨日ブックオフに行って見つけた本。今年の5月初版で、有名な著者だったから、まだ500円したよ(笑
この人の文体は読みやすい。夕刊ゲンダイやメールマガジン等、軽い感じの文章を書くのにも慣れているのだろうか。ローラーしながら1時間で読み終えた。読後感としては・・・、前書きと後書きは面白かったんだけど、あとは、どっかで聞いたことあるような感じかなぁ。。何度も読み返すってよりは、さらっと読んで自分の使えるところだけ取り出すといいかも。
そうはいいつつ気になった項目を抜粋しておく。
塹壕よりScrumとXP
Scrum and XP from the Trenches v.2.2(上記の日本語訳PDF)
日本語で130ページある、Scrumの実践本。これが無償で配布されていることに驚く。内容も結構面白かった。これからじっくり読む。
ということで、平均5時35分。やっぱり週末に目覚ましかけないで寝ると、起床時間が遅くなっている。これは仕方ないような気がするが、やはり出だしが遅いと一日がグダグダになってしまう傾向にあるので、改めた方がいいかなぁ~。
Joel on Softwareによるソフトウェア開発チームの評価について、あちこちでエントリがあったので便乗。
このテスト、12項目あるが、12点は完璧、11点は許せる範囲、10点以下だったらその組織は深刻な問題かかえている、とかいってしまう厳しいテストだ。
はてなは12点満点。
アプレッソは10点
ちなみに自分の所は、1,2,4,5,6,7、9、12で、8点。ちょっと甘目かも知れないけど、いま目指している所で、順次適用中なので、そのように採点してみた。
ただ、大事な事は、「成し遂げたい目標のために、今何をやるべきか、この先何をやるべきかを決めたら、腹くくってやり続ける」ってことだ。色々な本に色々な事が書いてある。同じことが書いてある場合もあれば矛盾する場合もある。でも一度決めたら自分が納得して良し悪しが分かるまで徹底的にやるしかない。中途半端にあちこち齧っては方向転換を繰り返すような組織ではいかん。
1. ソース管理システムを使っているか?
2. 1オペレーションでビルドを行えるか?
3. 毎日ビルドを行うか?
4. 障害票データベースを持っているか?
5. 新しいコードを書くまえにバグを修正するか?
6. 更新可能なスケジュール表を持っているか?
7. 仕様書を持っているか?
8. プログラマは静かな労働環境にあるか?
9. 買える範囲で一番良い開発ツールを使っているか?
10. テスト担当者はいるか?
11. プログラマを採用するときにコードを書かせるか?
12. 「廊下での使い勝手テスト」を行っているか?
使っている。Subversion。少なくとも最近全案件で必須にしていて、ソースだけじゃなく、ドキュメントやテストコードも対象範囲にしているから、まぁ問題ないだろう。しかし一方で静的サイト構築案件をやっているチームだとこれが出来ていない。自分の管轄ぢゃないけど、いつもデグレしたとか、大騒ぎしている。
DBに初期データ登録して、設定変更して、どうのこーのして、みたいなことは順次止めている。昔の協力会社が作った糞なソースなんて、IF文で、快活環境だったらこっちに繋げて本番環境だったらあっちに繋げるみたいな記述があって、本番用にはコンパイルしなおす、とかいう驚愕の実装があったな。最近は、デプロイ⇒即稼動前提にしているし、初期データの投入もインストーラ化しちゃうから問題ないだろう。
そもそも俺らはスクリプト系ばっかだ。ビルドって概念は無い。まぁ毎日自動回帰テストするかどうかって聞かれればしていない。CruiseControlとかPHPUnderControlとか使うと良いのは分かっているが、まだ出来ていない。
Tracで全部管理。新規要望も不具合もTracに突っ込んで、チケットドリブンで開発。沢山のメールに追われてどの不具合が直し終わった/終わってない、とかの苦労をすることはなくなっている。個数が見えると減らしたくなるのが人情だ。
そりゃそうだよ。テストコードが全部書けているわけではないところが痛いところだが。
普通にある。まぁたまに納期だけ先に決まったスケジュールがあるが、そういう場合は実装機能を減らす。それも許されなかった案件があるが、品質はとてつもない。もうそんな経験はしたくないな。
普通に概要設計、詳細設計、テスト仕様書・・・と揃っているものもあれば、テストコードだけが揃っているものもある。但し仕様書は所詮中間生成物なので、個人的には大量なものは要らないと考えている。設計の思想と、本当に重要な箇所だけに絞れば良い。あとはテストコードが仕様を明らかにしてくれる。
こりゃダメ。とにかく電話が鳴りすぎ。思考を中断されると、生産性は格段に低下する。家でソース書くと会社の数倍のパフォーマンスは出るな。
これは口をすっぱくして言っている。人的コストが一番高いのだから、生産性をあげるためには、必要な道具は揃えるべきだ。僕のところだと、全員パソコン2台以上、メモリも増設、デュアルディスプレイもOKで、20インチ以上の環境。良いものが出たらどんどん買い換えている。
開発ツールは、Eclipseとか、Subversionとか、デファクトスタンダードに揃えている。
この間やった案件ではいたんだけどね。ひたすらSeleniumでテストを記録しては、デイリーで実行したり、モンキーテストしたり。ただ全部の案件でやるのは無理だなぁ。テストはテストのための能力が必要だとは思う。
これやりたい。けどやっていいのかなぁ?一応ブログの有無は聞いている。アドレスは聞いていないけど。でもやっぱり会社のためにも本人のためにも、お互いが理解しあった上で採用した方が良いとは思う。人事と親分に相談してみるか。
まぁやっているように思う。俺なんかは特に、作ったものは直ぐ見せたい人だし。
現行システムの見える化,どうしていますか?:ITpro
http://itpro.nikkeibp.co.jp/article/OPINION/20080825/313313/
「見える化するよい方法があれば,ぜひ教えてほしいよ」――。取材で訪れたある製造業のIT部門に所属するAさんはこうぼやく。Aさんは最近,生産管理システムの刷新に伴い,現行システムの調査に乗り出した。ところが,過去に各プログラマがソースコードを次々とコピーして修正を加えた結果,同じようなソースコードがあちこちにあった。どれが信頼できるソースコードなのか分からない。これじゃあプロジェクトが始められないと,Aさんらは数カ月をかけて全ソースコードを一つずつ確認する羽目になった。Aさんは言う。「現行システムを見える化する“魔法の杖”はないものか。結局,目視による地道な調査をするしかないのか」と。
えーと、こんなソース調査するのやめて、改めて要件確認して、不要機能も選別して、作り直した方が良いと思われ。
ちなみに「現行システムを見える化する“魔法の杖”」はある。使っているユーザに、聞きに行けば良いだけだ。その仕様が正しいのか業務で使えるのかを決めるのはエンドユーザーだ。ソースだけ見たってそんなもん分からんよ。
部下が使っていたPCがちょっと前に壊れて、新しいのを買いつつ保証期間内なので修理したみたいなんだけど、結局そのPC使わないらしいので、バッテリーだけ貰った。
これで長野出張の際に「バッテリーがneeeeee」みたいな悲しい思いをしなくて良くなる。
そういえば、昔まだ競馬場に行って馬券を買っていた頃、ノートPC持って行って色々やってたんだけど、その時も替えのバッテリー持参で行ってたな~。東芝のDynabookSS3010。社会人1年目の冬のボーナスで買ったような記憶がある。当時にしては、超軽量薄型で画期的だったと記憶している。
その前も東芝のリブレット30かなんかを使ったなぁ。そのうち使わなくなって知り合いに譲ってしまったが。
日記 PHP オープンソース Linux Perl フリーソフト Trac wordpress 自宅サーバ phpMyFaq Plugin 書評 Delphi apache プラグイン セキュリティ アジャイル Ajax/Web2.0 Zope Ruby eclipse Firefox フレームワーク サーバ 翻訳・日本語化 自宅 scuttle CakePHP 文字化け mojavi CMS phpBB OpenVZ Excel LDAP XAMPP ApacheDS 修正 CodeIgniter 生産性向上 仮想化 taskfreak 言語ファイル HTML::FillInForm Ajax mod_security SBM 情報共有 ダウンロード フリーズ 移転 熱暴走 情報公開 メンテナンス 翻訳 格安 アンケート PhpScheduleIt API レンタル