站内信/消息功能的小型推送应用，用轮询还是长轮询？该如何处理

站内信/消息功能的小型推送应用，用轮询还是长轮询？
最近要做一个这个小应用，也查了不少资料。现在比较纠结该用哪个，主要是考虑服务器负载问题，望了解的大哥指点一二。
1）ajax做个3秒轮询的话，一是会有很多无效请求，另如果上一个请求服务器没响应下一个请求就到了的话，服务器肯定也鸭梨山大。
2）做长轮询的话，一个用户就一个连接，服务器要同时hold住这么多连接，鸭梨也很山大啊。
小弟对具体的架构不懂，反正这2个方法放在这很纠结，因为我也不会分析具体的服务器负载什么的。

另：服务器为盛大中等云主机and这个小应用对即时性要求不高。

------解决方案--------------------
站内信还要做推送比较少见，用户停在一个页面时间不会太长。如果真有这需求，那是真应该加个memcache了，每当对某个用户有更新操作，同时也更新memchache。
另外站内信是要考虑群发功能的,这时只需要插入一条记录，在用户登录时补全。还要把内容分成另外一个表。
------解决方案--------------------
关系编号 发送者 接受者 消息编号 状态
 1 ID1 ID2 3 读/未读


这就是一张关系表，另外还有消息表，用户表。

站内信一般就是一个未读信件的计数，select count就得到所有该用户未读信件的条数了，在可容忍限度内减少AJAX给数据库带来的查询压力，可以做个120秒的缓存存储未读条数，然后20秒一拉，就完事了。