明明俺是写程序的...但现在基本是公司全能了..有什么需求就要去满足什么需求.. 抱怨下.哈哈..是这样,现在 需要我提供一个页面比如 :  http://www.123.net/link.aspx?id=1001   这样别人访问进来, 页面就返回一个 Setup_1001.exe 给客户端. 根据提交进来的ID号, 返回文件名.代码如下:Response.ContentType = "application/x-zip-compressed";
Response.AddHeader("ContentDisposition", "attachment;filename=Setup_"+id+".exe");
string filename = Server.MapPath(@"Setup.exe");
Response.TransmitFile(filename);然后还要记录客户访问此页面时的来路 (Request.UrlReferrer) 然后把ID号和 来路URL记录到数据库.
数据库采用SQL 2005  使用一个简单的存储过程...   有记录就返回 无记录就写入.
功能都没有问题, 但网页编程经验不多, 想请教有经验的人, 以上方法,在高并发情况下(每天大概10W访问),能否工作正常,会不会出现客户端访问时,几秒也没有反应的情况.比如那个返回文件给客户端下载..我不知道.net 里是怎么实现的..TransmitFile 在WINDOWS里是把文件传输交给系统去处理,  而.net 里应该是一样的? 应该不是读到内存,把数据返回给客户端这种消耗大的动作吧? 和静态地址比起来,效率如何.?还有如果说在数据库操作那里,频繁的访问,能否造成性能下降等, 虽然我有想过分时段性操作数据库,比如每分钟只有前10秒才去访问数据库, 因为只记录来路,不统计次数等等,没必要每次都去访问数据.  但还是拿不准.
说这么多,就想问下,上面那个文件下载的代码,已经访问数据库的功能, 在面对大概每天10W访问量的时候,能否毫无压力..?    

解决方案 »

  1.   

    如果白天有10万人下载exe文件的话,无论如何你还是多找两台服务器吧。transitfile之类的的问题,你自己看一下msdn,再做一个测试就行了。不用仅在底层的简单问题上反复纠结,你亲自动手测试才能说明问题。如果说微软做的东西不好,自己又做不出能被测试证明更好的东西来替代它,就会瞎耽误工夫。
      

  2.   

    关于“能否工作正常,会不会出现客户端访问时,几秒也没有反应的情况.”,这个其实是瞬时的压力,跟“10w”没有直接的联系。假设只有100个人下载exe文件,也可能如此。因此你的 link.aspx 文件可以限制下载线程数,例如最多只能有30个,如果超过30,那么你可以返回一个403错误。
      

  3.   

    关于你的那个数据库操作,什么“分时段操作”是匪夷所思的。我好像是指在csdn这类地方某些帖子才会看到煞有介事地这样设计的。这个说法在这个多核多线程编程时代,明显是画蛇添足的。如果必须记录到数据库,那么就立刻记录数据库好了。只不过,既然结果跟ashx输出毫无关系,那么你对数据库的操作可以使用另外一个子线程去操作数据库,子线程就算因数据库事务操作阻塞模式而操作数据库,也不会阻塞处理网页的主线程操作。asp.net本身处理客户端消息是多线程的,再加上你对数据库保存数据的操作也是异步的,对你的ashx应该没有什么影响。
      

  4.   


    恩,谢谢你的回复...
    关于下载文件 transitfile 的问题. 我是有这样的顾虑, 因为公司的前辈告诉我 静态的地址,最节约资源,比如 http://www.123.net/1001.exe  这样别人是直接下载的连接.  我就在想 transitfile 是不是也类似于提供客户端直接访问静态地址,只不过保存的文件名不一样..还有因为业务要求,不能出现限制下载数量的事情...这个只能看服务器性能了吧..数据库操作那里,是我这个外行的推测, 因为 比如一分钟,一秒一个下载访问,有60个下载访问, 这60个下载都来自一个来路页面, 我就要访问60次数据库,看数据库里是否已经存在了这个来路页面的记录, 没有的话再写进去,  这样第一次写入后, 后面59次相当于没有实际操作的, 就浪费了59次去读取的时间.. 所以我觉得可能在时间上打乱一点, 只对前10秒进行判断,  这样大概一定程度上可以较少不必要的读取数据库的时间,达到节约性能的目的?...(虽然实际上IIS大概有记录来路的日志,  但领导不懂,非要搞也页面才舒坦.. 又抱怨了.抱歉..哈哈..)