@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看看你现有的内存是用什么芯片的，然后买同样芯片的就行，保证最大的兼容性。

我下一步会考虑把服务器迁到香港/日本之类的地方，同时也会考虑用类似varnish之类的东西去做纯代理，这样可以根本上解决速度慢或者不稳定的问题。

我试了一下现在provider-active现在的路径是“http://218.244.132.204/proxy/packagist/p/provider-active$4b824c3ca96d97ab6a226952475a09338358f9febb1a8df188f8743b0a820033.json”，这个文件也是可以访问的。

你之前碰到的问题我估计是官网的这个文件出了点问题，导致composer-proxy无法正确的去获取这个文件，这也可能是其他proxy为什么不能工作的原因。这个事情应该是小概率事件，只需要过一段事件重试即可。