|
精华帖 (1) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-04-01
一直在做桌面系统以及Ｊ２ＥＥ方面的应用，很少涉及到ＰＨＰ／ＰＹＴＨＯＮ／Ｐｅｒｌ等脚本语言，所以其实的性能比较我不是太在行，Ｒｏｂｂｉｎ比我更有经验。
不过我们最近在做很多服务器的编程（不是Ｗｅｂ方面的），最后发现要达到大量的用户并发和充分利用网络的带宽，多线程必须被抛弃。进程的线程数限制和系统用于线程切换的时间已经大大浪费了网络的处理能力和系统的资源利用 另外Ｒｕｂｙ／Ｒａｉｌｓ开发、维护、测试方面的优势让我感觉Ｊ２ＥＥ实在臃肿繁复。Ｒｕｂｙ编程是一种非常愉快的经历。我想以后除了特殊的情况之外，对很多项目会优先选择Ｒａｉｌｓ。 |
| 返回顶楼 | |
|
发表时间：2006-04-01
引用 其实线程也有很大的问题，每个进程的线程数目都会受到限制，即使不限制也会因为线程的频繁切换而造成系统极度颠簸。所以需要支持非常大数量的服务器采用进程加少量线程(或单个线程）的事件模式是比较好的选择（C10K problem），lighttpd，lightspeed是比较好的例子。对于PHP/rails这些程序来讲，其实Web服务器就是他们的应用服务器。
对于线程频繁切换的问题，高性能的Java应用服务器起码应该采用异步IO了。例如Tomcat5.5就可以通过JNI使用操作系统的NIO机制，线程调度能力的提升巨大。而传说中的jetty6在NIO方面也是很强。因此面对巨大的并发请求，AppServer未必需要那么多线程就可以调度的过来，而且也未必引起大的颠簸。 引用 而对于Web程序来讲，Rails的页面缓存、部分缓存基本上和J2EE应用程序所能采用的方式一样了，而且Rails本身内建了这些机制，使用起来非常方便。
页面缓存如何实现？缓存在哪里呢？硬盘文件上面吗？ |
| 返回顶楼 | |
|
发表时间：2006-04-01
线程切换不单单是网络方面的问题，而是整个ＶＭ中线程的数目问题
文件空间，直接由Ｗｅｂ服务器处理这些内容 但是稍稍要经过Ｒａｉｌｓ的处理 |
| 返回顶楼 | |
|
发表时间：2006-04-02
rails的ｃａｃｈｅ分为两种，一种是ｐａｇｅ ｃａｃｈｅ，适合于公共的内容，另外一种是ａｃｔｉｏｎ ｃａｃｈｅ，是基于用户的
ｐａｇｅ ｃａｃｈｅ是直接生成为文件，严格基于ＵＲＬ，譬如ｒａｉｌｓ可以生成ｓｈｏｗ／５这样的文件，不需要ｒａｉｌｓ的任何介入，直接由ｗｅｂ服务器处理 而ａｃｔｉｏｎ ｃａｃｈｅ需要经过ｒａｉｌｓ的ｃｏｎｔｒｏｌｌｅｒ，只不过做一个ｆｉｌｔｅｒ即可 非常简单，只需要加一句 ｅｘｐｉｒｅ＿ｐａｇｅ ｅｘｐｉｒｅ＿ａｃｔｉｏｎ即可 ｒａｉｌｓ也同时支持可以过期的ｃａｃｈｅ（需要编程，用手动ｅｘｐｉｒｅ或者ｓｗｅｅｐ）和片断ｃａｃｈｅ（需要ｖｉｅｗ层的编程） |
| 返回顶楼 | |
|
发表时间：2006-04-02
potian 写道 一直在做Ｊ２ＥＥ方面的应用，所以其实这两方面的性能比较我不是太在行，Ｒｏｂｂｉｎ比我更有经验。
只不过我们最近在做很多服务器的编程（不是Ｗｅｂ方面的），最后发现要达到大量的用户并发和充分利用网络的带宽，多线程必须被抛弃。进程的线程数限制和系统用于线程切换的时间已经大大浪费了网络的处理能力和系统的资源利用 另外Ｒｕｂｙ／Ｒａｉｌｓ开发、维护、测试方面的优势让我感觉Ｊ２ＥＥ实在臃肿繁复。Ｒｕｂｙ编程是一种非常愉快的经历。我想以后除了特殊的情况之外，对很多项目会优先选择Ｒａｉｌｓ。 针对特殊的网络应用，可能都要自己编写高性能的服务器，这个方面我是外行，确实不知道进程模型还是线程模型更有优势。不过传说IIS性能比Apache好的原因就是因为线程模型的缘故(未经证实的流言)。不过可能Java的NIO还是比不过C的进程也有可能，这个就是我不懂的领域了。 另外我怎么记得Linux上面每进程的线程允许数量是很大的呢？我刚刚查了一下SuSE9.1专业版 输入命令：sysctl -a |grep thread，得到 kernel.threads-max = 32760 已经很大了，而且这还是专业版，企业版肯定允许更多线程，反正我改这个参数到10万，也没有报错。我记忆中好像什么地方看过Redhat企业版号称他每进程可以支撑10万以上的线程数量，我等有空的时候可以安装一下查一查。 而Linux上面进程好像只能够支持65536个进程吧？每个进程打开一个文件描述符，而fs.file-max = 65536，从这个数字来看，我看不出来线程数量有什么比进程数量更多的限制。 potian推荐RoR，看来我也得安排进学习计划了。 |
| 返回顶楼 | |
|
发表时间：2006-04-02
这个和线程栈有关系的，假设你让每一个线程栈为２Ｍ，那么１０００个线程专用的栈空间就是２Ｇ，而一个进程的虚拟空间在３２位的情况下是４Ｇ，部分还要供操作系统使用，象Ｗｉｎｄｏｗｓ规定用户只能用２Ｇ的虚拟内存空间，并不是操作系统本身对线程的限制问题
而进程数并不需要那么多，并不是为每个请求都需要一个进程的 |
| 返回顶楼 | |
|
发表时间：2006-04-02
一方面Grails借助Java平台积累的优势奋起直追,另一方面Rails也在尽快弥补Ruby在速度和类库上的弱点. 现在两边都是社团驱动,以后会不会有第三方的商业力量介入亦未可知(想想当年IBM决然抛弃smalltalk转而全力投入java一举定乾坤),鹿死谁手还真难说呢.
乱世出英雄,搬凳子,看好戏~ |
| 返回顶楼 | |
|
发表时间：2006-04-02
关键看后面推动的商业力量。当年python比java的优势比现在ruby vs java要大很多，但是最终还仍然是边缘语言。
在企业应用层面，ajax一上，基本上ror相比java只有orm方面的方便性了，但是也没有太大的差异。业务逻辑这一块，开发效率并没有那么大的区别。 而且，我对那种不需要接口的动态语言始终有那么一点点不踏实。动态语言使得程序的静态结构越来越不重要，但动态结构却需要很强的洞察力才行，应该说，如果没有TDD/重构，这些动态语言在关键应用中根本硬不起来。但对于那些没有接口作为中间契约层的动态语言而言，其实更需要的是充分的集成测试，这个太难了。太依赖于常识也不好。 当然，我对ruby不了解，就当我梦游了。 |
| 返回顶楼 | |
|
发表时间：2006-04-02
Robbin 写道 对于线程频繁切换的问题，高性能的Java应用服务器起码应该采用异步IO了。例如Tomcat5.5就可以通过JNI使用操作系统的NIO机制，线程调度能力的提升巨大。而传说中的jetty6在NIO方面也是很强。因此面对巨大的并发请求，AppServer未必需要那么多线程就可以调度的过来，而且也未必引起大的颠簸。 网络层方面只需要非常少量的线程数，一般需要多线程的地方是应用层的事件分发，这个就看应用层的需要了。 Tomcat 5.5采用的APR效率还是不错的，它只在网络层方面开了两个线程；Jetty6在NIO方面的实现就比较弱了，效率上还不如它的BIO实现。 |
| 返回顶楼 | |
|
发表时间：2006-04-02
大佬Richard Monson-Haefel关于动态语言的一篇blog:
Groovy: The Sleeping Giant http://rmh.blogs.com/weblog/2006/02/groovy_the_slee.html 其中对java开发者是否会转向ruby有很有意思的论述。 |
| 返回顶楼 | |
