First of all, you choose the original JSP / Servlet JavaBeans structure, JSP / servlet is actually thread, when computing users accesses, it is multithreading, so, in your program, first avoid multithreading access to the same resource, Especially Singleton, this problem has been discussed in front of the post, such as: Originally, it is going on in parallel, to a wooden bridge, must be serialized, then the performance is greatly reduced. The best way is that an object is a thread service, and 10 objects have been accessed. This is the highest, but attention to, if you have a JavaBeans object, you have to create every time you have been created, it is possible to waste performance Especially the JavaBeans code is much, when the features are more functions, use pool, starting to generate these JavaBeans objects in memory when the system is started. These JavaBeans I have said are functionality Javabeans, improve functionality of functionality through pool. Another is data JavaBeans, which is specifically loaded, and this part uses cache to improve. There is already pool support in the EJB, if you transplant the functionality JavaBeans code to the session beans, then improve the processing performance of the concurrent user, use SLSB's LOCAL, turn off its network performance loss; turn off SLSB The transaction mechanism (if not required), this will turn SLSB into a special JavaBeans for pure Pool support. Since the entity bean under EJB is Cache support, you can implement the cache of data JavaBeans with entity beans, but it is recommended, it is best to do some caching in the web floor, which is the best in the client. In short, the performance problem is actually the problem that the architecture choice is inadvertent. In this forum, I saw too many JSP JavaBeans performance issues. Why don't we choose the powerful EJB architecture from the beginning of the system? This, When your system expands, you don't have to have a headache for system performance, or even performance problems causing your JSP JavaBeans system failure.
