万众海浪论坛  
温馨提示今天是:

当网络繁忙时请选择:https://bbs.838778.com(线路一)https://bbs.939138.com(线路二)进入本站论坛。


 
标题: 大并发大数据量请求的处理方法
朗文
管理员
Rank: 12Rank: 12Rank: 12


UID 8
精华 6
积分 46771
帖子 2550
威望 46771 点
金钱 70591 RMB
阅读权限 200
注册 2005-11-5
状态 离线
 
发表于 2015-4-15 05:07  资料  个人空间  短消息  加为好友 
大并发大数据量请求的处理方法

大并发大数据量请求一般会分为几种情况:
1.大量的用户同时对系统的不同功能页面进行查找,更新操作
2.大量的用户同时对系统的同一个页面,同一个表的大数据量进行查询操作
3.大量的用户同时对系统的同一个页面,同一个表进行更新操作

对于第一种情况一般处理方法如下:
一。对服务器层面的处理
1. 调整IIS 7应用程序池队列长度
由原来的默认1000改为65535。
IIS Manager > ApplicationPools > Advanced Settings
Queue Length : 65535
2.  调整IIS 7的appConcurrentRequestLimit设置
由原来的默认5000改为100000。
c:\windows\system32\inetsrv\appcmd.exe set config /section:serverRuntime /appConcurrentRequestLimit:100000
在%systemroot%\System32\inetsrv\config\applicationHost.config中可以查看到该设置:
[html] view plaincopyprint?

  • <serverRuntime
    appConcurrentRequestLimit="100000"
    />

<serverRuntime appConcurrentRequestLimit="100000" />
3. 调整machine.config中的processModel>requestQueueLimit的设置
由原来的默认5000改为100000。
[html] view plaincopyprint?

  • <configuration>

  • <system.web>

  • <processModel
    requestQueueLimit="100000"/>

<configuration>    <system.web>        <processModel requestQueueLimit="100000"/>
4. 修改注册表,调整IIS 7支持的同时TCPIP连接数
由原来的默认5000改为100000。
reg add HKLM\System\CurrentControlSet\Services\HTTP\Parameteris /v MaxConnections /t REG_DWORD /d 100000

完成上述4个设置,就基本可以支持10万个同时请求。如果访问量达到10万以上,就可以考虑将程序和数据库按功能模块划分部署到多个服务器分担访问压力。另外可以考虑软硬件负载均衡。硬件负载均衡能够直接通过智能交换机实现,处理能力强,而且与系统无关,但是价格贵,配置困难,不能区分实习系统与应状态。所以硬件负载均衡适用于一大堆设备,大访问量,简单应用。软件负载均衡是基于系统与应用的,能过更好地根据系统与应用的状况来分配负载。性价比高。PCL负载均衡软件,Linux下的LVS软件。

二。对数据库层面的处理
      当两个用户同时访问一个页面,一个用户可能更新的是另一个用户已经删除的记录。或者,在一个用户加载页面跟他点击删除按钮之间的时间里,另一个用户修改了这条记录的内容。所以需要考虑数据库锁的问题

有下面三中并发控制策略可供选择:
Ø 什么都不做 –如果并发用户修改的是同一条记录,让最后提交的结果生效(默认的行为)
Ø 开放式并发(Optimistic Concurrency) - 假定并发冲突只是偶尔发生,绝大多数的时候并不会出现; 那么,当发生一个冲突时,仅仅简单的告知用户,他所作的更改不能保存,因为别的用户已经修改了同一条记录
Ø 保守式并发(Pessimistic Concurrency) – 假定并发冲突经常发生,并且用户不能容忍被告知自己的修改不能保存是由于别人的并发行为;那么,当一个用户开始编辑一条记录,锁定该记录,从而防止其他用户编辑或删除该记录,直到他完成并提交自己的更改
当多个用户试图同时修改数据时,需要建立控制机制来防止一个用户的修改对同时操作的其他用户所作的修改产生不利的影响。处理这种情况的系统叫做“并发控制”。
并发控制的类型通常,管理数据库中的并发有三种常见的方法:
  • 保守式并发控制 - 在从获取记录直到记录在数据库中更新的这段时间内,该行对用户不可用。
  • 开放式并发控制 - 只有当实际更新数据时,该行才对其他用户不可用。更新将在数据库中检查该行并确定是否进行了任何更改。如果试图更新已更改的记录,则将导致并发冲突。
  • 最后的更新生效 - 只有当实际更新数据时,该行才对其他用户不可用。但是,不会将更新与初始记录进行比较;而只是写出记录,这可能就改写了自上次刷新记录后其他用户所进行的更改。

保守式并发保守式并发通常用于两个目的。第一,在某些情况下,存在对相同记录的大量争用。在数据上放置锁所费的成本小于发生并发冲突时回滚更改所费的成本。
在事务过程中不宜更改记录的情况下,保守式并发也非常有用。库存应用程序便是一个很好的示例。假定有一个公司代表正在为一名潜在的客户检查库存。您通常要锁定记录,直到生成订单为止,这通常会将该项标记为“已订购”状态并将其从可用库存中移除。如果未生成订单,则将释放该锁,以便其他检查库存的用户得到准确的可用库存计数。
但是,在断开的结构中无法进行保守式并发控制。连接打开的时间只够读取数据或更新数据,因此不能长时间地保持锁。此外,长时间保留锁的应用程序将无法进行伸缩。
开放式并发在开放式并发中,只有在访问数据库时才设置并保持锁。这些锁将防止其他用户在同一时间更新记录。除了进行更新这一确切的时刻之外,数据始终可用。有关更多信息,请参见开放式并发
当试图更新时,已更改行的初始版本将与数据库中的现有行进行比较。如果两者不同,更新将失败,并引发并发错误。这时,将由您使用所创建的业务逻辑来协调这两行。
最后的更新生效当使用“最后的更新生效”时,不会对初始数据进行检查,而只是将更新写入数据库。很明显,可能会发生以下情况:
  • 用户 A 从数据库获取一项记录。
  • 用户 B 从数据库获取相同的记录,对其进行修改,然后将更新后的记录写回数据库。
  • 用户 A 修改“旧”记录并将其写回数据库。

在上述情况中,用户 A 永远也不会看到用户 B 作出的更改。如果您计划使用并发控制的“最后的更新生效”方法,则要确保这种情况是可以接受的。
ADO.NET 和 Visual Studio .NET 中的并发控制因为数据结构基于断开的数据,所以 ADO.NET 和 Visual Studio .NET 使用开放式并发。因此,您需要添加业务逻辑,以利用开放式并发解决问题。
如果您选择使用开放式并发,则可以通过两种常规的方法来确定是否已发生更改:版本方法(实际版本号或日期时间戳)和保存所有值方法。
版本号方法在版本号方法中,要更新的记录必须具有一个包含日期时间戳或版本号的列。当读取该记录时,日期时间戳或版本号将保存在客户端。然后,将对该值进行部分更新。
处理并发的一种方法是仅当 WHERE 子句中的值与记录上的值匹配时才进行更新。该方法的 SQL 表示形式为:
UPDATE Table1 SET Column1 = @newvalue1, Column2 = @newvalue2WHERE DateTimeStamp = @origDateTimeStamp
或者,可以使用版本号进行比较:
UPDATE Table1 SET Column1 = @newvalue1, Column2 = @newvalue2WHERE RowVersion = @origRowVersionValue
如果日期时间戳或版本号匹配,则表明数据存储区中的记录未被更改,并且可以安全地使用数据集中的新值对该记录进行更新。如果不匹配,则将返回错误。您可以编写代码,在 Visual Studio .NET 中实现这种形式的并发检查。您还必须编写代码来响应任何更新冲突。为了确保日期时间戳或版本号的准确性,您需要在表上设置触发器,以便在发生对行的更改时,对日期时间戳或版本号进行更新。
保存所有值方法使用日期时间戳或版本号的替代方法是在读取记录时获取所有字段的副本。ADO.NET 中的 DataSet 对象维护每个修改记录的两个版本:初始版本(最初从数据源中读取的版本)和修改版本(表示用户更新)。当试图将记录写回数据源时,数据行中的初始值将与数据源中的记录进行比较。如果它们匹配,则表明数据库记录在被读取后尚未经过更改。在这种情况下,数据集中已更改的值将成功地写入数据库。
对于数据适配器的四个命令(DELETE、INSERT、SELECT 和 UPDATE)来说,每个命令都有一个参数集合。每个命令都有用于初始值和当前值(或修改值)的参数。


对于第二种情况的处理:因为是大并发请求,也能采用第一种情况的处理方法,另外因为是对大数据量进行检索,所以需要考虑查询效率的问题
1.对表按查询条件建立索引
2.对查询语句进行优化
3.可以考虑对查询数据使用缓存

对于第三种情况的处理:
也能采用第一种情况的处理方法,另外因为是对同一个表进行更新操作,可以考虑使用下面的处理方法:
1.先将数据保存到缓存中,当数据达到一定的数量后,再更新到数据库中
2.将表按索引划分(分表,分区),如:对于一个存储全国人民信息的表,这个数据量是很大的,如果按省划分为多个表,在将全国的人民信息按省存储到相应的表中,然后根据省份对相应的并进行查询和更新,这样大并发和大数据量的问题就会减小很多
如果还有其他更好的方法,希望大家能指点一二






请收藏万众海浪网永久域名:①www.838668.comwww.939138.com  业务联系: 朗文 1836688338
顶部
朗文
管理员
Rank: 12Rank: 12Rank: 12


UID 8
精华 6
积分 46771
帖子 2550
威望 46771 点
金钱 70591 RMB
阅读权限 200
注册 2005-11-5
状态 离线
 
发表于 2015-4-17 05:28  资料  个人空间  短消息  加为好友 
C# 文件上传 默认最大为4M的解决方法

.net中默只能上传小于4m的文件,大于4M将无法显示页面.那么如何设置来使imputfile能上传更大的文件呢
1,环境:window 2003 ,IIS6.0
要首先要修改IIS6.0中的asp请求的最大字节数,默认时为200K;
方法:打开位于 C:\Windows\System32\Inetsrv 中的 metabase.XML,
并修改 AspMaxRequestEntityAllowed 为你需要的值(例如 "1073741824", 1GB);
技术背景:
在 IIS 6.0 中, AspMaxRequestEntityAllowed 属性指定了一个 ASP 请求(Request)可以使用的最大字节数. 如果 Content-Length 头信息中包含的请求长度超过了 AspMaxRequestEntityAllowed 的值, IIS 将返回一个 403 错误信息.
这个属性值与 MaxRequestEntityAllowed 相似, 但是是针对 ASP 请求的. 假如你知道自己的 ASP 应用只需要处理很少的请求数据, 你可以在 World Wide Web Publishing Service (WWW 发布服务)层级设定全局的 MaxRequestEntityAllowed 属性为 1MB, 并单独设定 AspMaxRequestEntityAllowed 为一个较小的值.
注意: 在编辑文件前请停止 IIS 服务, 否则无法保存修改后的文件.
也可以那么解决:
到微软站点载了IIS6 Resource Kit Tools(http://www.microsoft.com/downloa ... &displaylang=en),安装后利用Metabase Explorer修改了(local)\LM\W3SVC\AspMaxRequestEntityAllowed属性(默认为200K=204800),修改为1G就是了;同时修改了AspScriptTimeout属性调整下时限,就可以上传大文件了。
2,.net中
(1)在web.comfig文件中添加一个httpRuntime主键
<httpRuntime executionTimeout="90" maxRequestLength="40960" useFullyQualifiedRedirectUrl="false"
minFreeThreads="8" minLocalRequestFreeThreads="4" appRequestQueueLimit="100"/>
maxRequestLength="40960" 是最大的请求数,单位为:K
(2)修改C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG\machine.config文件
<httpRuntime executionTimeout="190" maxRequestLength="40960"
maxRequestLength="40960" 是最大的请求数,单位为:K
经实验,(1)和(2)只要一个就可以。

配置httpRuntime也可以让FileUpload上传更大的文件,不过设置太大了会因用户将大量文件传递到该服务器而导致的拒绝服务攻击(属性有说明)

<httpRuntime>

<httpRuntime useFullyQualifiedRedirectUrl="true|false"
       maxRequestLength="size in kbytes"
       executionTimeout="seconds"
       minFreeThreads="number of threads"
       minFreeLocalRequestFreeThreads="number of threads"
       appRequestQueueLimit="number of requests"
       versionHeader="version string"/>属性
属性 选项 说明
appRequestQueueLimit     ASP.NET 将为应用程序排队的请求的最大数目。当没有足够的自由线程来处理请求时,将对请求进行排队。当队列超出了该设置中指定的限制时,将通过“503 - 服务器太忙”错误信息拒绝传入的请求。
executionTimeout     指示在被 ASP.NET 自动关闭前,允许执行请求的最大秒数。
enable  指定是否在当前的节点及子节点级别启用应用程序域。默认值为 true。
    true 指定启用应用程序域。
    false 指定禁用应用程序域。应用程序将不会在内存中加载,任何客户端请求将导致出现错误号为 404 的错误。
idleTimeOut     指定应用程序域在经过多长的空闲时间后将予以关闭。默认值为 20 分钟。
enableKernelModeCache  指定是否启用输出缓存。目前,该属性只有在安装 IIS 6.0 版或更高版本之后才起相应的作用。输出缓存的配置和请求的类型决定了是否对内容进行缓存。
若要对响应进行缓存,必须满足以下条件:

必须通过页面指令或使用缓存 API 显式启用缓存。
缓存必须具有过期策略,以便内核知道何时放弃缓存。
缓存不能有任何变量标头或参数。
请求不能要求进行任何身份验证。

true 指定启用缓存。
false 指定禁用缓存。
maxRequestLength     指示 ASP.NET 支持的最大文件上载大小。该限制可用于防止因用户将大量文件传递到该服务器而导致的拒绝服务攻击。指定的大小以 KB 为单位。默认值为 4096 KB (4 MB)。
minFreeLocalRequestFreeThreads     ASP.NET 保持的允许执行新本地请求的自由线程的最小数目。该线程数目是为从本地主机传入的请求而保留的,以防某些请求在其处理期间发出对本地主机的子请求。这避免了可能的因递归重新进入 Web 服务器而导致的死锁。
minFreeThreads     允许执行新请求的自由线程的最小数目。ASP.NET 为要求附加线程来完成其处理的请求使这些线程保持自由状态。
useFullyQualifiedRedirectUrl     指示客户端重定向是否是完全限定的(采用 {HYPERLINK "http://server/path" } 格式,这是某些移动控件所必需的),或者指示是否代之以将相对重定向发送到客户端。
    true 指定客户端重定向需要以完全限定的格式发送。这是通过自动将不是完全限定的格式的所有重定向转换为完全限定的格式来实现的。
    false 指定客户端重定向不需要被自动转换为完全限定格式。false 是默认选项。
versionHeader     指定 ASP.NET 随每个响应所发送的版本头的值。Microsoft Visual Studio .NET 使用该属性来确定当前使用的 ASP.NET 版本。这对产品环境来说不是必需的,并且可以通过从 Web.config 或 Machine.config 移除该属性,或将该属性设置为空字符串 (versionHeader="") 来将其禁用。






请收藏万众海浪网永久域名:①www.838668.comwww.939138.com  业务联系: 朗文 1836688338
顶部
朗文
管理员
Rank: 12Rank: 12Rank: 12


UID 8
精华 6
积分 46771
帖子 2550
威望 46771 点
金钱 70591 RMB
阅读权限 200
注册 2005-11-5
状态 离线
 
发表于 2015-4-17 05:32  资料  个人空间  短消息  加为好友 
修改Windows Server 2008+IIS 7+ASP.NET默认连接限制,支持海量并发连接数

 WIN7中IIS7默认配置的服务器同时最多只能处理5000个请求,如果由于某些情况(程序问题等)造成同时请求超过5000时,将会导致服务器错误。为此,修改服务器的设置,从而支持10万个同时请求。  具体设置如下:
1. 调整IIS7应用程序池队列长度
  依次打开,IIS管理器 > 应用程序池 > 高级设置,修改队列长度为65535




2.  调整IIS 7的appConcurrentRequestLimit设置

  打开%systemroot%\System32\inetsrv\config\applicationHost.config,将appConcurrentRequestLimit的值由默认5000改为100000
<serverRuntime appConcurrentRequestLimit="100000" />


  也可以直接在运行中执行:
c:\windows\system32\inetsrv\appcmd.exe set config /section:serverRuntime /appConcurrentRequestLimit:100000

3. 调整machine.config中的processModel>requestQueueLimit的设置

  打开%windir%\Microsoft.NET\Framework\v4.0.30319\Config\machine.config,将requestQueueLimit的值由默认5000改为100000
<configuration>      <system.web>          <processModel requestQueueLimit="100000"/>  



4. 修改注册表,调整IIS 7支持的同时TCPIP连接数
在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters节,将默认连接数5000改为100000。
reg add HKLM\System\CurrentControlSet\Services\HTTP\Parameters /v MaxConnections /t REG_DWORD /d 1000000



  此外,针对数据库的大并发处理,参见以下资料:


  http://msdn.microsoft.com/zh-cn/library/aa0416cz.aspx


  http://blog.csdn.net/fhzh520/article/details/7757830


  http://blog.csdn.net/truong/article/details/8929438


  http://www.cnblogs.com/chuncn/archive/2009/04/21/1440233.html


  http://jingyan.baidu.com/article/948f5924235410d80ff5f91d.html








请收藏万众海浪网永久域名:①www.838668.comwww.939138.com  业务联系: 朗文 1836688338
顶部
 

 

本站永久域名①:www.838668.com (点击加入您的收藏夹)

当前时区 GMT+8, 现在时间是 2024-3-29 16:02

     Powered by Discuz! 5.5.0  © 2001-2007, Skin by Cool
Clear Cookies - Contactus - 万众海浪论坛 - Archiver - wap