kazuk は null に触れてしまった

C# / .NET 系技術ネタ縛りでお送りしております

月別アーカイブ: 9月 2010

VS2010 に機能拡張を入れると起動に時間がかかるようになる


なんかVS2010の起動に3分ぐらいかかるんですよ、おかしいなーと思って色々見て回った結果なんですが

 

vsix

ごめんなさい、ごめんなさい。スクロールバーのサイズみた時点で何が原因かよく解りましたですよ。

Windows Live Spaces から移行してきました。


移行ツール使ったんだけど、コードの断片とかガシガシ落ちてますな。残念な結果でございます。

近況ですが DSL Tools や GAT 2010 / GAX 2010等のVS Extentions系を中心に散策中。

物作りを単純に出来合いツール(要するにVisual Studio)でやってると、なんていうか生産効率とかはどこもかしこも一緒なんすよね。(使いこなしている人を比較すれば:使いこなしていなければ残念でした)

結局の所効率を出そうとすると社内のプロセス全体での改善をかけるのと、局所的なプロセスオプチマイズでチューニングしていくしかないわけで。

TFS とかスクラム、アジャイル等での開発プロセス全体でのオプチマイズは全体に効くんでそっちも重要は重要なんだけど。

いわゆるVisual Studio 2010 っていう「包丁を研ぐ」の段階ですね。

 

包丁を使って作る料理の方は Azure や Sync Framework 等を素材にレシピの検討中です。

ネタばらし的な内容となりますがAzureに代表されるクラウドへの対応にあたって弊社システムとしてはクラウド、オンプレミスのハイブリッド形となる見通しでございます。

Webフロントエンド部の構成としてはオンプレミス側にカリカリにチューニングしたシステムを配置し、トラフィックスパイク等はオンプレミスに連れてきて処理を基本戦略としています。なぜかというとクラウドに発生するコストの懸念であり、弊社の事情としては事例記事にもちらっと出てる通りで顧客特性としてスパイクしたら800倍程度のトラフィックが襲い掛かるわけです。このトラフィックはクラウドにおける主要な課金要素でして、一気に数100倍のコストが発生するのはスパイクを処理した事で売上がそれなりにあっても容認しがたい事でございます。なので固定費で運用されている弊社データセンター側システムで処理する事でコストの平準化効果が非常に高く現れます。

また、事例記事で上がっている通り、弊社のCMSエンジンはかなりのキャッシュモンスターとして実装されており、このキャッシュ等のメカニズムはアクセスが一点に集中すればするほど効率が上がる特性を持ちますのでアクセス頻度の低いページへのリクエストがパラパラくる事でキャッシュに使用しているメモリを食われるよりはスパイク部等のキャッシュがカリカリに効く部分を集めて処理する事でより効率的に動作する事が期待できます。

また、クラウドによるスケールアウト戦略は基本的に否定しています。突発的に800倍の負荷がやってくる所にスケールアウト戦略はそもそもマッチしません、せいぜい数倍のスケールなら事前準備でスケールマージンとしてのマシンを立ち上げておく事はできないでもないですが、数100倍のスケールマージンに相当するシステムを立ち上げておいて予期された(スパイクという名の)商戦が来なかった場合に発生したコストが空振りになるリスクがあります。さらにはシステムをクラウド上で動的にスケールさせる事ができると言っても数十分のラグタイムは絶対に発生し、場合によっては商戦が数分で終了してしまう事もあります。この機会損失リスクも許容しがたい訳です。

結果的に可能なオプションは非常に限られており弊社データセンターに十分にチューニングされたシステムを配備し、平常時の数千倍のスパイクをそこで処理できる様にするしかないという事になります。当然のことながら平常時の稼働効率は要求性能の数千分の1でしかなくても綿密にチューニングされている必要があり、スパイクの規模が大きいほど効率的に動作するキャッシュ等のメカニズムは非常に重要度が高い事になります。

クラウド対応を行う上での基本的な設計方針としてはこんな感じではありますが、これを支えるメカニズムに多くの課題があるのも事実です、クラウドからオンプレミスに処理をスイッチするのはリダイレクトすればいいが誰が引き金を引くのか、数分で数100倍のトラフィックが襲い掛かる所ではログをバッチで分析してなんて手段はそもそも通用しません(バッチがオンプレミス系への切り替えを指示したタイミングですでにコストは発生してしまった後になるでしょう)。Webヘッドノードのスパイク監視で許されるラグタイムは高々数秒しかないのでリアルタイム処理は必須になりますし引き金を引きそこなったら数100倍のコストで沈む計算でかなりセンシティブな実装が要求されるわけです。またクラウドにおけるKVSでのデータアクセスの仕方と、オンプレミスでのデータアクセスの仕方を整合させる必要がありそもそもの PaaSで用意されるストレージとオンプレミスで使っている各種ストレージに対して処理方法やミドルが異なる中で処理内容を整合させるという困難なタスクをこなす必要があります。

いずれも簡単にはいかない困難な要素を抱えておりますが一つづつクリアしていく事でいずれ弊社SaaSがクラウド上で動作するようになりましたという報告ができる様にしたいと思っております。

Pex & Moles 0.94 をインストールしたらVS2008で csproj を読めなくなったっていう人に捧げます


2010/9/24 追記 0.94.1 がリリースされてました、それでは直ってるはずです(これから試します)

2010/9/24 追記 その2

Facebook 上で Pex and Moles Updated to 0.94.1: VS2008 registration issue and other little issues fixed… The MSDN download should be working again too… なんてアナウンスされていて、0.94.1 ってのが出るのかなと待っていたんですが、0.94のリビジョン違いでリリースされている模様です。

現在でmsdn subscriber downloadから落ちてくる en_visual_studio_2010_pex_0.94_power_tools_x64_587798.exe が0.94.1って事になりそうです。

Pex and Moles – Release Notes – Microsoft Research

v0.94.50921.0, 09/21/2010

Bug Fixes

  • Incorrect registration of MSBuild targets in Visual Studio 2008. The Moles MSBuild targets were not registered correctly for Visual Studio 2008.
  • Null Reference Exception when Assemblies could not be resolved. Moles would fail with a null reference when one of the dependent assembly was not resolved. Moles is still failing but with a nicer error message.

の最初の部分がこのblogで問題にした部分ですね。

中の人はこのblogでのパッチよりもうちっときれいな解決をしてますね。

<MolesBinPath Condition=”$(MolesBinPath) == ””>$(MSBuildThisFileDirectory)</MolesBinPath>

って事で同じディレクトリのを使えって形で変更されています。これで同様に直ってるはずって事で確認できましたのでみんな試してね!

お、64 bitマシンで開発してますね。えらい!、いまどきのサーバは64 bitしかないんだから、32 bit OSなんかで開発とかデバッグなんてできるわけねーよ、ですよね。

C:Program FilesMicrosoft Molesbin に置かれてる Microsoft.Moles.After.targets に原因が有ります。

オリジナルは以下の様になっています

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <!-- Begin Microsoft Moles -->
  <PropertyGroup Condition="'$(MolesImported)' != 'true'">
    <MolesInstallDir Condition="$(MolesInstallDir) == ''">$(ProgramFiles)Microsoft Moles</MolesInstallDir>
  </PropertyGroup>
  <Import Condition="'$(MolesImported)' != 'true'"
    Project="$(MolesInstallDir)binMicrosoft.Moles.targets"/>
  <!-- End Microsoft Moles -->
</Project>

VS2008は 32 bitプロセスなんで $(ProgramFiles) は C:Program Files (x86) になってしまい、隣にあるはずの Microsoft.Moles.targets の読み込みに失敗します。

PROCESSOR_ARCHITECTURE に応じて ProgramW6432 とProgramFiles の環境変数参照を切り替える様にします。

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <!-- Begin Microsoft Moles -->
  <PropertyGroup Condition="'$(MolesImported)' != 'true'">
    <MolesInstallDir Condition="$(MolesInstallDir) == '' And $(PROCESSOR_ARCHITECTURE)=='x86'">$(ProgramW6432)Microsoft Moles</MolesInstallDir>
    <MolesInstallDir Condition="$(MolesInstallDir) == '' And $(PROCESSOR_ARCHITECTURE)=='AMD64'">$(ProgramFiles)Microsoft Moles</MolesInstallDir>
  </PropertyGroup>
  <Import    Condition="'$(MolesImported)' != 'true'"
    Project="$(MolesInstallDir)binMicrosoft.Moles.targets"/>
  <!-- End Microsoft Moles -->
</Project>

#ぶっちゃけボンミスっぽいエラーだったりして、テスト支援ツール作っててこれは無いんじゃねーかなー、ちゃんとテストしてほしいなー>MSさま