维生素C.net

10分8错~

楼主说的还只是GC的一小部分.

可否邀请您加入博客园新手Team团队?

这样还麻烦. 你可以看一下tcp/ip里是怎么处理ip的. mysql里也有相关函数操作ip地址的.楼主也可以借鉴一下.

---
这种东西应该算是常识了吧。。。数值型的IP地址是从IE6就开始被支持的。。当年，直接把一串数字给别人，那是多么值得炫耀的事情？

这不是撤吗. 现在只所以在主流浏览器里不让使用其他进制的ip格式,是浏览器做了限制.

@蛙蛙池塘
that doesn't work

楼主可以看这里:
http://www.cnblogs.com/fanweixiao/archive/2008/07/13/1241951.html

原来我的windbg有问题.....

@翻译也要给出原文地址吧？！
以后我写一篇你就帮我把原文贴上来~~ 谢谢啊

@xiongli
我从鞠强的blog上看到过这个命令 但是在网上很少看到的使用 原来是内部工具

@翻译也要给出原文地址吧？！
中午你看不懂吗？

@小庄
性能,可用性,可扩展行 孰轻孰重已项目而定似乎更好：）

@巫云
这个看下http://www.cnblogs.com/worldreason/archive/2008/07/05/1236329.html

@Aldebaran's Home
其实是一个准则：你想做high performance的程序,那么就要主要的一些地方

@阿齐
什么意思?

@非空
你可以写个简单的程序然后去看IL,比如很简单的：
int i=0;
doSomething();
i++;
doSomething();
i++;

分别放在try()的外面和里面看一下就知道了

@Angel Lucifer
另外就是频繁的抛出异常是性能杀手，因为一旦抛出异常，在辗转展开堆栈，查找异常位置的时候，非常耗费时间。
----
耗费时间不是问题.耗费资源更重要.

@张旋
倒...

@Jeffrey Zhao
1.我没说高居不下,我说的是GC会占用较高的CPU.
2.暂停处理不会造成问题,但是这本身是语言的一个问题.至少现在看来微软是无法避免这个问题,当然这与操作系统有关.
3.我从没说过.net性能低.也没说过它比python或ruby的框架慢.我说的是asp.net框架.

@Jeffrey Zhao
不 .net的GC效率没那么高.
cpu也没有hang的说法.
动态语言的垃圾回收器不能与.net同日而语.
.net的GC会占用较高的cpu,并且中断通讯的继续进行.这是目前不可改变的事实

...感觉越来越跑题了...

@A.Z!
这里讨论的是思想,不是说谁不行.

@Q.Lee.lulu
1.这个操作如果要重视用户体验的话,就要在脚本上下功夫,不同的脚本性能差别可能天壤之别.
2.思路就在,把服务器段计算放在客户端完成.潜在危险是数据安全性.得到的好处是计算转移,或者说是性能损耗转移.

@Jeffrey Zhao
"比如windows验证没有用，它也不会降低性能阿" 对,这个不会.但是像默认添加的那些http module（.net framework的配置里的）,却是或多或少的存在影响的,并且这些东西都有积少成多的特点,积少成多的结果就是对性能的影响.

其次"对于动态请求完全不会成为性能瓶颈，瓶颈在数据访问上"这个说法我也赞同,但我认为不是这么肯定.比如GC,比如进程的lock,即使不读数据库,这两个东西也完全可以导致high cpu或者server too busy.反观asp.net本身的使用上并没有大量的使用BackgroundWorker类.

iis的能力不容怀疑,的确不错,但是还不够好.iis是对操作系统依赖性相当大的.

我这篇文章的目的没有批评微软技术的不好,而只是说我认为我们在做有web2.0思想（大多web2.0网站主线很明确,服务种类也相对单一）的large scale（要足够的large）website的时候,找到最核心的业务选用最恰当的技术来实现,才是最好的方案.不应该是从技术角度出发来分析问题,语言和框架等只是一个工具.懂细节,懂底层能让架构更简单,更实用（当然各种成本也要尽可能的低）.

@Ariel Y.
ariel哥,我还是坚持在.net阵营的.只不过最近在跟朋友搭一个website的时候交流中的一些感想:)

@Jeffrey Zhao
赵哥,你说的这个350个动态请求参照的应该是看的requests/sec这个值.这个值通常在700下都没有问题（2008没有在生产环境中体会过）.但是评估asp.net程序性能还有一个计数器是request executing,当然这个值究竟为多少合适各种说法都有,究竟是否依据cpu数量（准确说是taskmgr里看到的cpu的个数）我觉得还是要看.net在处理什么而定.

我说的成本确实是指windows的成本

“毕竟这个完整的asp.net2.0框架不是为large scale类型的网站制定的” 这不单是webform,是整个的asp.net框架. 这里不是说asp.net性能不好,而是说它不够好,原本可以做的更出色,更直白,只不过要顾及这顾及那,所以我才有如此的说法.举个例子,域用户验证机制对large scale的website在通常情况下需要吗？

@在线代理
这个不见得. asp也算是博大精深了,只不过暴露出来的东西让大家更多的看到的是他简单易用的一面--这也是微软做asp的目的.

@StillWartersRunDeep
基于python的框架我就用过web.py,对django还真是不熟,不过看起来web.py比dj更lightweight一点吧

@剑了
哥们你ID太酷了！

@egmkang
sorry,应该是qshttpd
地址是：http://www.linux-geek.org/qshttpd/

@Jeffrey Zhao
关于这种服务器架构很多大型的网站也在用.两层前端.而且都比较廉价.

@Jeffrey Zhao
关于这个350请求的测试环境还得看完全文,我没有列举出服务器当时的性能,没有像windows下perfmon这样直观和优越的工具,但看到的这个350并不是requests/sec计数器,在这里其实应该是一个再与request executing结合后做的一个值,这一点毫无疑问是比windows下的要高.
其次,windows能做到的时候,成本也大幅度上来了.

只要写的正确配置的正确，任何技术任何平台的性能都差不多--这个我不赞同：衡量的标准应该是在差不多的时间内完成的.同样一个基于.net framework 2.0的website,一个用原生的asp.net框架,一个用自己根据业务特点而写的web框架（毕竟这个完整的asp.net2.0框架不是为large scale类型的网站制定的）,肯定性能截然不同,同样,同一个应用程序基于iis6和iis7而编写,性能也有可能会差很多（比如从单纯考虑GC对基于asp.net框架对website的影响上）

此外我觉得数据库的说法也有些不妥,我觉得数据存储似乎应该更合适.

whatever,我认为究竟如何搭建一个large scale web application,还是要根据业务特点选用合适的服务器,选用合适的技术.

我觉得可以从另一个角度看待这个问题：
win32和iis的特点或缺点是否对我们解决这个问题产生了影响？

第一个问题：
大量的各种尺寸的图片放在硬盘上，如果目录建立的不合理或者说目录下分配的文件达到一定数量，IO是一个bottleneck了。这时候楼主不妨尝试一下放在数据库中的效果。（大多数情况下会发现比直接放在硬盘上有好一些了）

第二个问题：
IIS对于static file的处理能力如何？IIS作为一个web服务器，但是并不是完全实现http1.1的要求的，有一些东西是iis所不能直接支持的。

如果对于一定规模的图片服务器，文件系统是一个非常重要的部分。其次，可以尝试lighttpd，比较同等压力下的系统负载。

你那是出问题了才会oom，遇到这个问题的处理思路去看程序为什么会吃掉这么多内存！
web服务器为什么CPU越多越好？这个问题也跟你说的这个无关，去看Request Executing counter的原理。

从机制上来讲,原始的asp.net模型和现在MVC框架是完全不同的. 建议楼主先看MVC的实现原理.

mp.SaySex();//执行结果Man
//可以看到ManPerson很好的继承了Person
怎么是Man呢? 应该是NONE

@Phinecos(洞庭散人)
那样没什么意思吧.园子应该弄点有特色的

这是习惯吗?不同的公司有不同的规范.我觉得这没必要习惯.
像这样的:
public string name;
不叫习惯!

@随风流月
@没剑
我跟dudu提一下这个建议

@Vincent Yang
问题不在于"吹毛求疵",而在于你是否真的熟悉你的开发平台,是否熟悉你的项目.是很多人滥用乱用,时间久了大家都被其感染了.摆正心态,认真的去看看实现,不能算"吹毛求疵"吧?
一点想法.

@Vincent Yang
你用不同的方法,看代码的人也知道这两个用的地方处理的东西有不同的.

@Mainz
目的是要做有用的事.不要浪费时间在其他的地方.
parse/convert/tryparse不在于谁的性能好,而在于你怎么组织你的代码和逻辑,这是.net在发展在演变的一个过程

@Shawn Ji
TryParse已经帮你做了

顶~

@pwrjng
用profile

@李战
你看一下GC的工作方式就明白了.GC对待异常的处理方式比较复杂

@呵呵——next
我是用Server.Execute来替代了Server.Transfer() 没有更进一步的用IHttpHandler里的ProcessRequst()来处理问题,因为关联的地方太多了,我一时不能一下子全改过来

@Justin
已经给您邮件了

@overred
如果没有handler或其不正常的时候,就直接throw了,否则exception又response.end产生
谢谢指正

@Zhuang miao
哈哈.这个问题你肯定最清楚了