リッチクライアントシステム設計：ユーザーオブジェクト数に注意を！

「テストDB環境で動きますが本番DB環境ではエラーになりますが...」

ソフト開発でよく聞いたことであること。テストデータ作りの概念やデータボリュームによってソフト開発サイクルで様々な問題がく経験します。今日紹介したい件はこれらとちょっと違ってシステム設計の漏れという最悪のシナリオなのです。

最近リッチクライアントシステムは注目している。今やっているプロジェクトは.NETベースのWindowsフォームベースの開発。１年ほど開発されたシステムはいきなり本番機でベースの検索機能まで出来なくなったという心臓に悪い知らせがシステムテスト担当者から先週頂いたのです。現象はフォームが反応しなくなっていると。システムテストで見つかる問題点は今までの経験からいうと環境に依存する”なかなか治らない”ケースの方が多い。

一応、調査でまずログを調べたところ異常は記録してあるけど鍵になりそうなところではない。基本的に例外処理を徹底していてフォーム上にメッセージも上がらなかったことは不思議と思いました。

フォームの背景を説明するとコンプレックスのGUIでユーザーコントロールが多い。特にラベル系で形勢されているGUIコンポネント。

本番と同じボリュームで再現して見たところタスクマネージャーでユーザーオブジェクト数が１万件ほど。そこでピンと来た。８年前VB５で同じ現象を経験していて１万件のユーザーオブジェクトはWindowsの１アプリケーションインスタンスに割り振られている最大値。これは大変。失敗が繰り返されたということが自分でも許せられない。知ったときガッカリした。正直、失格ですね。ユーザーオブジェクトの制限、１万のことはwindowsNT以降２０００・XP・２００３になってもまだ同じである。Vistaはどうかちょっと分からないけど...

結局最悪のシナリオをユーザーオブジェクトを再デザインしラベルより全部GDIを使って描くようにした。またGDIの限界もあるけどデータの５年のボリュームベースででは大丈夫だろう。ちょっと苦労したこの件、失敗を繰り返さないためブログで公開したもの。

いまだに悔しい...