任何读取文件速度比 PHP 的 readfile(test.html) 更快的编程语言; @ 20.000,- 每秒点击次数?
什么服务器端编程语言毫无疑问是输出文件内容最快的? (我正在查看每秒大约 20k 个文件点击次数,所以是的,如果某些 X 语言可以比 PHP 快 1 毫秒输出文件,这确实很重要)。
在发布这个问题之前我已经阅读了以下链接(但突然提出了一个问题,哪种服务器端编程语言比 PHP 更快?)
因为 PHP 是我选择的语言,所以 com/wiki/Readfile_vs_include" rel="nofollow">http://raditha.com/wiki/Readfile_vs_include
当您说出答案时,还请告诉我用于读取文件的方法。所以不要只说FASTCGI/PHP,还要说读取文件的方法,比如本例中的readfile();
What Server Side Programming Language, which without a single doubt is THE FASTEST to output a file content? (I am looking at ~20k file hits / second, so YES it does matter if certain X Language can output a file 1ms faster then PHP).
Because PHP was my language of choice, I have read the following links before I posted this question (but suddenly it raised a question, which server side programming language that is faster than PHP?)
http://raditha.com/wiki/Readfile_vs_include
When you state your answer, please also tell me the method that is used to read file. So dont just say FASTCGI/PHP, but also the method used to read the file, such as in this case readfile();
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
问题是,所有这些 20k 次点击/秒都需要生成文件吗?这似乎不太可能。在第一次生成静态文件后,您只需配置 nginx 来缓存它,因此此后的所有请求都将命中缓存版本,并且根本不会调用您的服务器端语言。
这就是首先拥有像
nginx
这样的代理缓存的意义。所以你确定你真的在这里追寻正确的问题吗?您应该向我们提供的数字不是您期望每秒有多少命中,而是您期望每秒有多少缓存未命中。毕竟,如果您要提供 600 个每分钟更改一次的文件,那么每秒只会发生 10 次缓存未命中,对于实际的服务器端程序来说,这是一个更易于管理的数字(并使语言的选择不再成为问题)。
那么,请告诉我们更多信息:您的缓存命中/未命中率是多少? 10% 的缓存未命中率与 1% 的缓存未命中率有很大不同,依此类推。
The thing is, are all of those 20k hits/second going to be requiring generation of the file? That seems unlikely. After the first generation of a static file, you can just configure
nginx
to cache it, so all of the requests after that will hit the cached version and never invoke your server-side language at all.That's the point of having a proxy cache like
nginx
there in the first place.So are you sure you're really chasing the right problem here? The numbers you should be giving us are not how many hits you expect per second, but rather how many cache misses you expect per second. After all, if you're serving, say, 600 files that change once every minute, that's only going to be on the order of 10 cache misses per second, which is a much more manageable number for the actual server-side program to handle (and makes the choice of language less of an issue).
So, do tell us more: what's your cache hit/miss rate going to be like? A 10% cache miss rate is a lot different than a 1% cache miss rate, and so on.