(hatena (diary ’Nobuhisa)) このページをアンテナに追加 RSSフィード Twitter

16/10/06 :

[][]ワーカープロセスとstatic変数に関してのメモ

asp.net - IIS app pools, worker processes, app domains - Stack Overflowより:

In a server you can have many asp.net sites that runs together. Each one site is an app domain.


You must assign to each of them one application pool. Many application domains (sites) can have the same application pool, and because they have the same application pool they run under the same processes, and under the same account - and they have the same settings of the pool. If this pool restarts, then all sites under that pools restarts.


Now each pool can have one or more worker process. Each worker process is a different program that's run your site, have their alone static variables, they different start stop calls etc. Different worker process are not communicate together, and the only way to exchange data is from common files or a common database. If you have more than one worker process and one of them make long time calculations, then the other can take care to handle the internet calls and show content.


When you assign many worker process to a single pool then you make the called web garden and your site is like to be run from more than one computer if a computer is one processing machine.


Each worker process can have many threads.


How the more worker process affect you:

When you have one worker process everything is more simple, among your application all static variables are the same, and you use the lock to synchronize them.

When you assign more than one worker process then you still continue to use the lock for static variables, static variables are not different among the many runs of your site, and if you have some common resource (e.g. the creation of a thumbnail on the disk) then you need to synchronize your worker process with Mutex.


RazorEngineでstatic変数を当たり前のように使用していたので、ASP.NET(MVC)に乗せた際にどうなるのだろうと思って調べていました。

static変数はワーカープロセス内で共通なのですね。安易に使うのはちょっとこわい。

そういえば、HttpContext.Currentもstatic変数(プロパティ)だけど、あれは一体どういう扱いになってるんだろう。プロパティがstaticだというだけで、値が使い回されるわけではないですよね。(たぶん)


ASP.NETの内部についてもっと勉強しないとなぁ。

Web上で拾える情報に少し限界を感じたので、やはり書籍が必要になりそう。

16/09/20 :

[][]ASP.NET Web API でファイルをアップロード

Web API経由でファイルをアップロードするサンプルをGitHubにpushしました。

自分用の備忘録も兼ねて。。(たまにやり方を忘れる)

https://github.com/Nobuhisa/FsWebApiSample


メインとなるファイルは以下の2つ。

サーバ : FileController.fs

クライアント : Program.fs


今回、サーバサイドではファイルを保存する際に

MultipartFormDataStreamProviderを使用していますが、

例えばAzure Storageに保存したい場合は

MultipartFormDataRemoteStreamProvider を継承して

GetRemoteStream メソッドをオーバーライドします。

※ BlobのストリームをRemoteStreamInfoで包んで返してやる感じ


クライアントのほうは、

MultipartFormDataContentにファイル等を登録した後に、

HttpClientのPostAsyncを使ってアップロードしています。


おしまい。

16/01/29 :

DIコンテナ使ってますか

海外のStack Overflowなどを見ていると、


"DI vs (Abstract) Factory Pattern"

"DI vs Service Locator Pattern"


という類の議論(質問)が多数見受けられる。

( 例えば: http://stackoverflow.com/questions/557742/dependency-injection-vs-factory-pattern )

回答の内容はごもっともである。(と思う)


結局のところ、DIコンテナ(ツール/ライブラリ)は使わずFactory等で解決している人が多いのかな。

かく言う自分も、どちらにすべきか度々迷っている・・・。

15/12/07 : 有為転変

[]F# Quiz : プロパティ

F# Advent Calender 2015の4日目の、ぐるぐるさんの記事を拝見していました。


僕はお仕事で F# + ASP.NET MVC の組み合わせを使うことが多いのですが、やはりC#/V○前提のフレームワークを用いる時はどうしてもクラスをモリモリ使うことになってしまいます。その辺が少しもどかしい。


さて、記事の中ではメンバーの定義についてはあまり触れられていませんでしたが、F#にはプロパティの実装方法が沢山あります。そして厄介なことに、アクセスした時の振る舞いなどが異なります。でも、手のかかる子ほど可愛い。(?)


そこで、ちょっとF#クイズを用意してみました。

以下の4つのプロパティ*1を評価した時に、それぞれどのような結果となるか考えてみてください。

まずは脳内のF# Interactiveで実行してみてね。


type Quiz() =
    let count =
        let counter = ref 0
        fun () -> incr counter ; !counter

    let lazyCount = lazy count ()


    member this.PropA = count ()

    member val PropB = count ()

    member this.PropC with get() = count ()

    member this.PropD with get() = lazyCount.Force()


答えはfsiが教えてくれます。(手抜き)

それぞれ複数回評価してみると違いが分かるかもしれません。

現場からは以上です。


おまけ

はてなユーザの皆さん、彩りの存在も思い出してあげてください。(白目

http://irodori.azurewebsites.net/

*1:PropDはおまけです

15/12/03 :

[]恐怖のおやすみエラー

F# Advent Calender 2015の2日目の記事を拝見していました。

同名の型などを定義することによって、既存の型の使用を制限する方法が紹介されていました。


ふと、

「そういえば、CompileMessage属性なんてものがあったなぁ」

と思い出したので、別パターンを書いてみました。

以下のようにすると、(1)XmlDocumentクラスがインテリセンスに表示されなくなり、(2)それでも自力でインスタンスを生成しようとするとコンパイルエラーが発生するようになります。*1


namespace System.Xml

module private AA =
    [<Literal>]
    let oyasumi = """
_____
| (^o^)ノ| < おやすみー
|\⌒⌒⌒ \
 \|⌒⌒⌒⌒|
    ̄ ̄ ̄ ̄ ̄
"""

// インテリセンスに表示させないための属性
[<CompilerMessage("隠蔽のための属性", 12345, IsHidden = true)>]
type XmlDocument =
    // コンストラクタにアクセスした時にエラーを発生させる
    [<CompilerMessage(AA.oyasumi, 12345, IsError = true)>]
    new() = {}


スクリーンショット

f:id:Nobuhisa:20151203062217p:image


おしまい。

*1:IsErrorプロパティをfalseにすることによって、エラーを警告にすることも可能