HUST JudgeOnline 开发日记 3

关于online judge性能的思考
今年清华大学和上海大学的网络预赛中都出现了比较严重的服务器负载问题，所以我觉得性能问题必须得仔细推敲一下了。有人说可以使用多线程，可是在这里我想帮助是不大的，因为这里基本不存在多少等待的情况，而多线程只是为了将其他进程处在等待某种响应的时候，空闲出来的时间和资源利用起来的方式，对于ACM题目，这样作的意义不大，因为这里消耗的很多时间是在算法运行过程中的CPU时间，对于计算机来讲，这个时间是守恒的，不会因为来个多线程就多出一些CPU时间来，相反，在这里使用多线程还会带来附加的开销。我想我们要做的，就是实现一个judge的任务队列，并尽量保证足够的系统资源使得Web Server在任何时候都能够对参赛选手产生及时的信息反馈，我想，在网页上显示一个Pending...总比半天刷不出网页或者干脆是爆出一个错误页面好。
对于我们现有的服务器: P4 2.4 HT, 1G DDR, 我做了一个大概的极限负载估算
假设有200个队伍
总共有8道题目
每个队伍对每道题都提交5次
每次提交，服务器都花2s的时间来处理( 评判时间 + 数据库操作时间 + WebServer响应时间 )
这样总耗时为200*8*5*2 = 32000s = 4.4H 
这里还没有算上用户对其他页面请求的处理时间。甚至还没有考虑在比赛刚开始以及比赛即将结束时出现的代码提交峰值。
这说明：
这样的服务器的极限应该就是200个参赛队伍的在线比赛。
网络带宽不是瓶颈。（想象假设所有参赛队在某一秒钟同时提交代码，一份代码就算是有4k,也只有 200*4k = 800k，的数据量。 

我想，解决问题的关键就是：
合理地管理评测任务，保证服务器的响应速度。
页面防刷机制。
提高评测程序的效率。

可选方案：
将评测环节独立出来，由一组普通PC来完成，服务器只作一下任务调度。
具体想法是在评测机监听一个端口，设计一套与服务器的对话方案，比如状态查询（空闲，评测中），获取评测结果等。
实现动态配置，任何时候，即便是比赛中，只要使用少许时间将评测机配置好，然后在服务端的评测机列表中加入它的IP即可。

这个方案并不算特别难实现，只是服务器的任务调度稍有些繁琐，但是却可以大大提高服务器的带负载能力！估计是可以与评测机的台数成正比，这个时候的主要制约因素变成了服务器评测任务管理的开销，以及Web Server端的负载。

原址：http://blog.youkuaiyun.com/silentvoid/article/details/1469113