真面目で優しいシステムエンジニアは損をする13~性能テスト~

どうも!ヒグッティ(ヒグッティ@システムエンジニア)です!
私の実体験を元に真面目で優しいシステムエンジニアが損をすることについて書いていこうと思います。 これはフィクションです。とあるシステムエンジニア、ヒグッティの物語です。
前回は トレードオフの話について書きました。

真面目で優しいシステムエンジニアは損をする12~トレードオフ~

今回は性能テストの話です。では、お楽しみください!

性能テスト

トレードオフのせいで4月から新計算機能の開発が始まることになりました。しかも、3月いっぱいで向井さんは交代予定…中々にキツイ状況です。
そんな中、3月上旬から性能テストに入りました。3月末までの一ヶ月間で終わらせる必要があるので割とキツいスケジュールです。
性能テストでやることは以下でした。
1∶性能テスト計画書、テストシナリオの作成
2∶性能テスト仕様書の作成
3∶テスト実施
4∶エビデンスの作成
5∶性能テスト結果報告書の作成

まずは性能テスト計画書、テストシナリオの作成です。作成自体は難しくないのですが、性能目標(指標)を決めることが面倒くさいです。
まずは既存の処理時間を計測します。大体、一ヶ月分の処理時間を平均して性能目標とします。既存の処理時間がわからない場合は計測してもらうか、自分で計測します。既存保守の人でもよくわからない処理があり、計測も大変でした。計測前の条件などを揃える必要があるからです。あとは利用するデータの中身や量をお客さんと合意を取りながら進めていきます。

ヒグ∶要件定義で性能目標が記載されてない処理があるんですけど、これは現行と同程度の処理時間となることを確認しようと思いますけど問題ないですか?
PM∶そうだね。OKです!要件定義には性能の条件とかって他に何かある?
ヒグ∶そうですねー。データ量が2倍でも耐えられるようにしろとか、同時アクセス数が1.2倍に耐えられるようにしろとかですね。
PM∶了解です。データの準備はどうします?
ヒグ∶本番環境で実際に処理されたファイルを使います。データ量が2倍必要なので日付などのデータを変更して水増しします!
PM∶了解です。計画書にさっき言ったデータの事も書いておいてくださいね。あと性能目標も!
ヒグ∶了解です!

Web画面で同時アクセスや負荷を与えるためにJmeterとbadboyを使いました。結構便利です。Jmeterはレスポンス結果をレポートにまとめてくれたりするので、オススメ!
その後の作業は向井さんの頑張りで問題なく進みました。
3月までの作業は向井さんの頑張りでシステムテスト、性能テストが何とか終わりました。性能テストは目標の時間内に処理が終わらなかったりしましたが、8月までの申し送り事項として後回しにしました。

性能問題で考えること

ここからは性能をプログラムの観点から見たときの個人的な見解です。
プログラムの性能問題について考えるとき、以下を気にしています。
1∶for文などの繰り返し処理が多いか。
2∶ファイルアクセスが多いか。
3∶DBの接続が多いか。
4∶SQLの性能。
5∶addBatch的なものを使っているか。

それぞれ対応方法や解決策としては、
1∶処理が終わった時点でbreakする。また、SQLの検索結果を一度、配列などに入れてメモリに持ったままループしていないか確認が必要。配列に入れずフェッチした結果で処理するように修正したほうが良い!
2∶ファイルアクセスしながら処理をする。ファイルをopenしてからcloseするまでの流れで処理を行う(いちいちファイルをopen,closeしてたら遅いよね…)。
3∶DBのマスタの値とかは極力キャッシュする。Web画面はキャッシュはあまり使わないほうが良いよね。バッチ処理ならキャッシュしたほうが良い。
4∶ケースバイケースだけど…
where句などで値を比較する時、関数を使っていないか関数を使うとインデックスが効かないから遅い。
データ数の少ないテーブルから結合していく。テーブルの中身を気にしないといけないので結構忘れがち。
あとは各DBが提供するanalyzerを見てって感じです。nestedloopなのかハッシュなのかとかsqlがテーブルにアクセスする方法を知っておくと強い。
5∶Javaで処理するときなどにaddBatchを使います。addBatchはDBへの登録、更新を一括に行う機能です。100件単位で登録、更新したりします。よくあるのは1件ずつコミットしてるパターンですね。これは遅すぎるので、修正が必要です。

今回の性能テストで苦しめられたことは以下です。
・where句で値を比較する時、関数を使っていたため、遅い。
対応後は1時間かかっていた処理が3分くらいで、終わりました。プログラム的に同じような書き方なのに、こんなにも性能が変わるなんて面白いですよね(笑)特に以下のような書き方は注意です。
WHERE trim(a.data)=’DATA’
インデックス外れます。めちゃくちゃ遅いです。
私の感覚では性能問題の9割はSQLとDBのインデックスにあると思ってます!
性能テストは諸々ありましたが、何とか終了。向井さんは優秀でした。性能テスト結果報告書を私が作成し、残りのエビデンスは向井さんがまとめてくれました。お客さんにもレビュー依頼出しましたが、納品前で忙しそうでした。今でも見てくれたか謎です。

3月末。スケジュール通りの作業が終わり、一段落したという感じでした。あとは細かい機能や新計算機能、分析機能の改修だけです。と言ってもまだやることありますが…疲れた…あとちょっとだ…最近、朝、体が重くてやばいな…朝少し休まないと出社できない日もあるくらいです…少し休もう。東海オンエア見てゆっくりしたいねー。

健康

話は変わります。3月下旬頃から私の体に異変が発生しました。突然、アトピー性皮膚炎を発症しました。最初は膝裏が痒いなーという程度でしたが、いつの間にか膝裏を掻き壊してしまい、出血するまでになってしまいました。同じ現象が肘の内側、首まわり、頭皮にまで拡がってしまいました。仕事が忙しいという理由で病院には行きませんでした。
お客さんも心配してくれましたが、PMさんは「このプロジェクトやってると一人くらいは肌が荒れるんだよねー!前のプロジェクトの時もなってる人いたよー!」っと言っていました。
しかし、とうとう痒くて夜も眠れない日々が続いてしまいました。さすがにまずいと思った私は病院に行きました。それは4月の中旬くらいでした。もう少し早く行っておけばよかった…塗り薬を貰い1週間位つけると夜もぐっすり眠れるようになりました。本当に薬って素晴らしい。ステロイド系でしたが、構わず使いました。医者の指示した期間塗り続けるのは大事ですね。
やっぱりストレスなのかなー。今まであまり肌トラブルになったことがなかったので自分でもびっくりしています。今でもたまに発作的に痒くなります。一度、壊れると中々治らないですね…

まとめ

  • 性能目標は最初に決めること。既存処理の時間が計測できるか確認しておくこと。
  • 都合の悪いことを後回しで申し送り事項とし、その場を乗り切るのもアリ。本当はよくない。
  • 性能問題はSQLとDBのインデックスが9割関係してる(私の経験)
  • ストレスでアトピー性皮膚炎になるかも。病院は早めに。医者の言う事は聞いたほうが良い。

スポンサーリンク