へっぽこSEのお仕事ライフ

お仕事コラム　～パフォーマンスチューニング～

ITシステム構築時にバグよりやっかいなもの、神経をすり減らすもの、それがパフォーマンスチューニング。

「バグ」は狭義の意味で、「プログラムが決めたとおりに動かないこと。」
「パフォーマンスチューニング」とは「ユーザ要件に見合ったパフォーマンスを実現出来るように調整すること。」

バグが絶対的なものであるならば、パフォーマンスは相対的なもの。

もちろん、リリースするシステムにバグが残っていてはいけない。しかし、実際問題、致命的なバグでなければ（ＥＣサイトで料金計算が正しく出来ていない、というのは問題外の致命的なバグ）、お客様から猶予期間をいただけることもある。
時期を延ばしても良かったり、また、バグに対する真摯な姿勢が顧客満足度を向上させたり。。。
バグがあったとしても、システムに対する満足度が高いこともある。

そして、バグを改修すれば、お客様も開発側もはれてすっきりした顔になれる。（もちろん類似バグが残っている、などはもってのほか）

しかし、パフォーマンスチューニングと言うものは、上に書いたバグの真逆をゆく。

バグを「唯一の解に落とし込める数学」に例えるのであれば、パフォーマンスチューニングは、哲学であったり国語であったり唯一の解を出せないもの、人によって解釈が異なるもの、に位置づけられるだろう。

パフォーマンスは概して相対的なものだ。
通常、システム設計時にパフォーマンス要件というものを規定する。
・同時に何ユーザまでアクセス可能とするか？
・これだけの負荷をかけても、応答時間を～秒以内に納める。
＃例えば、100ユーザが同時にファイルをアップロードしたとすると、その部分にアクセス、処理が集中することになるが、その場合でも3秒以内でファイルをアップロード出来るように処理をするだとか。。。

規定をして、実際に、ツールを駆使して、試験している。
要件を満たすためにパフォーマンスチューニングもする。
※パフォーマンスチューニングは、本来、システムリリース前にやっておくべきこと。やる時期が遅くなればなるほど自分（開発側）の首をしめることになる。

そもそも、実際にシステムを使ったときにそのパフォーマンスで満足の行く保証はない。

たとえ、初期のパフォーマンス要件を満たしていたとしても、ユーザから不満の出る可能性はある。

そんな時のパフォーマンスチューニング。

これは、どんな優秀な技術者が集められてきても解決できるとは限らない。パフォーマンスチューニングには、スキルはもちろん、経験、そして勘が求められる。
＃いや、ホント経験者の勘で解決することが多いんですよ。。。

パフォーマンスネックになっているかを特定するだけでも、結構難しい。
プログラムが悪いのか？設定が悪いのか？ＤＢが悪いのか？ＳＱＬ文が悪いのか。。。？？？
バグよりも原因が多岐にわたる。

いざ特定して、解析して、改善したとしても、劇的に早くするのは難しい。

たとえ、パフォーマンスが改善しても、ユーザの中では
「遅い、遅い！！」
であったり
「処理が重い！！」
という意識が植え付けられているから、あっさりユーザが
「パフォーマンスチューニングをした結果、処理が軽くなって、ＯＫ！」
と一筋縄で言ってくれることはほぼないだろう。。。

パフォーマンスチューニングは、かなりユーザがシステムを操作する時に不愉快な気分を与えているので、パフォーマンスチューニングでどれだけすごいスキルを発揮したからと言って、顧客満足度が上がることは少ないだろう。。。

そして、顧客も開発側もすきりいかない気分が続くことになる。。。

	SEを極める50の鉄則著者：馬場史郎 / 日経コンピュータ編集部出版社：日経BP社／日経BP出版センター本体価格：1,700円
楽天ブックスで購入する

!へっぽこSEのお仕事ライフ!トップ

SEO		[PR] 爆速!無料ブログ無料ホームページ開設無料ライブ放送