timer控件是服务器端的,这样定时执行会给网站性能造成严重的影响。不建议用这个控件,而应该在客户端用settimeout函数的形式主动请求服务器。

解决方案 »

  1.   

    看你的性能瓶颈在哪timer对CPU资源几乎没有占用,如果你的性能瓶颈是CPU就不需要在意timer的问题
    但如果你的iis线程经常是满的,最好不要在服务器端做timer,它会一直占用线程,考虑服务器端直接返回,在客户端延时后再提交
      

  2.   

    timer里面的功能和客户端没有什么关系。是每分钟检查有没有ftp文件上传了,如果有就要做数据导入。
      

  3.   

    其实就是懒得再去写个windows服务专门干这个事情。
      

  4.   

    windows服务相比你在web写这个貌似也没多出来多少工作量啊
      

  5.   

    功能不一样,不能随便换到客户端去。另外这个类不会对网站性能造成任何影响,你居然说是严重影响,你用过没?使用System.Timers.Timer是不会产生性能问题的,不过如果你只是进行简单的定时操作,建议使用System.Threading.Timer。后者是轻量级的,只能绑定一个定时触发委托,而前者是通过事件的+=操作任意添加,要切换事件还必须先-=后+=,操作挺麻烦的,当然功能上也有差异,System.Timers.Timer可以指定触发事件在哪个线程上引发,引发到UI线程上都可以。
    这两种定时器都是用的系统计时,原理应该类似windows计划任务的触发,不占程序额外的资源开销,只有触发函数中执行的代码部分有点开销,因此对网站性能没什么影响。
      

  6.   

    我今天也用到这个Timer了,在全局文件里面写的
    定时2个小时
      

  7.   

    正统的方法还是windows service. IIS没有request就会结束掉进程(默认20分钟后),这个时候你的代码就没法执行了。
      

  8.   

    这个问题我也考虑了,不过,既然没人访问,那我的ftp目录里基本上也不会有东西,等有人访问的时候再去扫描应该问题也不大。
    不知道其他的IIS怎么样,2008的IIS应用程序池没有request会等待一段时间然后回收而不是结束,也就是会重启应用程序池,这样只要Timer的时间间隔稍微短一点,比如十分钟,就能被启动了,我原来设过一个小时的,结果真的像你说的那样,到了半夜以后完全不执行了。
      

  9.   

    不是,回收是重启应用程序池,而不是停止,当前的Timer当然是被回收了,不过我是在应用启动的时候初始化Timer的,所以等于没停么。
      

  10.   

    WEB服务器的反应应该是越快越好,怎么会用得到 Timer。
      

  11.   

    为什么?
    请看1楼
    你先看看7楼。
    原来如此,我的观点是和1楼一样的都没用过timer,看7楼说的应该是可以用的