当前页面: 开发资料首页 → J2EE 专题 → 关于javamail代收邮件的性能问题
关于javamail代收邮件的性能问题
摘要: 关于javamail代收邮件的性能问题
在一B/S架构的项目中，需要提供邮件的代收代发功能，准备用javamail实现；
主要是收的问题，系统中用户量不大还好，若用户几百上千的时候怎么办？如果为每个用户收邮件耗时1秒（outlook收取邮件一次绝不是1秒可以完成的），一千人，就是1000秒，而服务器端程序还要不停的循环去收取，服务器怎能承受如此的压力？
若不是循环，每个用户在页面上点击触发收取邮件的动作，几十个用户在线服务器就要崩溃了，如果写个池子就要很多用户等待！
请达人指点！
另，这样的需求有何好的解决方案呢？
这个性能确定不好处理，关注中
这有点象数据库连接,所以跟数据库连接同样的道理,同一时刻不会同时有那么多人操作数据库,或着是发送Email,而大部分时间用户是在浏览网页,或是写邮件!所以写个池子应该没有什么问题!
即使某一时刻有一百万用户在线,但是绝大部分还是在写邮件的,只有极少数的在发送邮件!
没这方面的经验，帮顶
多谢深蓝。
确实发邮件的量应该不会很大，我担心的是收邮件（不是收回本地后浏览邮件）的那个过程如何处理；
就像上班后大家第一件作的事情就是收邮件，如果上千人在早晨上班后的比较短的时间内都要从邮件服务器收取一遍邮件，因为收取邮件要认证、与服务器建立连接、过滤等操作比较耗时，这时服务器的压力可想而知；如果写池子限制连接数，如此大量的用户就会有排队等待发生，用户体验不佳；
当然还可以不让用户自己收取邮件，而只是浏览邮件、发邮件；这样做的前提是系统能够实时的把所有用户的邮件收取到服务器，当然是相对的实时；如果写个线程作一个循环一直收，所有用户收一遍的时间也是比较长的，实时性会大打折扣，用户体验也不好；
不知道是否还有其它解决方法？
你把程序做成多线程的就可以了。
多线程怎么解决问题，jsp servlet本来就是多线程的，用户量一上来java进程很容易就占用cpu100％，线程越多岂不死的更快？偶菜，请terry明示
希望各位发表下意见，自己先顶！
如果像你后来所说的用户量一上来，CUP就%100的话，用线程也一样没用。据我所知，我公司之前的一个系统也是javamail做的，全公司上下有几百人，但没出现过你说的服务器不堪重荷的情况，我泡论坛这么久印象中也没听说过你的情况。很可能你程序写的有问题，如果你不想查程序方面的原因的话，我建议把邮件部分布署到一台独立的服务器上。还有，如果光是建个邮件服务器，根本不用javamail，大把第三方软件可以用，自己一个代码都不用写的。
如果是domino的邮件系统，你可以看看domino的帮助应该有接口可以监听到新邮件的，有个OUTLOOKCONNECTER吧好像不知道这个有没有帮助，还有你的轮循应该有一些算法，代理因该本地有数据库，你可以在内存里维护一个队列只轮循较多邮件的人，或者按照最近有新邮件的维护队列，对最近有新邮件的人进行轮循，较多人的轮循会对服务器造成较大压力（取决于你的线程数多少），但是这样的方式是个非及时系统有一定的延时。至于压力我觉的是你程序的问题，你在大量的并发访问时应当有选择的访问数据库直接返回结果或者直接启动该用户的查看邮箱状态的线程然后再访问数据库，控制主与mail服务器通信的数量。还有POP3协议上，可以给邮件打标记，如果邮件服务器上的邮件只有通过代理看到，那你每次只取新的邮件头信息，不要把整个邮件都取下来，具体怎么的有些忘了，一年多前做过个类似的东西。
jsp或者servlet是多线程的，也就是说你的javamail会以多线程的方式运行，所以不用担心这个循环会影响
是这样的，我写了个收邮件的程序，收我的163邮箱的100多封邮件，收了10几秒，我的机器p42.4 1.5G内存，outlook也不快，而这种邮件的代收代发相当于把所有用户的outlook弄到一台服务器上去跑了，这个压力不用担心吗？得用什么配置的服务器呢？用户那里就x345或稍好点的pc server。
收回的邮件存在本地，列表时取头信息，浏览邮件时在取内容，这些是肯定的，但上班后的20分钟内，可能有一半的人要收邮件，压力还是不小。
关于cpu100％，俺只是做了100次 system.out.print（“”），或定义一个String对象，连续执行的时候，cpu瞬间就100％或接近了，如果有io就更不得了了，这是我的机器上测的，可能不准确。当然如果没有并发可能没有问题，但是收邮件这样的操作，怎么让人放心啊
支持一下
再顶一下！
↑返回目录
前一篇: spring+struts+hibernate开发中遇到的问题?
后一篇: 动态图片