性能与可伸缩性常常决定企业应用的成败。
遇到性能问题的J2EE应用的比例高得令人吃惊：往往发现问题的时候已经太晚了，无法用经济的方式得到解决，导致全面失败的风险。
并不是说J2EE注定就是缓慢的，而是因为很多导致系统缓慢的架构模式被不正常地广泛应用，而且太多的J2EE架构在设计时就有性能盲区。尽管有很多证据显示，性能方面的风险应该在项目周期中尽早解决，但是很多人仍然相信：性能问题可以在所有的功能都完善之后加以解决。他们常用的办法有：
代码优化，或者
更多、更快的硬件——这常常被视为万能灵药
这两条路都是歧路。代码优化能起的作用只不过相当于在泰坦尼克号上搬动一张躺椅而已。通常决定性能的是体系结构而非具体实现，优化代码很少能够从根本上改善性能。（然而，代码优化却是减轻后期维护压力和减少潜在bug的良好手段。）就算加上更多的硬件能解决吞吐量问题——常常还不能解决——这也会浪费很多金钱，因为应用程序占用的硬件资源比本该使用的更多。
对性能问题的视而不见常常来自这样一种信仰：“纯粹”的体系结构比高性能的程序更加重要。这是胡说：买单的人关心程序是否能满足他们的期望，远甚于关心程序是否遵循一张——本身就画满问号的——蓝图。
无法达到性能和吞吐量要求的程序是失败的。
以上是《Development Whithout EJB》一书中关于性能在企业应用中的重要地位的叙述。在论坛上、技术区内，我们见到了太多只强调代码复用而对程序性能不屑一顾的人及文章。须知这是一种典型本末倒置的想法。最终的用户谁会因体谅制作者的辛苦而不在乎自己备受煎熬的等待？？
在企业应用的开发过程中，一定要牢记一个原则：因地制宜，实事求是。决不能为了追捧某些技术而削足适履。
遇到性能问题的J2EE应用的比例高得令人吃惊：往往发现问题的时候已经太晚了，无法用经济的方式得到解决，导致全面失败的风险。
并不是说J2EE注定就是缓慢的，而是因为很多导致系统缓慢的架构模式被不正常地广泛应用，而且太多的J2EE架构在设计时就有性能盲区。尽管有很多证据显示，性能方面的风险应该在项目周期中尽早解决，但是很多人仍然相信：性能问题可以在所有的功能都完善之后加以解决。他们常用的办法有：
代码优化，或者
更多、更快的硬件——这常常被视为万能灵药
这两条路都是歧路。代码优化能起的作用只不过相当于在泰坦尼克号上搬动一张躺椅而已。通常决定性能的是体系结构而非具体实现，优化代码很少能够从根本上改善性能。（然而，代码优化却是减轻后期维护压力和减少潜在bug的良好手段。）就算加上更多的硬件能解决吞吐量问题——常常还不能解决——这也会浪费很多金钱，因为应用程序占用的硬件资源比本该使用的更多。
对性能问题的视而不见常常来自这样一种信仰：“纯粹”的体系结构比高性能的程序更加重要。这是胡说：买单的人关心程序是否能满足他们的期望，远甚于关心程序是否遵循一张——本身就画满问号的——蓝图。
无法达到性能和吞吐量要求的程序是失败的。
以上是《Development Whithout EJB》一书中关于性能在企业应用中的重要地位的叙述。在论坛上、技术区内，我们见到了太多只强调代码复用而对程序性能不屑一顾的人及文章。须知这是一种典型本末倒置的想法。最终的用户谁会因体谅制作者的辛苦而不在乎自己备受煎熬的等待？？
在企业应用的开发过程中，一定要牢记一个原则：因地制宜，实事求是。决不能为了追捧某些技术而削足适履。
