オルタナティブ・ブログ > インディアサテライト >

母国インドのアウトソーシング市場・経済などの現状と今後の方向性について書くブログ

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

»

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

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

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

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

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

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

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

いまだに悔しい...

Comment(1)