足球Legends Never Die

   
说实话,游戏只是自己的一个个人爱好的一面,他不会是生存的全部,然则或许在某一弹指间,在某一个足以打动到技惊四座的moment,在一个方可让我们呐喊和流泪的minute,它就是全世界。

原文:http://www.microsoft.com/china/msdn/library/webservices/asp.net/WebAppFollies.mspx?mfr=true

   
跟所有的体育运动一样,电子竞赛的魅力是宏伟的。老话说“音乐不分国界”,其实所有具有感染力的东西都是这么,电竞也不例外。再狭隘的民族主义者也无力回天否认Faker对LOL的进献和含义,大家既然喜欢竞赛,就该学会分享高品位的比赛。队员的国籍所属并无法改变竞技本身的美观程度,一味鼓吹血统论只好让LPL陷入倒退的窘境。有人说,SKT终于是在鸟巢被三星给击倒了,他们的朝代也毕竟是终止了,于是理所应当的,Faker也是跌下了神坛,这到底是王朝的宿命,也是比赛的魅力所在。没有人能永远一枝独秀,没有人能强盛,有的直接都是强者居上,新的笔录和新的神话再随地被刷新和开创,同时,这也是比赛将平素留存和持续前进前行的来由所在。

ASP.NET 成功的内部一个原因在于它降低了 Web
开发人士的门径。即使你不是电脑科学学士也可以编写 ASP.NET
代码。我在工作中境遇的不在少数 ASP.NET 开发人员都是自学成材的,他们在编辑
C# 或 Visual Basic® 从前都在编排 Microsoft® Excel®
电子表格。现在,他们在编辑 Web
应用程序,总的来说,他们所做的做事值得赞誉。

   
明天要讲的主人翁,是LOL界最了不起的人,而且没有之一。方今时常听到legends
never
die这首歌,总会记念这多少个在半决赛舞台上哭泣的男孩,固然他早就21了,但自我想,输掉比赛的那一刻,他一定就是个儿女,无助、失落、懊恼、不甘那一个所有类似于悲伤的心怀交织在他左右,彻底粉碎了他这颗曾经最为强大的心。很五人说,三十年河东,三十年河西,曾经的李相赫打哭那么多少人,此刻不过是物换星移,主角也换了私家而已。对于观众而言,没有人乐于只见到一个朝代,人们无形中里面,激荡的就是抵御,抗拒一个神话最好的点子——但是就是创制一个新的神话,因为唯有一个神话终究是会令人厌倦的。

可是与力量随之而来的还有责任,尽管是经验丰硕的 ASP.NET
开发人士也难免会出错。在多年的 ASP.NET
项目咨询工作中,我发现某些错误特别容易导致缺陷不断发出。其中一些错误会潜移默化属性。其他错误会制止可伸缩性。有些错误还会使支付公司耗费宝贵的大运来跟踪错误和意外的行为。

   
但对于,faker而言,他绝没有倒下。作为一个出道就终端,而且在其世界登上世界之巅的人,世界历史上也找不出好多少个,所以她迟早是万幸的那些,中国人笃信“天选之人”,认为“命由天定”,强如孟子,开篇也是“天将降大任于是人也”。如若有,那么李相赫他必定是。但我们清楚,电子竞赛是实力说话,空谈理想,一定会让自己距离最初的轨道。出道的第二个赛季,也就是取得最高的光荣后,faker他碰到到了英雄的战败和挫折,他的私房处境第一次有了沉降,随之他的军旅也分崩离析,最后留下来的,唯有苦苦坚韧不拔的她和她的亲热战友bengi,那么些王的老公。接下来的故事也许我们都了然了,卷土重来的SKT,又连续两年囊括了S系列赛和几乎拥有大小赛事的荣幸。但是,二零一九年,他们又倒下了,但必然,2019年faker的演出相对不止算职业生涯的第二春,应该只好用精妙绝伦来描写。作为已经跌落过神坛的爱人,没有什么比这一回更能让她倍感轻松和最好的熨帖了,他早就经历过四遍大的失败,那几遍,他只需要持续学习,以更成熟的态势归来。因为假如她是faker,他就绝不会倒下。

下边是会造成 ASP.NET 生产应用程序的发表过程中出现问题的 10
个毛病以及可避免它们的主意。所有示例均源于自身对实在的商家构建真正的 Web
应用程序的切身感受,在某些处境下,我会通过介绍 ASP.NET
开发社团在付出进程中相遇的有些问题来提供相关的背景。

   
要是把faker的史事换来任何领域,他都应该是我们的典范,他既谦虚又傲慢;忠于自己的老东家不丢掉不放任;失利时候首先找自己原因,而不是平素指责队友;他有礼貌,话虽然不多,但充满灵性;他爱慕他的每一个对手,充满职业精神。像她这么的人,你要知道,也才21岁。传奇在于拼搏,至高的荣誉不是每个人都能企及的,强如UZI,pray,没有人质疑他们的实力,去终不可能避免于无冠。拼搏,不仅是电竞精神,更是人活在世上应有的态度。Legends
never die,嗯,这就是传奇永不灭,这句话肯定是为faker量身定做的。

LoadControl 和输出缓存

极少有不采取用户控件的 ASP.NET
应用程序。在出现母版页在此之前,开发人士使用用户控件来提取公用内容,如页眉和页脚。就算在
ASP.NET 2.0
中,用户控件也提供了实惠的方法来封装内容和行事以及将页面分为四个区域,这一个区域的缓存能力可以独自于作为完整的页面进行支配(一种叫做段缓存的奇异输出缓存形式)。

用户控件可以动用阐明的不二法门加载,也足以强制加载。强制加载看重于
Page.LoadControl,它实例化用户控件并再次回到控件引用。假如用户控件包含自定义类型的分子(例如,公共性质),则您可以转移该引用并从您的代码访问自定义成员。
1

中的用户控件实现名为 BackColor 的性能。以下代码加载用户控件并向
BackColor 分配一个值:

protected void Page_Load(object sender, EventArgs e)
{
// 加载用户控件并将其添加到页面中
Control control = LoadControl("~/MyUserControl.ascx");
PlaceHolder1.Controls.Add(control);
// 设置其背景色
((MyUserControl)control).BackColor = Color.Yellow;
}

如上代码实际上很简短,但却是一个等待粗心的开发人员掉进去的骗局。您能找出其中的破碎吗?

假如您猜到该问题与输出缓存有关,那么你是无可非议的。正如您所观察的等同,上述代码示例编译和周转都健康,可是借使尝试将以下语句(完全合法)添加到
MyUserControl.ascx 中:

<%@ OutputCache Duration="5" VaryByParam="None" %>

则当您下一遍运行该页面时,您将见到 InvalidCastException (oh joy!)
和以下错误音信:

“无法将类型为‘System.Web.UI.PartialCachingControl’的对象转换为类型‘MyUserControl’。”

之所以,此代码在尚未 OutputCache 指令时运行如常,但假诺添加了 OutputCache
指令就会出错。ASP.NET
不应有以这种方法运行。页面(和控件)对于出口缓存应该是不可知的。那么,那表示怎么样看头?

题目在于为用户控件启用输出缓存时,LoadControl
不再回来对控件实例的引用;相反,它回到对 PartialCachingControl
实例的引用,而 PartialCachingControl
可能会也说不定不会卷入控件实例,具体取决于控件的输出是否被缓存。由此,假如开发人士调用
LoadControl
以动态加载用户控件并且为了访问控件特定的主意和性质而更换控件引用,他们不能够不小心举办该操作的章程,以便不管是不是拥有
OutputCache 指令,代码都可以运作。


2

表达动态加载用户控件以及转换重临的控件引用的正确性方法。以下是其工作规律概要:

如果 ASCX 文件缺少 OutputCache 指令,则 LoadControl 返回一个 MyUserControl 引用。Page_Load 将该引用转换为 MyUserControl 并设置控件的 BackColor 属性。

如果 ASCX 文件包括一个 OutputCache 指令并且控件的输出没有被缓存,则 LoadControl 返回一个对 PartialCachingControl 的引用,此 PartialCachingControl 的 CachedControl 属性包含对基础 MyUserControl 的引用。Page_Load 将 PartialCachingControl.CachedControl 转换为 MyUserControl 并设置该控件的 BackColor 属性。

如果 ASCX 文件包括一个 OutputCache 指令并且控件的输出被缓存,则 LoadControl 返回一个对 PartialCachingControl(其 CachedControl 属性为空)的引用。注意,Page_Load 不再继续执行操作。无法设置控件的 BackColor 属性,因为该控件的输出来源于输出缓存。换句话说,根本没有要设置属性的 MyUserControl。

不论 .ascx 文件中是不是具有 OutputCache 指令,
2
中的代码都将运行。虽然看起来复杂一点,但它会制止烦人的一无是处。简单并不总是代表容易维护。

足球 1回来页首

   
最终部分话,送给自己原先的战友们,比起体育的篮球足球网球之类,LOL一定有走到尽头的那一天,人都有透支自己喜好的那一天,一个游戏终究只好承载一代人的追忆,老玩家的消散,没有新鲜血液的融入,更面临新兴娱乐的挑衅,这就是他眼前的窘境。有人说,玩lol的人少了,是因为刚起先接触这批游戏的人都老了,他们也许都有了温馨的做事和家园,有了生存中更值得尊重的事物和更值得爱的人。世界的方方面面事物,都是在动态发展着的,盛衰之势常有,我们不用惋惜,他将离大家而去,逐渐淡出大家的视野和生存。但作为体育的电子竞赛,其旺盛是绝不会倒下的。这才是legends
never die的最终奥义,或许。

对话和出口缓存

谈到输出缓存,ASP.NET 1.1 和 ASP.NET 2.0
都存在一个秘密的题材,该问题会潜移默化在 Windows Server™ 2003 和 IIS 6.0
上运行的服务器中的输出缓存页。我早就亲眼看到该问题在 ASP.NET
生产服务器中出现过五次,这五遍都是通过关闭输出缓冲来化解的。后来自家精通到有一个比禁用输出缓存更好的解决方案。以下是我首先次遇上该问题时的状态。

旋即的图景是这样的,某个网站(我们在此称呼 Contoso.com,它在小型 ASP.NET
Web
领域中运行公共电子商务应用程序)与自我的团队交流,抱怨他们遭逢了“跨线程”错误。使用
Contoso.com
网站的客户通常突然不见已经输入的数据,但却见到另一用户的连锁数据。稍做分析即发现,跨线程这么些描述并不确切;“跨会话”错误越来越适合。看起来
Contoso.com
是在对话状态中存储数据的,由于某些原因,用户会有时随机地接连到其他用户的对话。

我的一个团社团成员编写了一个确诊工具,用来将各种 HTTP
请求和响应的重要要素(包括 库克(Cook)ie
标头)记录到日志中。然后,他将该工具安装在 Contoso.com 的 Web
服务器上,并让其运行了几天。结果充裕强烈。大概每 100000
个请求中会暴发一回这样的图景:ASP.NET 正确地为全新会话分配一个会话 ID
并回到 Set-库克ie 标头中的会话
ID。然后,它会在下一个紧相邻的哀告中回到相同的对话 ID(即,相同的
Set-Cookie 标头),尽管该请求已经与一个可行的对话相关联并且正确提交了
Cookie 中的会话 ID。实际上,ASP.NET
是不管三七二十一将用户从他们友善的对话中切换出去并将她们总是到任何会话。

大家很惊叹,于是从头物色原因。大家第一检查了 Contoso.com
的源代码,让我们倍感宽慰的是,问题不在这。接着,为了保险问题与应用程序宿主在
Web
领域无关,我们只保留一个服务器在运作,而关门了独具其他服务器。问题依旧存在,这并不奇怪,因为我们的日志突显匹配的
Set-Cookie 标头绝不会来自多少个例外的服务器。ASP.NET
意外地生成了再次的对话 ID,这令人难以置信,因为它利用 .NET Framework
RNGCrypto瑟维斯(Service)(Service)Provider 类生成那些 ID,并且会话 ID 的长短可以保证同等的
ID 决不会扭转一回(至少在下一个万亿年内不会转移两回)。除此之外,即便RNGCrypto瑟维斯(Service)Provider 错误地生成了再也的任性数字,也无法解释 ASP.NET
为什么不可名状地将使得的对话 ID 替换为新的 ID(不唯一)。

凭直觉,大家决定看一下出口缓存。当 OutputCacheModule 缓存 HTTP
响应时,它必须小心不要缓存了 Set-库克(Cook)ie 标头;否则,包含新会话 ID
的缓存响应会将缓存响应的所有接收者(以及其请求生成了缓存响应的用户)连接到同一会话。大家检查了源代码;Contoso.com
在五个页面中启用了出口缓存。我们关闭了出口缓存。结果,应用程序运行数天而从不生出一个跨会话问题。此后,它运行了两年多都不曾暴发其他不当。在拥有不同应用程序和一组不同
Web 服务器的另一家商家中,大家看来完全相同的问题也不复存在了。就像在
Contoso.com 一样,消除输出缓存就能解决问题。

Microsoft 后来肯定此行为来源 OutputCacheModule
中的问题。(当你读书本文时,可能早就揭橥了更新。)当 ASP.NET 与 IIS 6.0
一起行使并且启用内核形式缓存时,OutputCacheModule 有时不能从它传递给
Http.sys 的缓存响应中剔除 Set-库克(Cook)ie
标头。下面是致使出现错误的特定事件顺序:

最近没有访问网站(因此也没有对应的会话)的用户请求一个启用了输出缓存的页面,但是其输出当前在缓存中不可用。

该请求执行用于访问用户最新创建的会话的代码,从而导致会话 ID Cookie 在响应的 Set-Cookie 标头中返回。

OutputCacheModule 向 Http.sys 提供输出,但是无法从响应中删除 Set-Cookie 标头。

Http.sys 在后续的请求中返回缓存响应,误将其他用户连接到会话。

故事的味道又是何等吧?会话状态和水源情势输出缓存无法混合使用。尽管你在启用输出缓存的页中使用会话状态,并且应用程序在
IIS 6.0
上运行,则您需要关闭内核格局输出缓存。您仍将收益于出口缓存,可是因为根本格局输出缓存比常常输出缓存快得多,所以缓存不会一如既往有效。有关此题材的详细信息,请参见
support.microsoft.com/kb/917072

您可以经过在页面的 OutputCache 指令中含有 VaryByParam=”*”
属性来关闭单个页面的水源情势输出缓存,即便这么做可能造成内存需求骤增。另一种更安全的不二法门是经过在
web.config 中带有下列元一向关闭所有应用程序的基础情势缓存:

<httpRuntime enableKernelOutputCache="false" />

您还足以动用注册表设置来全局性地剥夺内核形式输出缓存,即禁用所有服务器的根本模式输出缓存。有关详细音讯,请参见
support.microsoft.com/kb/820129

历次自我听到客户报告会话爆发了费解的问题,我都会驾驭她们是否在其它页面中拔取了出口缓存。如果实在使用了出口缓存,并且宿主操作系统是
Windows Server
2003,我会提出他们禁用内核形式输出缓存。问题一般就会迎刃而解。假设问题尚未解决,则错误存在于代码中。警惕!

足球 2重返页首

Forms 身份验证票证生存期

您能找出以下代码的问题吧?

FormsAuthentication.RedirectFromLoginPage(username, true);

此代码看似没有问题,但决无法在 ASP.NET 1.x
应用程序中采纳,除非应用程序中另外职务的代码抵消了此语句的阴暗面效用。假如你不可能确定原因,请继续读书。

FormsAuthentication.RedirectFromLoginPage 执行五个任务。首先,当
FormsAuthenticationModule
将用户重定向到登录页时,FormsAuthentication.RedirectFromLoginPage
将用户重定向到他们本来请求的页面。其次,它揭露一个身份验证票证(平常带领在
Cookie 中,而且在 ASP.NET 1.x 中接二连三辅导在 Cookie
中),这些单子允许用户在预定的一段时间内维持已透过身份验证状态。

题目就在于这么些时刻段。在 ASP.NET 1.x 中,向 RedirectFromLoginPage
传递另一个为 false 的参数会发生一个暂时身份验证票证,该票证默认情形下在
30 分钟过后到期。(您可以应用 web.config 的 元素中的 提姆(Tim)eout
属性来更改超时期限。)然则,传递另一个为 true
的参数则会发生一个永恒身份验证票证,其有效期为 50
年!这样就会生出问题,因为只要有人窃取了该身份验证票证,他们就能够在单据的有效期内利(内尔y)用受害者的地点走访网站。窃取身份验证票证有多种艺术

在公私无线访问点探测未加密的通信、跨网站编写脚本、以物理形式访问受害者的总括机等等
— 因而,向 RedirectFromLoginPage 传递 true
比禁用你的网站的安全性好持续多少。幸运的是,此问题早已在 ASP.NET 2.0
中拿到了化解。现在的 RedirectFromLoginPage 以同一的法子接受在 web.config
中为临时和世代身份验证票证指定的晚点。

一种缓解方案是决不在 ASP.NET 1.x 应用程序的 RedirectFromLoginPage
的第二个参数中传递
true。可是这不切实际,因为登录页的表征一般是包含一个“将自己保持为记名情状”框,用户可以选中该框以吸纳永久而不是暂时身份验证
Cookie。另一种缓解方案是运用 Global.asax(倘使你愿意的话,也得以采用HTTP 模块)中的代码段,此代码段会在含有永久身份验证票证的 Cookie
重回浏览器在此之前对其开展修改。


3

包含一个如此的代码段。倘诺此代码段位于 Global.asax 中,它会修改传出永久
Forms 身份验证 库克ie 的 Expires 属性,以使 Cookie 在 24
刻钟后过期。通过改动注释为“新的晚点日期”的行,您可以将过期设置为你喜欢的其他日期。

您或许会以为意外,Application_EndRequest 方法调用本地 Helper 方法
(GetCookieFromResponse) 来检查身份验证 库克ie 的传播响应。Helper
方法是釜底抽薪 ASP.NET 1.1 中另一个荒唐的方法,虽然您使用
Http库克ieCollection 的字符串索引生成器来检查不存在的
库克ie,此错误会招致虚假 库克ie 添加到响应中。使用整数索引生成器作为
Get库克(Cook)ieFromResponse 可以化解该问题。

足球 3回到页首

视图状态:无声的习性杀手

从某种意义上说,视图状态是平素最宏伟的事情。毕竟,视图状态使得页面和控件可以在回发之间保持状态。由此,您不要像在观念的
ASP
中那么编写代码,以防范在单击按钮时文本框中的文本消失,或在回发后重新查询数据库和再次绑定
DataGrid。

不过视图状态也有欠缺:当它增长得过大时,它便成为一个落寞的特性杀手。某些控件(例如文本框)会遵照视图状态作出相应判断。其他控件(特别是
DataGrid 和 GridView)则依据显示的音讯量确定视图状态。如果 GridView 显示200 或 300 行数据,我会望而生畏。即便 ASP.NET 2.0 视图状态大致是 ASP.NET
1 x 视图状态的一半轻重缓急,一个糟糕的 GridView 也足以容易地将浏览器和 Web
服务器之间的接连的有效带宽减弱 50% 或更多。

你可以透过将 EnableViewState 设置为 false
来关闭单个控件的视图状态,但某些控件(特别是
DataGrid)在无法动用视图状态时会失去某些职能。控制视图状态的更佳解决方案是将其保存在服务器上。在
ASP.NET 1.x 中,您可以重写页面的 LoadPageStateFromPersistenceMedium 和
SavePageStateToPersistenceMedium 方法并按您喜爱的法门处理视图状态。
4

中的代码彰显的重写可防范视图状态保留在隐藏字段中,而将其保存在对话状态中。当与默认会话状态进程模型一起行使时(即,会话状态存储在内存中的
ASP.NET
匡助进程中时),在对话状态中储存视图状态更是有效。相反,假若会话状态存储在数据库中,则只有测试才能显示在对话状态中保留视图状态会加强或者下降性能。

在 ASP.NET 2.0 中应用相同的主意,不过 ASP.NET 2.0
能够提供更简便易行的法门将视图状态保留在对话状态中。首先,定义一个自定义页适配器,其
GetStatePersister 方法再次来到 .NET Framework SessionPageStatePersister
类的一个实例:

public class SessionPageStateAdapter :
System.Web.UI.Adapters.PageAdapter
{
public override PageStatePersister GetStatePersister ()
{
return new SessionPageStatePersister(this.Page);
}
}

接下来,通过将 App.browsers 文件按以下方法放入应用程序的 App_Browsers
文件夹,将自定义页适配器注册为默认页适配器:

<browsers>
<browser refID="Default">
<controlAdapters>
<adapter controlType="System.Web.UI.Page"
adapterType="SessionPageStateAdapter" />
</controlAdapters>
</browser>
</browsers>

(您可以将文件命名为您喜爱的此外名称,只要它的恢弘名为 .browsers
即可。)此后,ASP.NET 将加载页适配器并采取重回的
SessionPageStatePersister 以保存所有页面状态,包括视图状态。

利用自定义页适配器的一个瑕疵是它全局性地效用于应用程序中的每一页。假设你更愿意将里面部分页面的视图状态保留在对话状态中而不保留其他页面的视图状态,请使用
4

中展现的主意。此外,如若用户在同一会话中开创六个浏览器窗口,您使用该办法可能会碰到题目。

足球 4回去页首

SQL Server 会话状态:另一个性能杀手

ASP.NET 使得在数据库中储存会话状态变得简单:只需切换 web.config
中的开关,会话状态就会轻松地移动到后端数据库。对于在 Web
领域中运行的应用程序来说,这是一项首要效率,因为它同意该领域中的每个服务器共享会话状态的一个公共库。添加的数据库活动降低了单个请求的性质,可是可伸缩性的滋长弥补了性能的损失。

这看起来都还不易,但是你略微考虑一下下列几点,情状就会有所不同:

即使在使用会话状态的应用程序中,大多数页也不使用会话状态。

默认情况下,ASP.NET 会话状态管理器对每个请求中的会话数据存储执行两个访问(一个读取访问和一个写入访问),而不管请求的页是否使用会话状态。

换句话说,当您使用 SQL Server™
会话状态选项时,您在每个请求中都要付出代价(五个数据库访问)—
甚至在与会话状态无关的页面的请求中。这会直接对总体网站的吞吐量造成负面影响。

 

足球 5

图 5 消除不必要的对话状态数据库访问

 

这就是说您应该怎么做呢?很简单:禁用不采纳会话状态的页中的会话状态。这样做总是一个好方法,然则当会话状态存储在数据库中时,该办法更加关键。图
5 彰显怎么禁用会话状态。假诺页面根本不行使会话状态,请在其 Page
指令中富含 EnableSessionState=”false”,如下所示:

<%@ Page EnableSessionState="false" ... %>

该指令阻止会话状态管理器在各种请求中读取和写入会话状态数据库。假若页面从会话状态中读取数据,但却不写入数据(即,不修改用户会话的情节),则将
EnableSessionState 设置为 ReadOnly,如下所示:

<%@ Page EnableSessionState="ReadOnly" ... %>

终极,假若页面需要对会话状态举办读/写访问,则省略 EnableSessionState
属性或将其设置为 true:

<%@ Page EnableSessionState="true" ... %>

通过以这种方法决定会话状态,可以确保 ASP.NET
只在真正需要时才访问会话状态数据库。消除不必要的数据库访问是构建高性能应用程序的率先步。

附带说一下,EnableSessionState 属性是光天化日的。该属性自 ASP.NET 1.0
以来就曾经举办了认证,然而自己至今仍很少看到开发人士利用该属性。也许是因为它对于内存中的默认会话状态模型并不特别要害。然而它对于
SQL Server 模型却很要紧。

足球 6回到页首

未缓存的角色

以下语句平日出现于 ASP.NET 2.0 应用程序的 web.config 文件以及介绍
ASP.NET 2.0 角色管理器的示范中:

<roleManager enabled="true" />

但相比以上所示,该语句实在会对性能暴发显明的负面影响。您明白为啥吧?

默认境况下,ASP.NET 2.0
角色管理器不会缓存角色数据。相反,它会在历次需要确定用户属于哪个角色(假诺有)时参考角色数据存储。那表示假诺用户通过了身份验证,任何利用角色数据的页(例如,使用启用了平安缩小设置的网站图的页,以及利用
web.config 中基于角色的 URL
指令举行走访受到限制的页)将导致角色管理器查询角色数据存储。如若角色存储在数据库中,那么对于每个请求需要拜访六个数据库的动静,您可以轻松地排除访问几个数据库。解决方案是安排角色管理器以在
Cookie 中缓存角色数据:

<roleManager enabled="true" cacheRolesInCookie="true" />

您可以使用其他<roleManager> 属性控制角色 库克(Cook)ie 的特性 —
例如,Cookie
应保持有效的限期(以及角色管理器由此回到角色数据库的效能)。角色 库克(Cook)ie
默认情形下是透过签字和加密的,由此安全风险即使不为零,但也享有缓解。

足球 7归来页首

安排文件属性系列化

ASP.NET 2.0
配置文件服务为维持每个用户的意况(例如个性化首选项和言语首选项)的题材提供了一个现成的化解方案。要选取安排文件服务,您可以定义一个
XML 配置文件,其中富含要保留的意味单个用户的性能。然后,ASP.NET
编译一个饱含相同属性的类,并由此充裕到页的部署文件属性提供对类实例的强类型访问。

部署文件灵活性很强,它甚至同意将自定义数据类型用作配置文件属性。不过,其中却存在一个题目,我亲眼看到该问题造成开发人员出差错。
6

包含一个名为 Posts 的简单类,以及将 Posts
用作安排文件属性的布局文件定义。不过,该类和该配置文件在运转时会发生意想不到的所作所为。您能找出里面的因由吧?

问题在于 Posts 包含一个名为 _count
的私有字段,该字段必须举办系列化和反系列化,才能一心结冰和重复冻结类实例。可是
_count 却从不经过连串化和反序列化,因为它是私家的,而且默认意况下
ASP.NET 配置文件管理器使用 XML
体系化对自定义类型举行连串化和反系列化。XML
体系化程序将忽略非公共成员。由此,会对 Posts
的实例举办系列化和反体系化,可是每回反体系化类实例时,_count 都会重设为
0。

一种缓解方案是使 _count
成为国有字段而非私有字段。另一种缓解方案是利用集体读/写属性封装
_count。最佳解决方案是将 Posts 标记为可类别化(使用
SerializableAttribute),并将安排文件管理器配置为运用 .NET Framework
二进制类别化程序对类实例举办体系化和反连串化。该解决方案可以保持类本身的统筹。与
XML
连串化程序不同的是,二进制体系化程序系列化字段,而不论是不是能够访问。
7

显示 Posts 类的修复版本并鼓起显示了改变的附带配置文件定义。

你应该牢记的一些是,假使你使用自定义数据类型作为配置文件属性,并且该数据类型具有必须序列化才能一心系列化类型实例的非公共数据成员,则在性质表明中采纳serializeAs=”Binary”
属性并保证项目我是可连串化的。否则,将无法开展总体的体系化,并且您还将浪费时间来尝试确定安排文件不能工作的原因。

足球 8重临页首

线程池饱和

在实施数据库查询并听候 15
秒或更长日子来取得重返的询问结果时,我日常对看到的实际上的 ASP.NET
页数感到至极讶异。(我也拭目以待了 15
秒钟才来看查询结果!)有时,延迟是出于重回的数据量很大而导致的不可制止的无可奈何结果;而有时,延迟则是由于数据库的统筹糟糕导致的。但不论是何等原因,长日子的数据库查询或任何类型的长日子
I/O 操作在 ASP.NET 应用程序中都会导致吞吐量的下跌。

有关这么些问题我原先曾经详细地叙述过,所以在此就不再作过多的注明了。我只说一点就够了,ASP.NET
看重于个其它线程池处理请求,尽管持无线程都被占据来等待数据库查询、Web
服务调用或任何 I/O
操作完成,则在某个操作完成而且释放出一个线程此前,其他请求都不可以不排队等待。当呼吁排队时,性能会急剧下降。假如队列已满,则
ASP.NET 会使随后的伏乞败北并冒出 HTTP 503 错误。那种气象不是我们意在在
Web 生产服务器的生育应用程序上所乐见的。

缓解方案非异步页面莫属,这是 ASP.NET 2.0
中极品却鲜为人知的效用之一。对异步页面的伸手从一个线程上上马,不过当它先河一个
I/O 操作时,它将回到该线程以及 ASP.NET 的 IAsyncResult
接口。操作完成后,请求通过 IAsyncResult 布告 ASP.NET,ASP.NET
从池中领取另一个线程并形成对请求的拍卖。值得注意的是,当 I/O
操作爆发时,没有占用线程池线程。这样可以通过阻止其他页面(不履行较长的
I/O 操作的页面)的乞求在队列中伺机,从而显然地增进吞吐量。

您可以在 MSDN®Magazine 的 2005 年 10
月刊
中阅读有关异步页面的富有消息。I/O
绑定而不是统计机绑定且需要很长日子执行的此外页面很有可能变成异步页面。

当自己将有关异步页面的消息告知开发人士时,他们通常回答“这真是太棒了,不过自己的应用程序中并不需要它们。”对此我回答说:“你们的此外页面需要查询数据库吗?它们调用
Web 服务啊?您是不是业已检查 ASP.NET
性能计数器中有关排队请求和平均等待时间的总结音信?固然你的应用程序至今运行正常化,不过随着您的客户规模的提升,应用程序的载荷可能会追加。”

实则,绝大多数事实上的 ASP.NET 应用程序都急需异步页面。请记住这点!

足球 9归来页首

模拟和 ACL 授权

以下是一个简便的部署指令,不过每当在 web.config
中见到它时都让我美观:

<identity impersonate="true" />

此命令在 ASP.NET
应用程序中启用客户端模拟。它将意味客户端的拜访令牌附加到处理请求的线程,以便操作系统执行的安全性检查针对的是客户端身份而不是赞助进程身份。ASP.NET
应用程序很少需要效法;我的经验告诉我,开发人士经常都是出于错误的由来而启用模拟的。以下是原因所在。

开发人员常常在 ASP.NET
应用程序中启用模拟,以便可以利用文件系统权限来界定对页面的访问。要是 Bob没有翻动 Salaries.aspx
的权限,则开发人员将会启用模拟,以便可以经过将访问控制列表 (ACL)
设置为拒绝 鲍勃 的读取权限,阻止 鲍伯 查看
Salaries.aspx。不过存在以下隐患:对于 ACL 授权来说,模拟是不必要的。在
ASP.NET 应用程序中启用 Windows 身份验证时,ASP.NET 会活动为呼吁的各样.aspx 页面检查 ACL
并驳回没有读取文件权限的调用者的呼吁。尽管禁用了效仿,它仍会这样操作。

一些时候需要申明模拟的创造。但是你平常可以用精良的筹划来避免它。例如,假定
Salaries.aspx
在数据库中询问只有管理人士才能知晓的薪资音信。通过模拟,您可以应用数据库权限拒绝非管理人员查询工资多少的能力。或者你可以不考虑模拟,并且经过为
Salaries.aspx 设置 ACL
以使非管理人员不负有读取权限,从而限制对工资数据的拜访。后一种艺术提供的特性更佳,因为它完全避免了模拟。它也免除了不必要的数据库访问。为何查询数据库仅出于安全原因被拒绝?

顺便说一下,我一度帮忙对一个价值观的 ASP
应用程序举办故障排除,该应用程序由于内存占用不受限制而定期重新开动。一个并未经历的开发人士将对象
SELECT 语句转换成了 SELECT
*,而尚未考虑要询问的表包含图像,这一个图像很大并且数量很多。问题由于未检测到内存泄漏而恶化。(我的托管代码领域!)多年来运作正常化的应用程序先导突然截至工作,因为在此以前再次来到一两千字节数量的
SELECT
语句现在却再次回到了几兆字节。假诺再添加不丰富的版本控制,开发社团的生活将只好“亢奋起来”—
这里所谓的“亢奋”,就如同当你在夜间要睡觉时,还只可以看着您的儿女玩令人讨厌的足球游戏一样。

足球,力排众议上,传统的内存泄漏不会时有暴发在完全由托管代码组成的 ASP.NET
应用程序中。不过内存使用量不足会通过强制垃圾收集更频繁地发出而影响属性。即便是在
ASP.NET 应用程序中,也要居安思危 SELECT *!

足球 10再次来到页首

不用完全相信它 — 请设置数据库的配备文件!

作为一名顾问,我时时被问询为什么应用程序没有按预想执行。如今,有人询问我的团体为什么ASP.NET 应用程序只完成请求文档所需吞吐量(每秒的请求数)的大约
1/100。大家原先所发现的问题是我们在不可以正常运作的 Web
应用程序中发觉的题材特有的 — 和我们所有人应该认真对照的教训。

咱们运行 SQL Server Profiler
并监视此应用程序和后端的数据库之间的竞相情状。在一个更极致的案例中,仅仅只是一个按钮单击,就导致数据库暴发了
1,500
六个谬误。您不可能那么构建高性能的应用程序。卓越的系统布局总是从优良的数据库设计开端。不管你的代码的频率有多高,即便它被编辑不好的数据库所拖累,就会不起功用。

不佳的数量访问体系布局常常来自下边的一个或三个方面:

拙劣的数据库设计(通常由开发人员设计,而不是数据库管理员)。

DataSets 和 DataAdapters 的使用 — 尤其是 DataAdapter.Update,它适用于 Windows 窗体应用程序和其他胖客户端,但是对于 Web 应用程序来说通常不理想。

具有拙劣编制计算程序、以及执行相对简单的操作需消耗很多 CPU 周期的设计糟糕的数据访问层 (DAL)。

必须先确定问题才能对其举行拍卖。确定数据访问问题的不二法门是运作 SQL Server
Profiler
或一致的工具以查看后台正在实施的操作。检查应用程序和数据库之间的通信之后,性能调整才大功告成。尝试一下
— 您可能会对您的发现震惊。

足球 11回去页首

结论

如今您曾经精通在生成 ASP.NET
生产应用程序过程中或许遇见的片段题材及其解决方案了。下一步是仔细查看您自己的代码并尝试防止自己在此概述的一些问题。ASP.NET
可能回落了 Web
开发人员的门径,然而你的应用程序完全有理由灵活、稳定和便捷。请认真考虑,制止出现新手易犯的谬误。


8

提供了一个简练检查列表,您可以接纳它来制止本文中讲述的毛病。您可以创造一个类似的安全缺陷检查列表。例如:

您是否已经对包含敏感数据的配置节进行加密?

您是否正在检查并验证在数据库操作中使用的输入,是否使用了 HTML编码输入作为输出?

您的虚拟目录中是否包含具有不受保护的扩展名的文件?

若果你重视网站、承载网站的服务器以及它们所依赖的后端资源的完整性,则这一个问题特别重大。