ホーム>ネットワークプログラミングチュートリアル>ASP.NET チュートリアル

Web.configの詳細説明 + asp.netの最適化

著者：Eve Cole 更新時間：2009-07-01 16:44:14
1. Web.config ファイルについて理解する
Web.config ファイルは、asp.NET Web アプリケーションの構成情報 (asp.NET Web アプリケーションの設定に最も一般的に使用される認証方法など) を保存するために使用される XML テキスト ファイルです。ディレクトリ内のステップ。 .NET 経由で新しい Web アプリケーションを作成すると、デフォルトでは、デフォルトの構成設定を含むデフォルトの Web.config ファイルがルート ディレクトリに自動的に作成され、すべてのサブディレクトリはその構成設定を継承します。サブディレクトリの構成設定を変更する場合は、サブディレクトリに新しい Web.config ファイルを作成できます。親ディレクトリから継承された構成情報に加えて構成情報も提供でき、親ディレクトリで定義された設定を上書きまたは変更することもできます。
(1).Web.Configはxmlファイル仕様で格納されており、設定ファイルは以下の形式に分かれています
1. 構成セクション ハンドラー宣言の特徴: 構成ファイルの先頭に位置し、<configSections> タグに含まれます。
2. 特定のアプリケーション構成機能: <appSetting> にあります。アプリケーションのグローバル定数設定などの情報を定義できます。
3. 構成セクションの設定機能: <system.Web> セクションにあり、asp.net ランタイムの動作を制御します。
4. 設定セクション グループの機能: <sectionGroup> タグを使用すると、グループ化をカスタマイズし、それを <configSections> 内または他の <sectionGroup> タグ内に配置できます。
(2) 設定セクションの各セクション
1.<configuration> セクションのルート要素。他のセクションはその中にあります。
2. <appSetting> セクション このセクションは、アプリケーション設定を定義するために使用されます。不確実な設定については、ユーザーが実際の状況に応じて独自の使用法を設定することもできます。
I.<アプリ設定>
<add key="Conntction" value="server=192.168.85.66;userid=sa;password=;database=Info;"/>
<アプリ設定>
接続文字列定数が定義されており、プログラム コードを変更することなく、実際のアプリケーションで接続文字列を変更できます。
II.<アプリ設定>
<add key="ErrPage" value="Error.aspx"/><appSettings> はエラー リダイレクト ページを定義します。
3.<コンパイル>セクションの形式:
<編集
デフォルト言語 = "c#"
デバッグ = "true"
/>
I.デフォルト言語: バックグラウンドコード言語を定義します。c# と vb.net の 2 つの言語を選択できます。
IIdebug: true の場合、aspx デバッグが開始されます。false の場合、aspx デバッグは開始されないため、アプリケーションの実行時のパフォーマンスが向上します。通常、プログラマは開発時に true に設定し、顧客に引き渡すときに false に設定します。
4.<customErrors> セクションの形式:
<カスタムエラー
モード = "リモートのみ"
デフォルトリダイレクト = "error.aspx"
<error statusCode="440" redirect="err440page.aspx"/>
<error statusCode="500" redirect="err500Page.aspx"/>
/>
I.mode: On、Off、RemoteOnly の 3 つの状態があります。 On はカスタマイズされた情報が常に表示されることを意味し、Off は詳細な asp.net エラー情報が常に表示されることを意味し、RemoteOnly はカスタマイズされた情報がローカル Web サーバーで実行されていないユーザーに対してのみ表示されることを意味します。
II.defaultRedirect: エラーが発生したときにリダイレクトするために使用される URL アドレス。
III.statusCode: 特定のエラーステータスを示すエラーステータスコードを示します。
IV. リダイレクト: URL のリダイレクトエラー。
5.<globalization> セクションの形式:
<グローバル化
requestEncoding="utf-8"
応答エンコーディング = "utf-8"
ファイルエンコーディング = "utf-8"
/>
I.requestEncoding: 各受信リクエストのエンコーディングをチェックするために使用されます。
II.responseEncoding: 返送された応答のコンテンツエンコーディングをチェックするために使用されます。
III.fileEncoding: aspx、asax、およびその他のファイル解析のデフォルトのエンコーディングをチェックするために使用されます。
6.<sessionState> セクションの形式:
<セッション状態
モード = "InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="データ ソース=127.0.0.1;Trusted_Connection=yes"
クッキーレス = "偽"
タイムアウト = "20"
/>
I.mode: off、Inproc、StateServer、SqlServer の状態に分割されます。
mode = InProc はプロセスに保存されます。 特徴: 最高のパフォーマンスと最速の速度を持ちますが、複数のサーバー間で共有することはできません。 mode = "StateServer" は状態サーバーに保存されます。 特徴: ユーザー セッション情報を複数のサーバー間で維持する必要がある場合。サーバーの場合は、この方法を使用してください。ただし、状態サーバーに障害が発生すると情報は失われます。 特徴: 負荷は大きくなりますが、情報は失われません。
II. stateConnectionString: asp.net アプリケーションがリモート セッション状態を保存するサーバー名を指定します。デフォルトはローカル マシンです。
III.sqlConnectionString: セッション状態データベースを使用する場合、ここに接続文字列を設定します。
IV. Cookieless: true に設定すると、Cookie セッション状態が顧客の識別に使用されないことを意味します。それ以外の場合は、その逆になります。
V. TimeOut: セッション状態の保存時間を定義するために使用され、制限時間を超過した場合、セッションは自動的に終了します。
7.<認証>セクションの形式:
<認証モード="フォーム">
<forms name=".ASPXUSERDEMO" loginUrl="Login.aspx" protection="All" timeout="30"/>
</認証>
<認可>
<拒否ユーザー = "?"/>
</認可>
I.Windows: IIS 認証方法を使用する
II.フォーム: フォームベースの検証の使用
III.パスポート: パスポート Cookie 検証モードを使用する
IV.None: 埋め込まれた Forms ノードの属性の意味:
I.Name: 認証を完了するために使用される HTTP Cookie の名前を指定します。
II.LoginUrl: 検証が失敗またはタイムアウトした場合にリダイレクトされるページ URL。通常はログイン ページで、ユーザーが再度ログインできるようにします。
III.保護: Cookieデータの保護方法を指定します。
設定できる内容: すべて なし 暗号化検証 4 つの保護方法
a. すべては、データを暗号化し、2 つの方法で有効性検証を実行することを意味します。
b. [なし] は Cookie が保護されていないことを意味します。
c. 暗号化とは、Cookie のコンテンツを暗号化することを意味します。
d. 検証とは、Cookie の内容の正当性を検証することを意味します。
IV. タイムアウト: タイムアウト後に再度ログインする時間を指定します。
実行時に Web.config ファイルに加えた変更は、サービスを再起動しなくても有効になります (注: <processModel> セクションは例外です)。もちろん、Web.config ファイルは拡張可能です。新しい構成パラメーターをカスタマイズし、それらを処理する構成セクション ハンドラーを作成できます。
web.config 構成ファイル (デフォルトの構成設定) には、次のすべてのコードが含まれている必要があります。
<構成>
<システム.ウェブ>
そして
</system.web>
</設定>
学習を目的として、次の例ではこの XML タグを省略しています。
1. <authentication> セクションの役割: asp.NET 認証サポート (4 種類: Windows、Forms、PassPort、None) を構成します。この要素は、コンピューター、サイト、またはアプリケーション レベルでのみ宣言できます。 <authentication> 要素は、<authorization> セクションとともに使用する必要があります。
例：
次の例は、ログインしていないユーザーが認証を必要とする Web ページにアクセスすると、ログイン Web ページに自動的にジャンプします。
<認証モード="フォーム" >
<forms loginUrl="logon.aspx" name=".FormsAuthCookie"/>
</認証>
要素loginUrlはログインWebページの名前を表し、nameはCookie名を表します。
2. <authorization> セクションの役割: URL リソースへのクライアント アクセスを制御します (匿名ユーザーのアクセスの許可など)。この要素は、任意のレベル (コンピューター、サイト、アプリケーション、サブディレクトリ、またはページ) で宣言できます。 <authentication> セクションと組み合わせて必要です。
例: 次の例では、匿名ユーザーへのアクセスを無効にします。
<認可>
<拒否ユーザー = "?"/>
</認可>
注: user.identity.name を使用して現在の認証済みユーザー名を取得できます。また、web.Security.FormsAuthentication.RedirectFromLoginPage メソッドを使用して、認証済みユーザーをユーザーが要求したばかりのページにリダイレクトできます。
3. <compilation> セクションの役割: asp.NET で使用されるすべてのコンパイル設定を構成します。デフォルトのデバッグ属性は「True」です。プログラムがコンパイルされ、使用できるように配布された後は、False に設定する必要があります (詳細は Web.config ファイルに記載されており、ここでは例は省略します)。
4.<カスタムエラー>
役割: asp.NET アプリケーションのカスタム エラー メッセージに関する情報を提供します。 XML Web サービスで発生するエラーには適用されません。
例: エラーが発生した場合、カスタム エラー ページにジャンプします。
<customErrorsdefaultRedirect="ErrorPage.aspx" mode="RemoteOnly">
</カスタムエラー>
要素defaultRedirectは、カスタマイズされたエラーWebページの名前を表します。 mode 要素は、ローカル Web サーバー上で実行されていないユーザーにカスタム (わかりやすい) 情報を表示することを示します。
5. <httpRuntime> セクションの役割: asp.NET HTTP ランタイム設定を構成します。このセクションは、コンピューター、サイト、アプリケーション、およびサブディレクトリのレベルで宣言できます。
例: ユーザーアップロードファイルの最大サイズを 4M、最大時間を 60 秒、最大リクエスト数を 100 に制御します。
<httpRuntime maxRequestLength="4096"executionTimeout="60" appRequestQueueLimit="100"/>
6. <ページ>
役割: ページ固有の構成設定 (セッション状態、ビュー状態を有効にするかどうか、ユーザー入力を検出するかどうかなど) を識別します。 <pages> は、コンピューター、サイト、アプリケーション、およびサブディレクトリのレベルで宣言できます。
例: ユーザーがブラウザーで入力したコンテンツに潜在的に危険なデータがあるかどうかを検出しません (注: この項目はデフォルトで検出されます。非検出を使用する場合は、ユーザーの入力をエンコードまたは検証する必要があります)。 client ページがポストバックされるときに、暗号化されたビュー ステートがチェックされ、ビュー ステートがクライアント側で改ざんされていないことが確認されます。 (注: この項目はデフォルトでは検証されていません)
<pagesbuffer="true" enableViewStateMac="true" validateRequest="false"/>
7. <セッション状態>
機能: 現在のアプリケーションのセッション状態設定を構成します (セッション状態を有効にするかどうか、セッション状態を保存する場所の設定など)。
例：
<sessionState mode="InProc" cookieless="true" timeout="20"/>
</セッション状態>
注記：
mode="InProc" は、セッション状態をローカルに保存することを意味します (リモート サーバーまたは SAL サーバーに保存するか、セッション状態を無効にすることも選択できます)
cookieless="true" は、ユーザーのブラウザが Cookie をサポートしていない場合にセッション状態を有効にすることを意味します (デフォルトは False)。
timeout="20" の意味: セッションがアイドル状態でいられる分数
8. <トレース>
機能: asp.NET 追跡サービスを構成します。主に、エラーが発生した場所を特定するためのプログラム テストに使用されます。
例: Web.config のデフォルト構成は次のとおりです。
<trace Enabled="false" requestLimit="10" pageOutput="false" trackMode="SortByTime" localOnly="true" />
注記：
Enabled="false" は、追跡を有効にしないことを意味します。
requestLimit="10" は、サーバーに保存される追跡リクエストの数を指定します。
pageOutput="false" は、トレース出力にはトレース ユーティリティを介してのみアクセスできることを意味します。
traceMode="SortByTime" は、トレース情報がトレースの処理順に表示されることを示します。
localOnly="true" は、トレース ビューア (trace.axd) がホスト Web サーバーに対してのみ使用されることを意味します。カスタム Web.config ファイル構成セクションのプロセスは 2 つのステップに分かれています。
1. 構成セクションの名前と、構成データを処理する .NET Framework クラスの名前を、構成ファイルの先頭の <configSections> タグと </configSections> タグの間のセクションで宣言します。
2. <configSections> 領域以降に、宣言されたセクションの実際の構成設定を行います。
例: データベース接続文字列を保存するセクションを作成する
<構成>
<configセクション>
<section name="appSettings" type="System.Configuration.NameValueFileSectionHandler, System, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
</configセクション>
<アプリ設定>
<add key="scon" value="server=a;database=northwind;uid=sa;pwd=123"/>
</アプリ設定>
<システム.ウェブ>
...
</system.web>
</設定>
Web.config ファイルへのアクセス ConfigurationSettings.AppSettings 静的文字列コレクションを使用して、Web.config ファイルにアクセスできます。 例: 上の例で確立された接続文字列を取得します。例えば：
protected static string Isdebug = ConfigurationSettings.AppSettings["debug"]
2. web.config のセッション構成の詳細説明 アプリケーションの構成ファイル Web.config を開くと、次の段落が表示されます。
< セッション状態
モード = "InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="データ ソース=127.0.0.1;Trusted_Connection=yes"
クッキーレス = "偽"
タイムアウト = "20"
/>
このセクションでは、アプリケーションがセッション情報を保存する方法を構成します。以下のさまざまな操作は主にこの構成に焦点を当てています。まず、この構成に含まれる内容の意味を見てみましょう。 sessionState ノードの構文は次のとおりです。
< sessionState mode="Off|InProc|StateServer|SQLServer"
cookieless="true|false"
timeout="分数"
stateConnectionString="tcpip=サーバー:ポート"
sqlConnectionString="SQL 接続文字列"
stateNetworkTimeout="秒数"
/>
必須の属性は次のとおりです。 属性 オプション 説明
モードはセッション情報を保存する場所を設定します
Ø Offはセッション機能を使用しない設定です。
Ø InProc はプロセスにセッションを保存するように設定されます。これは、ASP の保存方法です。これがデフォルト値です。
Ø StateServer は、セッションを独立した状態サービスに保存するように設定されています。
Ø SQLServer 設定は、セッションを SQL Server に保存します。
オプションの属性は次のとおりです。 属性 オプションの説明
Ø クライアントのセッション情報が保存されるクッキーレスセット、
Ø は cookieless モードを使用します。
Ø false Cookie モードを使用します。これがデフォルト値です。
Ø タイムアウトは、サーバーが自動的にセッション情報を放棄するまでの時間を分単位で設定します。デフォルトは 20 分です。
stateConnectionString は、状態サービスにセッション情報を保存するときに使用されるサーバー名とポート番号を設定します (例: "tcpip=127.0.0.1:42424")。この属性は、mode の値が StateServer の場合に必須です。
sqlConnectionString は、SQL サーバーに接続するときの接続文字列を設定します。たとえば、「データ ソース = localhost;統合セキュリティ = SSPI;初期カタログ =northwind」などです。この属性は、mode の値が SQLServer の場合に必須です。
stateNetworkTimeout は、StateServer モードを使用してセッション状態を保存するときに、Web サーバーと状態情報を保存しているサーバー間の TCP/IP 接続が切断されるまでのアイドル秒数を設定します。デフォルト値は 10 秒です。
asp.NET におけるクライアント セッション ステータスの格納は、上記のセッション モデルの紹介で示されています。セッション ステータスは、クライアントとサーバーの 2 つの場所に格納される必要があることがわかります。クライアントは、対応する Web サイトのセッション ID を保存することのみを担当し、他のセッション情報はサーバー側に保存されます。 ASP では、クライアントの SessionID は実際には Cookie の形式で保存されます。ユーザーがブラウザの設定で Cookie を無効にすると、セッションの利便性を享受できなくなり、特定の Web サイトにアクセスできなくなる場合もあります。上記の問題を解決するために、asp.NET におけるクライアントのセッション情報の保存方法は Cookie と Cookieless の 2 種類に分けられます。
asp.NET では、デフォルトで、クライアントにセッション情報を保存するために Cookie が引き続き使用されます。 Cookieless を使用してセッション情報をクライアントに保存する場合、方法は次のとおりです。
現在の Web アプリケーションのルート ディレクトリを見つけて Web.Config ファイルを開き、次の段落を見つけます。
< セッション状態
モード = "InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="データ ソース=127.0.0.1;Trusted_Connection=yes"
クッキーレス = "偽"
タイムアウト = "20"
/>
この段落の cookieless="false" は cookieless="true" に変更されます。このようにして、クライアントのセッション情報は Cookie を使用して保存されなくなり、URL を通じて保存されます。現在の IE を閉じ、新しい IE を開いて、先ほどの Web アプリケーションに再度アクセスすると、次のような内容が表示されます。
このうち、 http://localhost/MyTestApplication/(ulqsek45heu3ic2a5zgdl245 )/default.aspx 内で太字で示されているのがクライアントのセッション ID です。この情報は IIS によって自動的に追加され、以前の通常の接続には影響しないことに注意してください。
asp.NET のサーバー側でセッション状態を保存するための準備:
実験的な現象をよりよく体験するには、SessionState.aspx というページを作成し、次のコードを <body></body> に追加します。
<scriptrunat="サーバー">
Sub Session_Add(送信者をオブジェクトとして、e を EventArgs として)
session("MySession") = text1.Value
span1.InnerHtml = "セッション データが更新されました! < P>セッションには次のものが含まれています: < font color=red>" & session("MySession") & "</font>"
エンドサブ
サブ CheckSession(オブジェクトとして送信者、EventArgs として)
If (Session("MySession")Is Nothing) then
span1.InnerHtml = "何もありません、セッション データが失われました!"
それ以外
span1.InnerHtml = "あなたのセッションには以下が含まれています: < font color= red>" & session("MySession").ToString() & "< /font>"
終了の場合
エンドサブ
</script>
< formrunat="server"id="Form2">
< inputid="text1"type="text"runat="server"name="text1">
< inputtype="submit"runat="server"OnServerClick="Session_Add"
value="セッション状態に追加" id="Submit1"name="Submit1">
< inputtype="submit"runat="server"OnServerClick="CheckSession"
value=" セッション状態の表示 " id="Submit2" name="Submit2">
< /form>
< hrsize="1">
< fontsize="6">< spaid="span1"runat="server" /></font>
SessionState.aspx ページを使用して、現在のサーバーでセッション情報が失われたかどうかをテストできます。
プロセス内でのサーバー セッション情報の保存 Web.config ファイルの前の段落に戻りましょう。
< セッション状態
モード = "InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="データ ソース=127.0.0.1;Trusted_Connection=yes"
クッキーレス = "偽"
タイムアウト = "20"
/>
mode の値が InProc の場合、サーバーがこのモードを使用していることを示します。
この方法は、ASP の以前のモードと同じです。つまり、サーバーはセッション情報を IIS プロセスに保存します。 IIS をシャットダウンして再起動すると、この情報は失われます。ただし、このモードには最高のパフォーマンスという最大の利点もあります。すべてのセッション情報は IIS プロセスに保存されるため、このモードのパフォーマンスは、セッション情報をプロセス外に保存する場合や SQL Server に大量のセッション情報を保存する場合よりも高速です。このモードは、asp.NET のデフォルトの方法でもあります。
さて、実験をしてみましょう。ここで SessionState.aspx ページを開き、いくつかの文字を入力してセッションに保存します。次に、IIS を再起動しましょう。現在のサイトを停止して再起動するのではなく、IIS のローカル マシン名のノードを右クリックし、[IIS の再起動] を選択することに注意してください。 (NT4 を使用していたときは、IIS を再起動するためにコンピュータを再起動する必要があったと思います。Microsoft は本当に @#$%^& です。) SessionState.aspx ページに戻り、先ほどのセッション情報を確認すると、情報が変更されていることがわかります。失った。
サーバー セッション情報をプロセス外に保存する まず、管理ツール -> サービスを開き、asp.NET State Service という名前のサービスを見つけて開始します。実際、このサービスはセッション情報を保存するプロセスを開始します。このサービスを開始すると、Windows タスク マネージャー -> プロセスに aspnet_state.exe という名前のプロセスが表示されます。これはセッション情報を保存するプロセスです。
次に、Web.config ファイルの上記の段落に戻り、モード値を StateServer に変更します。ファイルを保存した後、IE を再度開き、SessionState.aspx ページを開いて、セッションに情報を保存します。この時点で、IIS を再起動し、SessionState.aspx ページに戻って、先ほどのセッション情報を確認し、情報が失われていないことを確認します。
実際、セッション情報をプロセス外に保存するこの方法は、ローカル マシンのプロセス外に情報を保存できるだけでなく、他のサーバーのプロセスにもセッション情報を保存できることを意味します。このとき、モード値を StateServer に変更するだけでなく、stateConnectionString で対応するパラメーターを構成する必要もあります。たとえば、計算結果は 192.168.0.1 です。IP アドレス 192.168.0.2 のコンピュータのプロセスにセッションを保存するには、stateConnectionString="tcpip=192.168.0.2:42424" のように設定する必要があります。もちろん、192.168.0.2 コンピューターに .NET Framework をインストールし、asp.NET State Services サービスを開始することを忘れないでください。
サーバーセッション情報を SQL サーバーに保存する まず、いくつかの準備作業を行います。 SQL サーバーおよび SQL サーバー プロキシ サービスを開始します。 SQL サーバーで InstallSqlState.sql というスクリプト ファイルを実行します。このスクリプト ファイルは、特にセッション情報を保存するためのデータベースを SQL Server に作成し、セッション情報データベースを維持する SQL Server エージェント ジョブを作成します。このファイルは次のパスにあります。
[システムドライブ]winntMicrosoft.NETFramework[バージョン]
次に、クエリ アナライザーを開き、SQL サーバーに接続し、先ほどのファイルを開いて実行します。しばらく待つと、データベースとジョブが作成されます。この時点で、Enterprise Manager を開くと、ASPState という新しいデータベースが追加されたことがわかります。ただし、このデータベースにはストアド プロシージャがいくつかあるだけで、ユーザー テーブルはありません。実際、セッション情報は tempdb データベースの APSPStateTempSessions テーブルに格納され、別の ASPStateTempApplications テーブルには asp のアプリケーション オブジェクト情報が格納されます。これら 2 つのテーブルも、先ほどのスクリプトによって作成されました。さらに、[管理] -> [SQL サーバー エージェント] -> [ジョブ] を確認すると、ASPState_Job_DeleteExpiredSessions という追加のジョブもあることを確認します。このジョブは実際に、ASPStateTempSessions テーブルから期限切れのセッション情報を毎分削除します。
次に、Web.config ファイルに戻り、モード値を SQLServer に変更します。同時に sqlConnectionString の値も変更する必要があることに注意してください。形式は次のとおりです。
sqlConnectionString="データ ソース = localhost; 統合セキュリティ = SSPI;"
データ ソースは、SQL サーバー サーバーの IP アドレスを参照します。SQL サーバーと IIS が同じマシンの場合は、「127.0.0.1」と入力します。 Integrated Security=SSPI は、Windows 統合認証を使用することを意味します。このように、データベースへのアクセスは、userid=sa;password=password を使用する SQL サーバー認証方法よりも優れたセキュリティを実現します。 。もちろん、SQL サーバーが別のコンピュータで実行されている場合は、Active Directory ドメインを通じて両側で認証の一貫性を維持する必要がある場合があります。
もう一度、実験してみましょう。 SessionState.aspx にセッション情報を追加すると、そのセッション情報が SQL サーバーにすでに存在していることがわかり、コンピューターを再起動してもセッション情報は失われません。これで、セッション情報がどのようなものであるかが完全にわかりました。セッション情報は SQL Server に保存されます。何ができるかはパフォーマンスによって異なります。

概要 3. asp.net フォーム認証の一般設定
asp.net フォーム認証の一般設定:
1: web.config で、フォーム認証を追加します。
<認証モード="フォーム">
<forms name="auth" loginUrl="index.aspx" timeout="30"></forms>
</認証>
<認可>
<ユーザーを拒否=?"
</認可>
2: 登録ページがある場合、匿名ユーザーが登録ページを呼び出して登録できるようにする必要があります。
次のコードは <configuration><system.web> の間にある必要があり、<system.web>..</system.web> の間に含めることはできません。
----------------匿名ユーザーが userReg.aspx ページへのアクセスを許可されていることを示します。
<location path="userReg.aspx">
<システム.ウェブ>
<認可>
<許可ユーザー=?"
</認可>
</system.web>
</場所>
3. ログインに成功した後、認証された正規ユーザーが合格したことを示す ID 検証チケットを作成する必要があります。
if (ログイン成功)
System.Web.Security.FormsAuthentication.SetAuthCookie(ユーザー名、false);
4. Web.config ファイルにアクセスする ConfigurationSettings.AppSettings 静的文字列コレクションを使用して、Web.config ファイルにアクセスできます。 例: 上記の例で確立された接続文字列を取得します。例えば：
protected static string Isdebug = ConfigurationSettings.AppSettings["scon"]
asp.Net パフォーマンスの最適化。
(1).セッション状態の保存方法の選択
Webconfig ファイルで設定します。
<sessionState mode="???" stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="データ ソース=127.0.0.1;Trusted_Connection=yes"
cookieless="false" タイムアウト="20"/>

ASP.NET には、セッション状態情報を保存する 3 つの方法があります。
1. プロセスに保存: 属性モード = InProc
特徴: 最高のパフォーマンスと最速の速度を備えていますが、複数のサーバー間で共有することはできません。

2. 状態サーバーに保存: 属性モード = "StateServer"
機能: ユーザー セッション情報をサーバー間で維持する必要がある場合は、この方法を使用します。
ただし、情報は状態サーバーに保存され、状態サーバーに障害が発生すると情報は失われます。

3. SQL サーバーに保存: 属性 mode="SqlServer"
特徴：作業負荷は大きくなりますが、情報は失われません。
もう一つ:
I. 一部のページはセッション状態を必要としないため、セッション状態を無効にすることができます。
コードは次のとおりです: <%@ Page EnableSessionState="false" %>
II. ページがセッション変数にアクセスする必要があるが、変更が許可されていない場合は、ページのセッション ステータスを読み取り専用に設定できます。
コードは次のとおりです: <%@ Page EnableSessionState="false" %>
使用するときは、特定の状況に応じて特定の方法を選択できます
(2).Page.IsPostBackを使用する
Page.IsPostBack は、クライアントから返されるかどうかを示します。初回実行時には、その値は返されません。
false の場合、ページ上のイベントがトリガーされるかページが更新されると、ポストバックであるため、Page.IsPostBack の値は true になります。
一般的に使用されるのは次のとおりです: Page_Load メソッド:
private void Page_Load(オブジェクト送信者,EventArgs e)
{
if(!Page.IsPostBack)
{
....; // ページを初期化するコード。これらのコードは、ページが初めて初期化されるときと、2 回目にポストバックされるときに実行されます。
//再度実行されません。効率を向上させます。
}
}
一部のコントロールは初期化後に状態を維持する必要があるため、多くの場合、IsPostBack を使用する必要があります。
例: DropDownList を毎回初期化すると、ユーザーがどのオプションを選択しても、デフォルト値に初期化されます。
(3) サーバーコントロールの使用を避ける。
1. 一般的な静的な表示情報については、サーバー側コントロールを使用して表示しないようにしてください。サーバー側コントロールは実行のためにサーバーにポストバックする必要があるためです。
プログラムの実行効率が低下しますので、通常は<DIV>で表示できます。
サーバー側コントロールが使用されている場合は、 runat="server" を削除すると効率も向上します。
2. サーバー側コントロールの状態ビューを無効にします。一部のコントロールは、その状態を維持する必要がありません。EnableViewState=false; と設定できます。
ページ コントロール全体で状態ビューを維持する必要がない場合は、ページ全体の状態ビューを false に設定できます。
コードは次のとおりです: <%@ Page EnableViewState="false"%>
3. Web.Config ファイルで構成します。
asp.NET セッションは、Web.config または Machine.config の Sessionsstate 要素で構成できます。
Web.config の設定の例を次に示します。
<Sessionsstate timeout="10" cookieless="false" mode="Inproc" />
(4) DataGrid の使用を避ける。
DataGrid が強力であることは誰もが知っています。ただし、強力である一方で、パフォーマンスのオーバーヘッドも増加します。通常は他のコントロールを使用します: DataList
または、Repeater コントロールでこれを実現できる場合は、DataGrid を使用しないようにしてください。
(5).文字列操作
1. 箱詰め作業は効率が悪くなりますので避けてください。
たとえば、次の 2 つのコード スニペットを実行します。
文字列テスト="";
for(for int i=0;i<10000;i++)
{
テスト = テスト + i;
}
そして
文字列テスト="";
for(for int i=0;i<10000;i++)
{
テスト = テスト + i.ToString();
}
以下のコード スニペットは明らかに効率的です。i は整数であるため、システムは接続する前にまず i をボックス化して文字列型に変換する必要があります。
読者はそれを自分のマシンにコピーしてテストできます。
2. StringBuliderクラスを使用する
文字列連結を行う場合: string str = str1 + str2 + ....;
一般に、接続が 3 つを超える場合は、文字列オブジェクトの再作成を回避できる StringBuilder の代わりに StringBuilder を使用するのが最善です。
パフォーマンスの損失。
通常、SQL ステートメントを組み立てるときに使用されます: StringBulider。
読者は自分のマシンでテストできます。
3. 使用量は最小限に抑えます。
試す
{}
キャッチ
{}
ついに
{}
このステートメントの実行効率は比較的低いです。
(6) ADO.Net利用の最適化
1. データベース接続がオープンおよびクローズされます。 接続が必要なときに開き、データベースにアクセスしたらすぐに接続を閉じます。
たとえば、2 つのコード スニペットを見てみましょう。
私。
DataSet ds = 新しい DataSet();
SqlConnection MyConnection = new SqlConnection("サーバー=ローカルホスト; uid=sa; pwd=; データベース=NorthWind");
SqlCommand myCommand = new SqlCommand(strSql,MyConnection);
SqlDataAdapter myAdapter=new SqlDataAdapter(queryStr,connectionStr);
MyConnection.Open(); //接続を開きます
for(int i=0;i<1000;i++) //for ループはデータを取得する前にビジネス ロジック操作をシミュレートします
{
Thread.Sleep(1000);
}
myAdapter.Fill(ds);
for(int i=0;i<1000;i++) //for ループはデータ取得後のビジネス ロジック操作をシミュレートします
{
Thread.Sleep(1000);
}
MyConnection.Close(); //接続を閉じます。
II.
DataSet ds = 新しい DataSet();
SqlConnection MyConnection = new SqlConnection("サーバー=ローカルホスト; uid=sa; pwd=; データベース=NorthWind");
SqlCommand myCommand = new SqlCommand(strSql,MyConnection);
SqlDataAdapter myAdapter=new SqlDataAdapter(queryStr,connectionStr);
for(int i=0;i<1000;i++) //for ループはデータを取得する前にビジネス ロジック操作をシミュレートします
{
Thread.Sleep(1000);
}
MyConnection.Open(); //接続を開きます
myAdapter.Fill(ds);
MyConnection.Close(); //接続を閉じます。
for(int i=0;i<1000;i++) ////for ループは、データ取得後のビジネス ロジック操作をシミュレートします。
{
Thread.Sleep(1000);
}
表示 II コードは、I コードよりもはるかに優れています。ユーザーが多い場合、接続プールがいっぱいになる可能性があります。ひどい場合には、クラッシュが発生する可能性があります。
2. データベースクエリ
I. SQL ステートメントを直接生成します。 SQL Server は毎回コンパイルする必要があるため、パフォーマンスが大幅に向上することはありません。さらに、安全性も十分ではありません。簡単に攻撃されます。
II. パラメータを指定して SQL コマンドを使用します。この方法では、SQL サーバーは SQL を 1 回コンパイルするだけで、コンパイルされたコマンドをさまざまなパラメーターに再利用できます。パフォーマンスが向上しました。
III. SQL サーバー ストアド プロシージャを使用します。一度にコンパイルすると、ステートメントを複数回送信する機能を一度に完了できます。
流れ。 ビジネス ロジックが非常に複雑な場合、ストアド プロシージャがステートメントよりも効率的であるとは限りません。
(6). キャッシュの最適化
キャッシュには、ページ キャッシュと API キャッシュの 2 種類があります。
1. ページ キャッシュとフラグメント キャッシュを使用する
<%@ OutputCache Duration="5" VaryByParam="None"%>
<%@ OutputCache 期間=60 VaryByParam=”TextBox1,TextBox2” %>
注: 期間はキャッシュの有効期限を設定します。
VarByParam はパラメータに応じて設定を変更するかどうかです。None の場合、すべてのパラメータが同じキャッシュを使用します。
TextBox1 を設定するとき、TextBox1 の異なる値に従って個別にキャッシュし、複数のパラメータがある場合は組み合わせてキャッシュします。
2.APIキャッシュ。アプリケーションで使用するための
I. キャッシュの使用例:
http://blog.csdn.net/chengking/archive/2005/10/03/494545.aspx
II. 以下を使用する場合は、Page.Cache と HttpContext.Current.Cache の違いに注意してください。
これらは同じオブジェクトを参照します。global.asax または独自のクラスで使用する場合は、Page.Cache を使用します。一部のイベントでは、HttpContext がないため、HttpRuntime.Cache を使用します。
関連記事