JSP Struts 性能/内存技巧
我正在开发一个基于 Struts 的基本应用程序，该应用程序在内存中遇到了严重的峰值。 我们有一个监控工具，它会注意到每个用户的一个请求向 JVM 堆内存添加了 3MB。 是否有任何建议可以鼓励尽早进行垃圾回收、释放内存或提高性能？
该应用程序是一个基本的 Struts 应用程序，但 JSP 报告中有很多行，因此可能创建了很多对象。 但这不是您以前从未见过的东西。
- 执行一组数据库查询。
- 创建序列化 POJO 对象 bean。 这代表一行。
- 将一行添加到数组列表中。
- 当调用操作时，将数组列表设置为表单对象。
- JSP 逻辑将循环访问 ActionForm 中的列表，并将数据显示给用户。
备注：
1. 表单在会话范围内，并且可能是数据数组列表（也许这是一个问题）。
2. POJO bean 包含 20 个左右字段，是 String 或 BigDecimal 数据的混合。
该报告可以有 300 到 1200 行左右。 所以至少创建了那么多对象。
I am working on a basic Struts based application that is experience major spikes in memory. We have a monitoring tool that will notice one request per user adding 3MB to the JVM heap memory. Are there any tips to encourage earlier garbage collection, free up memory or improve performance?
The application is a basic Struts application but there are a lot of rows in the JSP report, so there may be a lot of objects created. But it isn't stuff you haven't seen before.
- Perform a set of database query.
- Create an serialized POJO object bean. This represents a row.
- Add a row to an array list.
- Set the array list to the form object when the action is invoked.
- The JSP logic will iterate through the list from the ActionForm and the data is displayed to the user.
Notes:
1. The form is in session scope and possibly that array list of data (maybe this is an issue).
2. The POJO bean contains 20 or so fields, a mix of String or BigDecimal data.
The report can have 300 to 1200 or so rows. So there are at least that many objects created.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
根据您提供的信息，我估计您通常会加载 1 到 2 MB 的数据以获得结果：750 行 * 20 个字段 * 每个字段 100 字节 = 1.4 Mb。 现在考虑数据库和最终标记之间所需的所有临时对象。 3 Mb 并不奇怪。
我只会担心那段记忆是否泄露了； 即，年轻代空间的下一次垃圾收集不会收集所有这些对象。
Given the information you provide, I'd estimate that you're typically loading 1 to 2 megabytes of data for a result: 750 rows * 20 fields * 100 bytes per field = 1.4 Mb. Now consider all of the temporary objects needed between the database and the final markup. 3 Mb isn't surprising.
I'd only be concerned if that memory seems to have leaked; i.e., the next garbage collection of the young generation space doesn't collect all of those objects.
设计要在 Web 应用程序中呈现的报表时，请考虑从数据库获取的记录数。
如果记录数量较多并且整个记录集占用大量内存，则考虑使用报表分页。
尽可能不要显式调用垃圾收集器。 之所以如此，有两个原因：
垃圾收集是一个成本高昂的过程
因为它扫描整个内存。
大多数生产服务器都会
在 JVM 级别进行调整以避免
显式垃圾收集
When desiging reports to be rendered in web application, consider the number of records fetched from database.
If the number of records is high and the overall recordset is taking lot of memory, then consider using pagination of report.
As far as possible donot invoke garbage collector explicitly. This is so because of two reasons:
Garbage collection is costly process
as it scans whole of the memory.
Most of the production servers would
be tuned at JVM level to avoid
explicit garabage collection
我认为问题在于 ActionForm 中的数组列表需要分配大量内存空间。 我会将查询结果直接写入响应：从结果集中读取行，写入响应，读取下一行，写入等。也许这不是 MVC，但它对您的堆会更好:-)
ActionForms 适合 CRUD 操作，但对于报道来说……我不这么认为。
注意：如果 ActionForm 具有scope=session，则实例将一直处于活动状态（以及巨大的数组列表），直到会话过期。 如果scope=request，实例将可用于GC。
I believe the problem is the arraylist in the ActionForm that needs to allocate a huge chunk of memory space. I would write the query results directly to the response: read the row from the resultset, write to response, read next row, write etc. Maybe it's not MVC but it would be better for your heap :-)
ActionForms are fine for CRUD operations, but for reports ... I don't think so.
Note: if the ActionForm has scope=session the instance will be alive (along with the huge arraylist) until session expires. If scope=request the instance will be available for the GC.