minio性能（如何利用wrap测试oss性能）

本文目录

• 如何利用wrap测试oss性能
• ssdb、minio性能测试c
• miniio一直正常突然报错timeout
• ASP.NET性能提升秘诀之管道与进程优化

如何利用wrap测试oss性能

前言

我们利用mino与ceph rgw搭建好的oss经过多层网络转发，传输速度必定有所折损，这个时候我们使用wrap来测试oss对象存储的真实性能。

利用wrap测试oss性能

wrap是minio项目下的一个开源测试工具，wrap会上传一定随机数据到oss对象存储服务器上，统计过程消耗时间得出整个oss性能分析。

使用docker 执行测试

上述命令使用warpv0.5.5对地址为172.16.1.54:7480的oss服务器进行测试。

相关命令

结果

结语

以上就是使用wrap测试oss的其中一种办法，你学会了吗？ 希望读者朋友看完这篇文章后有所启发。

ssdb、minio性能测试c

项目上需要找一个硬盘型的NoSQL，用于将 Redis 中的冷数据落入硬盘。初步选型了几款 key-value 类型的NoSQL，分别有 levelDB、 rocksDB、 TiDB、 SSDB、swapDB、 Kvrocks、Tikv 。均为基于 levelDB 开发的几款NoSQL。其中因为 levelDB、rocksDB 无网络接口，不方便做分布式和高可用。， TiDB 过重，还有 swapDB 社区不够活跃且相关client API不完备。暂时选型 SSDB 。

项目需要存储的其实是一个略长的二进制字符串，初步认为，使用 对象存储 方案其实也可以替代NoSQL，所以压测对象添加当前非常火的云原生对象存储 MinIO

硬件名|配置 系统| Ubuntu(基于win10 wsl版的docker启动) 内存| 16GB(实际可用6.08G) CPU| Intel i5-8400

测试项目： 1. 写50M数据100次 2. 随机读取任意key 100次（对LRU机制不友好）

写

数据导入成功！
数据序列化成功！
a 数据大小:50.99295234680176 MB
第1次写入总用时: 797 ms
第2次写入总用时: 848 ms
第3次写入总用时: 3621 ms
第4次写入总用时: 813 ms
第5次写入总用时: 1862 ms
第6次写入总用时: 838 ms
第7次写入总用时: 2235 ms
第8次写入总用时: 836 ms
第9次写入总用时: 900 ms
第10次写入总用时: 1027 ms
第11次写入总用时: 1101 ms
第12次写入总用时: 880 ms
第13次写入总用时: 1956 ms
第14次写入总用时: 866 ms
第15次写入总用时: 2422 ms
第16次写入总用时: 852 ms
第17次写入总用时: 4511 ms
第18次写入总用时: 875 ms
第19次写入总用时: 2736 ms
第20次写入总用时: 814 ms
第21次写入总用时: 7172 ms
第22次写入总用时: 891 ms
第23次写入总用时: 7820 ms
第24次写入总用时: 836 ms
第25次写入总用时: 22103 ms
第26次写入总用时: 877 ms
第27次写入总用时: 2712 ms
第28次写入总用时: 841 ms
第29次写入总用时: 1928 ms
第30次写入总用时: 916 ms
第31次写入总用时: 839 ms
第32次写入总用时: 826 ms
第33次写入总用时: 7759 ms
第34次写入总用时: 843 ms
第35次写入总用时: 10670 ms
第36次写入总用时: 843 ms
第37次写入总用时: 9361 ms
第38次写入总用时: 821 ms
第39次写入总用时: 810 ms
第40次写入总用时: 794 ms
第41次写入总用时: 13281 ms
第42次写入总用时: 833 ms
第43次写入总用时: 811 ms
第44次写入总用时: 798 ms
第45次写入总用时: 18843 ms
第46次写入总用时: 911 ms
第47次写入总用时: 9428 ms
第48次写入总用时: 898 ms
第49次写入总用时: 17582 ms
第50次写入总用时: 903 ms
第51次写入总用时: 831 ms
第52次写入总用时: 800 ms
第53次写入总用时: 14602 ms
第54次写入总用时: 827 ms
第55次写入总用时: 5898 ms
第56次写入总用时: 856 ms
第57次写入总用时: 5693 ms
第58次写入总用时: 1050 ms
第59次写入总用时: 882 ms
第60次写入总用时: 1020 ms
第61次写入总用时: 15060 ms
第62次写入总用时: 902 ms
第63次写入总用时: 1062 ms
第64次写入总用时: 915 ms
第65次写入总用时: 7572 ms
第66次写入总用时: 823 ms
第67次写入总用时: 9649 ms
第68次写入总用时: 832 ms
第69次写入总用时: 10403 ms
第70次写入总用时: 907 ms
第71次写入总用时: 978 ms
第72次写入总用时: 789 ms
第73次写入总用时: 2111 ms
第74次写入总用时: 947 ms
第75次写入总用时: 4675 ms
第76次写入总用时: 944 ms
第77次写入总用时: 8592 ms
第78次写入总用时: 832 ms
第79次写入总用时: 2940 ms
第80次写入总用时: 842 ms
第81次写入总用时: 19835 ms
第82次写入总用时: 862 ms
第83次写入总用时: 7646 ms
第84次写入总用时: 873 ms
第85次写入总用时: 1002 ms
第86次写入总用时: 842 ms
第87次写入总用时: 9057 ms
第88次写入总用时: 801 ms
第89次写入总用时: 5117 ms
第90次写入总用时: 918 ms
第91次写入总用时: 798 ms
第92次写入总用时: 853 ms
第93次写入总用时: 7728 ms
第94次写入总用时: 810 ms
第95次写入总用时: 3969 ms
第96次写入总用时: 814 ms
第97次写入总用时: 2050 ms
第98次写入总用时: 819 ms
第99次写入总用时: 9566 ms
第100次写入总用时: 833 ms《/pre》

随机读

第1次读取 15总用时: 2251 ms
第2次读取 73总用时: 2045 ms
第3次读取 98总用时: 1548 ms
第4次读取 20总用时: 2683 ms
第5次读取 46总用时: 1156 ms
第6次读取 69总用时: 1160 ms
第7次读取 46总用时: 1520 ms
第8次读取 51总用时: 1381 ms
第9次读取 48总用时: 1000 ms
第10次读取 69总用时: 1400 ms
第11次读取 82总用时: 1236 ms
第12次读取 22总用时: 1140 ms
第13次读取 36总用时: 864 ms
第14次读取 66总用时: 843 ms
第15次读取 47总用时: 922 ms
第16次读取 17总用时: 885 ms
第17次读取 14总用时: 864 ms
第18次读取 64总用时: 888 ms
第19次读取 74总用时: 815 ms
第20次读取 33总用时: 866 ms
第21次读取 36总用时: 822 ms
第22次读取 78总用时: 975 ms
第23次读取 40总用时: 1186 ms
第24次读取 54总用时: 857 ms
第25次读取 92总用时: 963 ms
第26次读取 43总用时: 955 ms
第27次读取 38总用时: 853 ms
第28次读取 47总用时: 926 ms
第29次读取 62总用时: 877 ms
第30次读取 70总用时: 890 ms
第31次读取 88总用时: 895 ms
第32次读取 15总用时: 937 ms
第33次读取 3总用时: 993 ms
第34次读取 99总用时: 892 ms
第35次读取 76总用时: 818 ms
第36次读取 30总用时: 1020 ms
第37次读取 89总用时: 863 ms
第38次读取 99总用时: 819 ms
第39次读取 62总用时: 818 ms
第40次读取 1总用时: 871 ms
第41次读取 66总用时: 809 ms
第42次读取 68总用时: 847 ms
第43次读取 72总用时: 910 ms
第44次读取 50总用时: 1128 ms
第45次读取 47总用时: 898 ms
第46次读取 26总用时: 909 ms
第47次读取 35总用时: 872 ms
第48次读取 30总用时: 826 ms
第49次读取 79总用时: 904 ms
第50次读取 66总用时: 863 ms
第51次读取 2总用时: 885 ms
第52次读取 65总用时: 900 ms
第53次读取 67总用时: 1023 ms
第54次读取 16总用时: 934 ms
第55次读取 63总用时: 892 ms
第56次读取 9总用时: 894 ms
第57次读取 71总用时: 896 ms
第58次读取 20总用时: 947 ms
第59次读取 89总用时: 865 ms
第60次读取 57总用时: 872 ms
第61次读取 62总用时: 856 ms
第62次读取 14总用时: 881 ms
第63次读取 19总用时: 950 ms
第64次读取 14总用时: 876 ms
第65次读取 86总用时: 968 ms
第66次读取 12总用时: 911 ms
第67次读取 93总用时: 877 ms
第68次读取 59总用时: 886 ms
第69次读取 79总用时: 878 ms
第70次读取 49总用时: 869 ms
第71次读取 91总用时: 964 ms
第72次读取 38总用时: 838 ms
第73次读取 73总用时: 915 ms
第74次读取 8总用时: 875 ms
第75次读取 96总用时: 827 ms
第76次读取 98总用时: 826 ms
第77次读取 95总用时: 892 ms
第78次读取 36总用时: 843 ms
第79次读取 44总用时: 872 ms
第80次读取 89总用时: 863 ms
第81次读取 24总用时: 883 ms
第82次读取 89总用时: 804 ms
第83次读取 49总用时: 876 ms
第84次读取 81总用时: 873 ms
第85次读取 72总用时: 914 ms
第86次读取 68总用时: 861 ms
第87次读取 73总用时: 893 ms
第88次读取 4总用时: 880 ms
第89次读取 3总用时: 987 ms
第90次读取 76总用时: 896 ms
第91次读取 16总用时: 1010 ms
第92次读取 73总用时: 903 ms
第93次读取 83总用时: 933 ms
第94次读取 52总用时: 945 ms
第95次读取 48总用时: 901 ms
第96次读取 26总用时: 942 ms
第97次读取 37总用时: 883 ms
第98次读取 44总用时: 866 ms
第99次读取 89总用时: 921 ms
第100次读取 61总用时: 896 ms《/pre》

写

数据导入成功！
第1次写入总用时: 956 ms
第2次写入总用时: 912 ms
第3次写入总用时: 1241 ms
第4次写入总用时: 1564 ms
第5次写入总用时: 942 ms
第6次写入总用时: 3666 ms
第7次写入总用时: 1629 ms
第8次写入总用时: 1712 ms
第9次写入总用时: 977 ms
第10次写入总用时: 1515 ms
第11次写入总用时: 911 ms
第12次写入总用时: 1009 ms
第13次写入总用时: 1024 ms
第14次写入总用时: 1206 ms
第15次写入总用时: 984 ms
第16次写入总用时: 943 ms
第17次写入总用时: 954 ms
第18次写入总用时: 1033 ms
第19次写入总用时: 1008 ms
第20次写入总用时: 1121 ms
第21次写入总用时: 963 ms
第22次写入总用时: 949 ms
第23次写入总用时: 889 ms
第24次写入总用时: 1066 ms
第25次写入总用时: 1289 ms
第26次写入总用时: 1125 ms
第27次写入总用时: 1111 ms
第28次写入总用时: 953 ms
第29次写入总用时: 964 ms
第30次写入总用时: 1125 ms
第31次写入总用时: 998 ms
第32次写入总用时: 1993 ms
第33次写入总用时: 926 ms
第34次写入总用时: 920 ms
第35次写入总用时: 926 ms
第36次写入总用时: 1169 ms
第37次写入总用时: 1325 ms
第38次写入总用时: 1170 ms
第39次写入总用时: 1074 ms
第40次写入总用时: 1011 ms
第41次写入总用时: 931 ms
第42次写入总用时: 984 ms
第43次写入总用时: 1563 ms
第44次写入总用时: 905 ms
第45次写入总用时: 944 ms
第46次写入总用时: 1147 ms
第47次写入总用时: 1429 ms
第48次写入总用时: 934 ms
第49次写入总用时: 1133 ms
第50次写入总用时: 912 ms
第51次写入总用时: 953 ms
第52次写入总用时: 1127 ms
第53次写入总用时: 1065 ms
第54次写入总用时: 1323 ms
第55次写入总用时: 1003 ms
第56次写入总用时: 1489 ms
第57次写入总用时: 1377 ms
第58次写入总用时: 940 ms
第59次写入总用时: 1317 ms
第60次写入总用时: 912 ms
第61次写入总用时: 898 ms
第62次写入总用时: 934 ms
第63次写入总用时: 1005 ms
第64次写入总用时: 1729 ms
第65次写入总用时: 983 ms
第66次写入总用时: 1684 ms
第67次写入总用时: 908 ms
第68次写入总用时: 895 ms
第69次写入总用时: 1171 ms
第70次写入总用时: 1372 ms
第71次写入总用时: 1261 ms
第72次写入总用时: 1024 ms
第73次写入总用时: 1048 ms
第74次写入总用时: 904 ms
第75次写入总用时: 941 ms
第76次写入总用时: 928 ms
第77次写入总用时: 1806 ms
第78次写入总用时: 1052 ms
第79次写入总用时: 1030 ms
第80次写入总用时: 1092 ms
第81次写入总用时: 1117 ms
第82次写入总用时: 950 ms
第83次写入总用时: 933 ms
第84次写入总用时: 928 ms
第85次写入总用时: 935 ms
第86次写入总用时: 1908 ms
第87次写入总用时: 994 ms
第88次写入总用时: 1097 ms
第89次写入总用时: 930 ms
第90次写入总用时: 1052 ms
第91次写入总用时: 1119 ms
第92次写入总用时: 958 ms
第93次写入总用时: 987 ms
第94次写入总用时: 973 ms
第95次写入总用时: 2036 ms
第96次写入总用时: 891 ms
第97次写入总用时: 954 ms
第98次写入总用时: 951 ms
第99次写入总用时: 1044 ms
第100次写入总用时: 1366 ms《/pre》

随机读

第1次读取 46总用时: 40 ms
第2次读取 8总用时: 36 ms
第3次读取 28总用时: 26 ms
第4次读取 80总用时: 10 ms
第5次读取 77总用时: 13 ms
第6次读取 27总用时: 49 ms
第7次读取 86总用时: 20 ms
第8次读取 0总用时: 45 ms
第9次读取 54总用时: 34 ms
第10次读取 24总用时: 153 ms
第11次读取 78总用时: 29 ms
第12次读取 0总用时: 17 ms
第13次读取 91总用时: 56 ms
第14次读取 5总用时: 99 ms
第15次读取 23总用时: 138 ms
第16次读取 37总用时: 120 ms
第17次读取 40总用时: 156 ms
第18次读取 88总用时: 41 ms
第19次读取 76总用时: 32 ms
第20次读取 49总用时: 102 ms
第21次读取 20总用时: 179 ms
第22次读取 40总用时: 68 ms
第23次读取 6总用时: 215 ms
第24次读取 36总用时: 197 ms
第25次读取 37总用时: 30 ms
第26次读取 68总用时: 154 ms
第27次读取 14总用时: 314 ms
第28次读取 27总用时: 91 ms
第29次读取 51总用时: 255 ms
第30次读取 66总用时: 166 ms
第31次读取 86总用时: 140 ms
第32次读取 29总用时: 374 ms
第33次读取 96总用时: 235 ms
第34次读取 68总用时: 72 ms
第35次读取 74总用时: 264 ms
第36次读取 11总用时: 334 ms
第37次读取 55总用时: 316 ms
第38次读取 31总用时: 287 ms
第39次读取 93总用时: 233 ms
第40次读取 44总用时: 499 ms
第41次读取 26总用时: 312 ms
第42次读取 76总用时: 33 ms
第43次读取 11总用时: 31 ms
第44次读取 86总用时: 191 ms
第45次读取 96总用时: 217 ms
第46次读取 20总用时: 145 ms
第47次读取 1总用时: 772 ms
第48次读取 69总用时: 477 ms
第49次读取 9总用时: 320 ms
第50次读取 46总用时: 42 ms
第51次读取 34总用时: 823 ms
第52次读取 76总用时: 115 ms
第53次读取 62总用时: 635 ms
第54次读取 99总用时: 596 ms
第55次读取 64总用时: 657 ms
第56次读取 66总用时: 97 ms
第57次读取 18总用时: 461 ms
第58次读取 91总用时: 247 ms
第59次读取 46总用时: 147 ms
第60次读取 12总用时: 702 ms
第61次读取 79总用时: 545 ms
第62次读取 47总用时: 956 ms
第63次读取 17总用时: 853 ms
第64次读取 97总用时: 771 ms
第65次读取 74总用时: 368 ms
第66次读取 84总用时: 790 ms
第67次读取 72总用时: 866 ms
第68次读取 82总用时: 742 ms
第69次读取 93总用时: 313 ms
第70次读取 57总用时: 917 ms
第71次读取 61总用时: 1185 ms
第72次读取 66总用时: 162 ms
第73次读取 5总用时: 168 ms
第74次读取 68总用时: 275 ms
第75次读取 43总用时: 1108 ms
第76次读取 74总用时: 281 ms
第77次读取 65总用时: 955 ms
第78次读取 22总用时: 1169 ms
第79次读取 88总用时: 501 ms
第80次读取 80总用时: 1685 ms
第81次读取 92总用时: 1286 ms
第82次读取 89总用时: 1680 ms
第83次读取 30总用时: 1537 ms
第84次读取 41总用时: 1576 ms
第85次读取 2总用时: 2193 ms
第86次读取 52总用时: 1817 ms
第87次读取 8总用时: 323 ms
第88次读取 81总用时: 1409 ms
第89次读取 40总用时: 577 ms
第90次读取 88总用时: 598 ms
第91次读取 19总用时: 2324 ms
第92次读取 75总用时: 2275 ms
第93次读取 29总用时: 668 ms
第94次读取 77总用时: 2773 ms
第95次读取 62总用时: 484 ms
第96次读取 84总用时: 883 ms
第97次读取 32总用时: 2945 ms
第98次读取 44总用时: 884 ms
第99次读取 66总用时: 631 ms
第100次读取 38总用时: 2739 ms《/pre》

非常奇怪的是 MinIO 整体性能略优于 SSDB 但是理论上不太应该， SSDB 怎么说也是半内存半硬盘的NoSQL不应该比纯硬盘的 MinIO 性能要差，有可能是 SSDB 写到一定数据量后把本机内存写爆了，导致读写非常慢。但这变相验证了 SSDB 在极端情况下的不稳定。

miniio一直正常突然报错timeout

你好，你是想问miniio一直正常突然报错timeout的原因吗？miniio一直正常突然报错timeout的原因有：
1、网络不稳定导致文件上传中断引起miniio一直正常突然报错timeout；
2、防火墙阻止了传输导致miniio一直正常突然报错timeout；
3、等待处理请求时超时导致的miniio一直正常突然报错timeout。miniio是一款高性能高可用的文件系统服务。

ASP.NET性能提升秘诀之管道与进程优化

　　ASP NET 中包涵了很多秘密 当你发现它时 可以为你的程序带来更大的性能和扩展性提升 例如 了解了在Membership和Profile provider提供程序中所隐藏的秘密瓶颈后就可以方便地的解决验证问题并使得授权操作的速度加快

　　另外 ASP NET HTTP管道为了避免针对每次请求所要执行的必要代码而发生阻塞 不仅那样 ASP NET工作者进程能够推动其限制而获得更高的性能 页面碎片在浏览器端的输出缓存（不是在服务器端）可以显著节约回访者的下载时间 按需求的用户界面下载可以让你的站点给人快速流畅的感觉

　　最后内容传输网络和HTTP缓存头的恰当使用可以让你的网站惊人的快速 在这篇文章中 你将学习到这些技术 它能够使你的ASP NET应用程序获得更高的性能 更好的扩展性 并且可以在任何ASP NET的网站上实现 尤其是那些应用了ASP NET Membership 和Profile provider的站点

　　ASP NET管道优化

　　位于请求管道中的很多ASP NET默认的HttpModules用于拦截客户端所发出的每个请求 例如 SessionStateModule拦截每个请求 并解析对应的会话cookie 然后在HttpContext中加载适当的会话 实时证明 并不是所有的modules都是必要的

　　例如 如果你不使用Membership和Profile provider提供程序 那么你就可以不需要FormsAuthentication module 如果你需要为你的用户使用Windows验证 那么你就可以不需要WindowsAuthentication 位于管道中的这些modules仅仅在每次请求到来时执行一些不必要的代码

　　默认的modules都定义在了nfig文件中（位于$WINDOWS$\Microsoft NET\Framework\$VERSION$\CONFIG目录下）

　　＜Modules＞

　　＜add name= OutputCache type= System Web Caching OutputCacheModule /＞

　　＜add name= Session type= System Web SessionState SessionStateModule /＞

　　＜add name= WindowsAuthentication

　　type= System Web Security WindowsAuthenticationModule /＞

　　＜add name= FormsAuthentication

　　type= System Web Security FormsAuthenticationModule /＞

　　＜add name= PassportAuthentication

　　type= System Web Security PassportAuthenticationModule /＞

　　＜add name= UrlAuthorization type= System Web Security UrlAuthorizationModule /＞

　　＜add name= FileAuthorization type= System Web Security FileAuthorizationModule /＞

　　＜add name= ErrorHandlerModule type= System Web Mobile ErrorHandlerModule

　　System Web Mobile Version=

　　Culture=neutral PublicKeyToken=b f f f d a a /＞

　　＜/Modules＞

　　你可以通过在站点的nfig文件中添加《remove》节点到你的网站应用程序中来删除这些默认的modules 例如

　　＜Modules＞＜! Remove unnecessary Http Modules for faster pipeline ＞＜remove name= Session /＞＜remove name= WindowsAuthentication /＞＜remove name= PassportAuthentication /＞＜remove name= AnonymousIdentification /＞＜remove name= UrlAuthorization /＞＜remove name= FileAuthorization /＞＜/Modules＞

　　上面的配置对于使用了数据库并基于Forms验证的网站来说非常适合 它们并不需要任何会话的支持 因此 所有这些modules都可以安全的删除

　　ASP NET 进程配置优化

　　ASP NET进程模型配置定义了一些进程级别的属性 像ASP NET使用的线程数量 超时前阻止线程花费了多长时间 多少请求在继续等待IO工作完成等等 默认情况下 很多方面都具有太多的限制 当今 硬件已经变得十分便宜了 即使是采用双核多GB的RAM服务器也变得非常平常的选择了

　　因此 进程模型配置能够减少ASP NET进程消耗更多的系统资源并提供为每台服务器提供更好的扩展性

　　执行一次规则的ASP NET安装将会在nfig文件中创建如下配置的节点

　　＜system web＞＜processModel autoConfig= true /＞

　　你需要减少这种自动配置并针对不同的特性使用一些特定的值以便自定义ASP NET工作者进程的工作方式 例如

　　＜processModel

　　enable= true

　　timeout= Infinite

　　idleTimeout= Infinite

　　shutdownTimeout= : :

　　requestLimit= Infinite

　　requestQueueLimit=

　　restartQueueLimit=

　　memoryLimit=

　　webGarden= false

　　cpuMask= xffffffff

　　userName= machine

　　password= AutoGenerate

　　logLevel= Errors

　　clientConnectedCheck= : :

　　AuthenticationLevel= Connect

　　ImpersonationLevel= Impersonate

　　responseDeadlockInterval= : :

　　responseRestartDeadlockInterval= : :

　　autoConfig= false

　　maxWorkerThreads=

　　maxIoThreads=

　　minWorkerThreads=

　　minIoThreads=

　　serverErrorMessageFile=

　　pingFrequency= Infinite

　　pingTimeout= Infinite

　　asyncOption=

　　maxAppDomains=

　　/＞

　　除了下面几个不为默认值以外 其余均为系统默认值

　　maxWorkerThreads

　　每次处理默认为 在一台双核的计算机上 ASP NET的处理就需要 了 这意味着ASP NET在一台并行的双核服务器上可以每次处理 个请求 我将数量增加到 以便为ASP NET的每次处理提供更多的线程 如果你有一个应用程序 它的CPU处理能力并不是很强但是它却能够每秒更容易地处理多个请求 那么你就可以增加这个值

　　尤其是你的Web应用程序使用了大量的Web服务调用或者下载/上传了很多不会对CPU产生压力的数据时 当ASP NET用完这些工作者线程时 它会停止出来发来的多个请求 此时请求会放置到一个队列中并持续等待直到出现一个空闲的工作者线程 通常到你的站点开始接受超过预期的点击时会发生这样的情况 那样的话 如果你需要节省CPU的使用 可以增加每次处理的工作者线程数来达到目的

　　maxIOThreads

　　每次处理默认为 在一台双核的计算机上 ASP NET进行的I/O操作就需要 个线程了 这意味着ASP NET在一台并行的双核服务器上可以每次处理 个I/O请求 I/O请求能够进行的文件读/写 数据库操作 web服务调用 从Web 应用程序中产生的HTTP请求等等 因此 如果你的服务器有足够的系统资源来处理更多的I/O请求 你可以将该值设置为 特别是当你的Web应用程序在并行模式下进行下载/上传数据 调用很多外部Web服务时 非常有用

　　minWorkerThreads

　　当空闲的ASP NET工作者线程数量低于这个数字时 ASP NET就会开始将这些发来的请求推入队列中 因此 你可以为改值设定一个较低的值以便可以增加当前请求的数量 此外 建议不要将该值设置得过低 因为Web应用程序的代码可能需要做一些后台处理和并行处理 此时会需要更多的空闲工作者线程支持

　　minIOThreads

　　除了它是针对I/O线程以外 其它与minWorkerThreads的方式相同 然而你可以将该值设置得比minWorkerThreads还低 因为就I/O线程而言 这里不会发生并行处理的问题

　　memoryLimit

　　指定内存大小所允许的最大值 作为整个系统内存的百分比 以便ASP NET在启动一个新的进程并重新分派存在的请求之前这些工作者进程能够进行消费 如果在你的服务器上仅仅只运行了你的网站应用程序 而且没有其它的进程需要RAM 你可以设置一个更高的值 比如

　　然而 如果你同时有一个会发生内存泄漏的应用程序 那么最好是把该值设置为一个较低的值以便在出现大问题之前泄漏的内存能得到及时的回收从而保持你的站点稳定 尤其是当你使用组件并发生内存泄漏时 然而 这只是针对该问题的一个临时解决方案 当然需要你去解决泄漏问题

　　除了processModel以外 另外还有一个非常重要的节点 你能够指定发出请求作为单独IP的最大数量

　　＜＞＜connectionManagement＞＜add address= * maxconnection= /＞＜/connectionManagement＞＜/＞