FC2ブログ

某SEの日記

パフォーマンス用語集

アンケートの結果やいろいろな人を声を聞く限り、
パフォーマンスについて問題をかかえている、
もしくは気になっている人は多いようだ。

そこで、来年の課題としてパフォーマンスに対して対応がとれるように
体系的知識を身につけようと考えた。
まず、予習がてらに覚えた用語を自分なりにまとめてみた。


ワークロード:
構築対応のシステムが実行する処理の種類や量を表す。
ユーザおよび同時アクティブユーザ数、トランザクション量、トランザクションの組み合わせなど

応答時間(レスポンスタイム):
サーバーが要求に応答するまでに要する総時間。

スループット:
アプリケーションが単位時間ごとに処理する要求数。

リソース利用:
アプリケーションによるサーバーおよびネットワークリソースの消費量。
CPU、ディスクIO、ネットワークIO、メモリなど。

パフォーマンスガジェット:
制約要因を表すもの。
アプリケーションのある機能が実際使うことができる(許されている)リソース量。
例えば、他システムと相乗りしているので、本アプリはCPUを50%までしか使うことができない場合は
ガジェットはCPU使用率50%となる。
ガジェットイコールパフォーマンス目標値とは違う!!

パフォーマンス目標値:
応答時間、スループット、リソース利用で表されることが多い。
スポンサーサイト



このページのトップへ

アーキテクチャ説明書レビュー

アーキテクチャ説明書のレビューを2ヶ月のプロセストレーニングの集大成として行った。

【記述内容】(項目の目次)
1.はじめに
目的やスコープ、補足が必要な用語について述べている
2.アーキテクチャの目標と制約

3.キャパシティと品質目標

4.アーキテクチャの全体像

5.アーキテクチャの表現

6.ユースケースビュー

7.論理ビュー

8.実装ビュー

9.配置ビュー


【指摘事項】
・予算の制約も考える
→推敲範囲が現時点で何%カバーしているか。
 そして、実績工数はいくつか?
 予算オーバーであればそのアーキテクチャ(計画)は絵に描いた餅になる?!

・アーキテクチャの目標にはもっと定量的なものを設定するべき

・セキュリティについて
→まず顧客セキュリティ標準の有無を確認。
→あればそれを満たすことを目標。なければ社内標準なりを検討。

・パッケージ分割の思想(どういう基準で分けたか)をしっかり書くべき

・アーキテクチャの理由は必ず書いた方がいいというわけではない
→後付的なものならあえていらない。
→自分でもはっきりわかってないものは書かない方がいい。

・俯瞰的な視点からの記述が少ない。
→各論は理解できるが全体としてわかりにくい。

【感想】
アーキテクチャを記述する際の4+1ビューなど勉強したので
各論については何を書くべきかということは理解できて
それぞれはそれなりの文書が作成できたと思う。
ただ、学習中であることもあって
各ビューを記述することが第1目的化してしまっていて
本来要件を実現するのにAがこうであってBであるという
流れを表現するための4+1ビューなのであるが、
逆に4+1ビューで書くということが先にたってしまった。
それゆえに全体としてはそれぞれが唐突で全体の
アーキテクチャ思想がわかりにくい文書になってしまったと反省している。



このページのトップへ

ビジネスロジックを実現するパターン

マーチンファウラー氏が中心になってまとめたPofEAAから学んだことを抜粋。

ビジネスロジックを実現するパターンについて。

1.「TransactionSctipt
トランザクションとして完結する処理(ビジネスロジックとデータの永続化処理)をすべて一つのメソッドの中にまとめて記述するパターン。

メリット:コードが非常に単純
デメリット:同じようなコードがいろいろなメソッドに散在するため、ビジネスロジックの再利用が困難。
→保守性、拡張性↓

2.「DomainModel
概念モデリングで定義したクラスをそのまま利用し、個々のクラスにビジネスロジックとデータを両方を持たせようとしたパターン。

メリット:モデルとコードの乖離が少なくて変更も比較的に容易に出来る。
→保守性、拡張性↑
デメリット:RDBに保存する際には高度なO/Rマッピングが必要。

3.「TableModule
データベースのテーブルごとにビジネスロジッククラスを実装するクラスを用意する。

メリット:ビジネスロジックを実装するクラスの導出が容易。O/Rマッピングも不要。
デメリット:テーブル構造が変わるとビジネスロジックを実装うするクラス構造も変更する必要がある。


このページのトップへ

アーキテクチャ確定作業について2

アーキテクチャ確定作業の
・非機能要件、前提・制約条件の定義。
・アーキテクチャ目標と推敲機能選定。
における注意点(学んだこと)を箇条書き

可用性に関する目安:
可用性99%の場合はサーバ構成がシングル(冗長化しない)でも可能と言える。
それ以上の可用性を求められるとデュアル構成にする必要がある。

トランザクションの定義について:
サーバーとのやり取りなのかRequestなのかユースケース単位なのかをしっかり定義しておく必要がある。
それによっては数字が大きく変わってきて揉める一因となるらしい。


アーキテクチャ目標:
・非機能要件に書いてあることをわざわざ目標にも重ねて書く必要はない(特に目標値等が変わらない場合)
・イメージを持たせるのが主目的なので多少抽象的でも可。
・アーキテクチャを狭めるような表現はしないほうがいい。
(実現方法を目標の内容に含めない)
・目標を測定できる何か指標があればベター。

推敲機能選定について:
選ぶ際には業務フローの先頭を選ぶという視点を頭の片隅にいれておくこと。
→後続機能の確認を先に行いOKをもらってものちに先頭の機能で修正が入った場合また確認が必要。単純に確認作業のコストもかかる(データ準備等)



このページのトップへ

基本が重要

前回のエントリーでアーキテクチャ確定の作業における意識について思ったことをかいた。
アーキテクチャ説明書作成時の心構え

結局アーキテクチャ確定作業だけにとどまらずどんな作業においても重要かなと思われる結論になっていた。

アーキテクチャ確定というと高度な作業のイメージがあるが
基本は「当たり前のことを当たり前にやる
だからまぁそれは当然といえば当然のことかなと。

アーキテクチャ確定作業全般でほかにも思ったことは情報処理に関する基礎知識の重要性を改めて感じた。
基本情報処理の午前で出るような問題をテストで点をとれるだけでなく血となり身となっているような理解度があればなーと思うことがしばしばある。

第一弾として待ち行列を改めて勉強してみた。
サルでもわかる待ち行列

すごくわかりやすかったので忘れないようにリンクを貼っておく。
そのまま直接役に立つわけではないが、
基礎としてしっかりとした基礎知識がそなわってないといけないなーと最近痛感している。
テーマを決めてちょこちょこ基本情報を復習してみようかと。
このページのトップへ

プロフィール

ibarakinakano

Author:ibarakinakano
FC2ブログへようこそ!

最近の記事

最近のコメント

最近のトラックバック

月別アーカイブ

カテゴリー

ブロとも申請フォーム

この人とブロともになる

アクセスカウンター

ブログ内検索

RSSフィード

リンク

このブログをリンクに追加する