既然大家有兴趣，就简单和大家说一下我的经验吧，但肯定不是完整的方案，因为每个case有很多需要注意的点和分支剧情，也要考虑到每个业务的具体场景，讲完整是不可能的。

@zjqzxc @TangMonk「6」这个问题可以用这个思路，比如内容是以时间排序的，那么就在每次查询的时候自动多带一个参数，也就是用户访问的时间点，并且在翻页的过程中记住这个时间点，在每页的查询语句里设置内容创建的时间要早于这个时间，这样用户不管翻多少页，由于有这个limit在，只要不删数据（即使删数据也可以用每页cache的方法，做到不影响其他页），总的结果集是固定的，所以每页的内容就是固定的。在用户重新进入第一页的时候，这个时间重新计算，这样就可以既不影响翻贴用户的阅读体验，又能够保证用户想看新内容的时候能够看的到。

当然如果你是做APP之类的瀑布流信息展现方式的话，就用Last_ID之类的方案好了，不过其实瀑布信息流也不应该叫做分页。

@raincious 「7」和「8」这两个问题和业务场景结合的很深，但总的来说是一个平衡问题，在以下两者之间取得一个平衡：
1.以每页为cache单位，这样内容一旦增加（例如新增了一条信息在第一页），那所有的cache都应该被清空重建。这个策略在数据刷新很频繁的时候效率最低，在数据变更不频繁的时候效率最高。
2.以每条内容为cache单位，这样一旦有新数据出现，不会有任何旧的cache被重建，只要每条数据不删不改，cache是可以一直用下去的，所以在数据刷新很频繁的时候效率较高，但这样cache会分布的很散，所以在数据刷新不频繁的时候效率会较低（分支剧情：如果你可以用redis的hmget的话当我没说）。
两者你都无法接受的话，就可以考虑结合他们的优势，去做group cache，比如每页20条数据，你每10条数据做一个cache，这样悲观情况下取3次就能拿到整页的内容，乐观情况下2次即可，具体group里放数据的数量要根据你的使用场景去订。分支剧情：但如果这样做的话，就要考虑如果数据删除的话，会造成cache不对齐，那这时候你就可以考虑在每个group里前后多加x条数据，这样即使数据有改动，只要不是太频繁，就能做到现有的cache的重复利用。不过这个分支剧情貌似走的人比较少，对逻辑的严密性也比较高，在此只是提一下就不展开了。

随便写写，一定有错，求别抬杠，求别黑，谢谢。

分页还真不是简单能写好的，简直是一个细思恐极的话题。

1.如何自动根据查询语句去生成一个 count sql，算出有多少条信息，需要分多少页？
2.有没有不用计算一共有多少条也能分页的办法？
3.如何保证「1」的语句在不同的情况下都能正常运行？
4.如果你用了 distinct 的话，如何保证效率？
5.如果查询语句里有 union 之类的操作的话，该怎么办？
6.如果信息刷新很频繁，如何解决「第x页的最后一条内容被顶到x+1页的第一条」这个问题？
7.如何在实现以上几点的情况下做cache？
8.如何在实现「7」的基础上尽量提高命中率？

@anewg 有点印象了，现在在哪儿呀？有兴趣来聊聊吗？

@anewg 谢谢，不过真的记不起你是哪位了，能提示一下吗

用过Symfony2吗，可以刷新一切你对PHP的世界观

@breeswish 现在有两种proxy，一种是toran，暂不支持缓存，但是性能较好，一种是一个日本人写的composer代理器，支持缓存，但是性能不太好。

我之前用的是第二种，现在用的是第一种，主要是因为json文件本身其实gzip压缩后尺寸并不大，再加上服务器本身速度也快，在可以接受的范围之间。

你现在发生这个情况我觉得可能是属于你的网络连接comproxy.cn的速度特别慢导致的，由于comproxy.cn是用cloudflare进行加速的，很有可能和你的网络有兼容性问题。

你可以试一下直接在hosts文件里指定真实的ip ：

92.243.16.3 comproxy.cn

试试看速度有没有变快。

可以看看这个：
http://www.imooc.com/learn/244

张培成快出来看你挖的坑

支持一下

@panxianhai 我只想让大部分用户用的爽一点罢了，至于是谁来做到这个事情，我并不关心。

如果没有人在做这件事情，那么我就会来做，如果有人做了而且比我做的好，我会建议大家去用那个更好的。

@zhengkai 你看错了吧，坐网确实是我做过的项目，我负责底层框架的搭建和几个模块的重构和开发工作，所以就算我说了“是我做的”，我说得也没错啊，这难道有什么问题么？

@zhengkai 应该是10ss.net，能上网的小票打印机，他们应该在使用workerman处理订单业务。

700k的js在uglify之后也就200k左右，再gzip一下也就80k左右，所以不是移动场景的话没必要分割。

当然如果你700k的js里如果有大部分都是其他页面能共用的，那可以分成一个公用库js文件，每个页面的独立逻辑做成一个js文件，两个就好。

看到thinkphp，dedecms，帝国我就跪了。

firefox的开发是基于xulrunner的，xulrunner是mozilla的一套跨平台的桌面程序开发框架，这套框架最大的特点就是允许用js语言写程序，用类似html的xul语言去定义界面及样式。但xulrunner最大的弱点是性能不佳，尽管mozilla对js多次进行优化，但多线程、文件操作，内存管理等都不是js的强项，所以firefox跑不快也理所当然，毕竟底子不好。firefox已经发展到今天这步了，不太可能全部重写，也就只能这样将就着继续混下去。

有兴趣的朋友可以试试看在firefox里打开chrome://browser/content/browser.xul，然后用firebug inspect一下各种元素，就可以知道其实firefox浏览器其实也只是一个网页而已。

@anewg 有其他热心人提供专门的服务器做这事儿了，所以我的镜像就停了。

@Lucups 一般这样是因为你的代码在host上，虚拟机通过映射把代码mount到本地，这样的模式在文件数量很多，或者需要生成各种临时文件的时候，就会特别慢。

解决的办法也有很多，最普遍就是用nfs去mount，性能会好很多，合适的mount参数也会提高文件io性能。或者host和虚拟机都使用本地文件，通过rsync自动同步等等。

virtualbox的cpu/内存性能都不差，只要你稍微放开一些设置，例如不要把cpu限制在一个，把内存限制在256mb之类的，virtualbox虚拟机在各方面几乎都可以跑到和host相同的性能。

其实都一样的，真要挑一挑，你就拆开iMAC看看你现有的内存是用什么芯片的，然后买同样芯片的就行，保证最大的兼容性。