做一个项目.主要是信息的录入.修改,查询.数据量在十万左右.
采用tomcat+SQL Server2000
我没有采用框架.
而是jsp+javabean+数据库连接池.(逻辑基本都在bean里)
能否满足100人同时访问使用?
服务器是双核至强.3G内存.
我在tomcat的monitor里把jvm调到256m ----1024M.
大家估计一下怎么样.基本都是动态页面.所以没有集成apache或iis.
有什么建议.
我把那个apr也准备集成在tomcat里.这样子怎么样呢.
因为项目基本做完了.不想再采用框架.主要时间挺紧张.spring或structs框架我也不熟,正学.
你这个问题其实分两种情况：
1. 100同时使用?
2. 总共100人使用，使用频度不高，如果是这个没有问题。
下面讨论第一种情况：
关键不在于你的CPU有多强，这里要了解一下Java运行原理。
Java有一个垃圾回收机制，总是在内存剩余大概5%才启动，因为它中断权限最高，它运行，其他全部停止，因此，我们不希望垃圾回收机制频繁启动，那么就要控制内存不要触碰剩余5%底线。
而在普通JavaBeans系统中，每一次客户端请求访问时，系统总是new一个javabeans或Java Class，如果并发访问量很大，比如并发10人或100人，再加上你的系统复杂，有很多JavaBeans，假设有30个，那么这下子100个并发请求来，就有3000个Java对象创建，然后下一批有来一次100个请求，这象潮水一样。
每次请求产生的3000个对象会继续占用内存，不会被垃圾回收机制回收，因为垃圾回收机制只有等到内存剩余5%才启动，这样，你的内存无论多大，取决于访问量，总会被耗光，最后垃圾回收出来收拾残局，你的业务系统被暂停甚至缓慢。
所以，这里需要有资源控制，将内存能够控制住，不要被无限消耗，最后导致垃圾回收启动，造成系统好像死机。
控制资源就是使用Pool或Cache来控制，Spring/JdonFramework下可自行加入； EJB已经默认加入了。
这也是我一直反对使用Jsp+JavaBeans来写复杂或大访问量的系统，至于如何控制服务器资源，只有数据库连接池是不够的，因为Bean才是真正的资源消耗重点。
继续补充：
经过前面基本原理以后，楼主问题可以知道一些答案，我再详细回答如下：
能够满足同时100人访问，关键在于每个请求耗费的资源是否多，这也是相对的，如果你的CPU够强，内存够多，那么可以这个值相对来说低，这也就是可以解释这种情况：你的系统可能经常发生死机，你就采取提高硬件的办法，提高CPU，增大内存，原来系统是每3小时死机，那么现在提高硬件后，可能是不会每3小时死机了，但是会每天或两天死机，因为你根本问题没有解决，硬件提高只是苟延残喘。
这就象以前SAS一样，当初得SAS的人只能靠名贵呼吸机延长寿命，病毒源没有找到啊。
当然，也有侥幸的，虽然每天死机，但是，每天我可以重新启动了，你可以躲避每天死机了，但是注意，如果访问量比以前增加了，那你可能又回到每3小时死机的老路。
这些解决方案都是可以称为没有可伸缩性的,no scalable，我们软件架构一定要注重可伸缩性，这是软件架构重要内容，以前为什么没有架构这个词语，现在特别重视，这也是一个原因，都是失败经验教训，那些不重视架构的人，必然会重蹈覆辙，这些都是因为无知产生的可悲结果。
这也是2003年/2004年极力推荐EJB原因，因为EJB机制本身已经包含了资源控制和优化，如果你理论上对于前面原理不熟悉，选择EJB还能避免你架构方向错误。
如果你理论上属于无知，又狂热追求Spring这些新玩艺（当初），那么，即使你使用Spring，性能还是和Jsp+JavaBeans一样，在大访问量情况下经常死机，因为Spring里面需要手工配置Pool或Cache这些资源控制机制。
所幸，JdonFramework只需你实现一个Poolable接口就可以了。
回到可伸缩性话题上，不但架构要考虑单机，还要考虑单机不够怎么办？一味提高单机性能，在不断增长的访问量情况下，还是有单点风险，这是过去集中式主机思维的毛病。
我们需要廉价的，无单点风险的、多机的、集群的软件架构。这才是真正有伸缩性的。
请问JavaBeans被创建以后,我们不能通过赋null的方式取消它的引用么?
是否取消引用之后它仍然占用系统的内存?
清除JavaBeans占用的系统内存一定要通过Java的回收机制才能实现么?
>我们不能通过赋null的方式取消它的引用么?
是否取消引用之后它仍然占用系统的内存?
清除JavaBeans占用的系统内存一定要通过Java的回收机制才能实现么
垃圾回收机制的原理是：只回收那些不被引用的对象。内存不通过垃圾回收机制回收，还会其他方式吗？Java不需要象C那样，用完对象后，需要进行清理，所以你的对象赋null只是防止其他地方象这个对象里嵌入新的对象，否则，根本不起任何作用，有点掩耳盗铃。
我以前说过，如果说Java比C方便，因为对象使用之后不需要清理，那么有了Ioc/DI依赖注射以后，Java中对象使用之前也不需要创建了。
对象在一般语言中，如果需要使用，必须首先创建，使用完成后，必须清理，这些琐碎的事务困扰开发者的开发效率，现在在Java中无需了。
这些都是因为Java是容器概念的语言，对于容器这个概念，很多不容易接受，而且也很难处理与其互动，从对象清理这个问题就可以看出，所以，使用Java的企业系统缓慢，死机，这些都怪罪Java语言，而不从自己设计思维架构思路上寻找，正是睡不着觉怪床歪啊。
再补充一句：
将对象赋null做法不但不美观，而且是欺骗人的，这句话我经常从IBM/Websphere技术工程师嘴里听到，这里批评一下。注意，不是针对楼上。
看看那些经典的源码，有将对象赋null的语法吗？
关于控制资源，前面提到Pool和Cache，当然单例也是一种方式，不过这种方式在J2EE多线程环境下要时刻注意线程安全性，后者是Spring和JdonFramework等Ioc容器采取的方式，但是仅仅将业务逻辑Bean使用单例有时不够，还需要Pool支持；除了业务逻辑Bean要控制其资源，数据Bean也要控制，使用Cache，每次数据Bean对象获得都从数据库获得，虽然连接池水平再好，也是不具备伸缩性的，Cache才是真正根本解决之道。
一看到Cache，我就头大，能不能讲讲？
呵呵,banp讲得让人收益菲浅啊. 如果是这样的话,使用很多Web框架的时候会生成很多临时对象, 比如JSF得UIComponent, 也就是说当用户访问量超过一定的时候,内存就会被多余得Component消耗光了吗?
是啊,banq是否可以把话题扩展开来,讲讲cache和pool.看你的文章真是受益不浅啊.
>比如JSF得UIComponent, 也就是说当用户访问量超过一定的时候,内存就会被多余得Component消耗光了吗
表现层的对象相比巨无霸的业务Bean，只是小菜一碟，现在JDK改进，所以没有那么严重，当初Struts 2003左右出来的时候，大家也会发现在高负载系统使用它有些性能问题，但是现在这些都可以忽略不计，如果真这样，谁还会用java。
所以，只是针对巨无霸的业务Bean，数量几百，访问量并发100以上这样高负载情况。
其实Cache和Pool早在前几年我开展的企业培训中详细讲述了，看我以前的帖子可以知道我这一主导思想，老道友都能够看到的，等新论坛出来后，提供这些相关主题的连接供大家讨论。
论坛要改版？支持
数据库用MySQL吧，它对jsp的支持比MSSQL2000要好很多
BAND大哥，现在的WEB容器本身就带有Thread POOL支持呀，我们应该不用考虑Pool方面的问题吧