我只是在使用基于 Netbeans 的 Profiler 对我的 JSF 项目进行一些分析实验。然而我发现了一个非常令人惊讶的结果。我发现 JSF 的FacesServlet.service()方法在处理请求时大部分时间都在消耗。我确实将数据库中的内容提供到我的 JSF 页面中，但我仍然发现主要的时间延迟是由于方法自身时间过长造成的service()。
这是分析结果的快照：-
为什么会发生这种情况，在这种方法中发生了什么如此昂贵导致如此高的自我时间？
我在 Tomcat 7.0.42 上以生产模式运行 Myfaces 2.1.12。
正如@mkienenb 在下面的回答中正确指出的那样，在上面的分析测试中，我排除了这些org.apache.myfaces方法，所以我做了一个新的分析测试，我在新的结果快照下面发布。
但是你仍然可以看到很多时间开销是由于 Myfaces/JSF 方法的自身时间造成的。
我不是分析专家，但我很确定“自我时间”包括所有未在其他地方明确分析的方法。由于某种原因，您似乎没有单独分析“org.apache.myfaces”方法，而只是分析 javax.faces 方法。
所以这将使所有 JSF 执行时间都显示在 javax.faces.webapp.FacesServlet.services() 下。
您需要调整您的包裹排除选项。我不使用 NetBeans，所以我无法具体告诉您它是如何完成的。
嗯，FacesServlet.service() 的参数是什么？那是servlet 请求和servlet 响应吗？看起来像是来自您的浏览器的典型请求和来自您的应用程序/服务器的响应。
很明显，您的代码和依赖项的使用是 FacesServlet.service() 完成所需时间的原因。哇，似乎您对漂亮面孔依赖项的使用导致 FacesServlet.service() 完成所需的大部分时间。
2013 年 9 月 7 日星期六凌晨 2:24，Anton Gavazuk 写道：
通过执行请求处理生命周期来处理传入的请求，并创建相应的响应。
如果此方法的请求和响应参数分别不是 HttpServletRequest 和 HttpServletResponse 的实例，则调用此方法的结果是未定义的。
此方法必须通过在响应参数上调用 sendError 方法（强制转换为 HttpServletResponse）来响应以以下字符串开头的请求，并将代码 HttpServletResponse.SC_NOT_FOUND 作为参数传递。
所以这个方法实际上是把所有底层处理都包起来了：jsf动作、业务服务、与db的交互——因此它的时间总是最大的
作为对 OP 的回应并展示上面所说的 Anton（来自 myfaces 列表），
(1) 在开始这个请求之前，我的浏览器显示了“会话超时”页面，所以我点击了确定，它向服务器发出了一个简单的请求，以响应登录页面。下面的屏幕截图将向您展示，如此简单的请求产生的响应时间如此之快，以至于找不到 FacesServlet.service()。
(2) 在浏览器中呈现登录页面后，我单击登录按钮，我的应用程序执行了几项操作（检查数据库的用户 ID，验证存储在数据库中的密码，然后导航到并呈现一个进行数据库检索的页面，这可能需要几秒钟，具体取决于当前日期完成的用户操作数（它是用户审计跟踪数据/页面），当然，页面是在浏览器中呈现的，毕竟。我搜索了对于 FacesServlet.service() 多次，直到没有发现更多事件。在下面的屏幕截图中，您将看到 FacesServlet.service() 的“时间”是由完成其他/基础/调用的操作/流程所花费的时间引起的。
(3) 在 Audit Trail 页面上，我单击了一个选项，该选项将调用 AJAX 请求/响应，这将执行一个数据库检索，该检索可能/将需要比上面 #2 中的数据库检索更长的时间，然后 AJAX 响应将是在浏览器中呈现。下面的屏幕截图将再次向您展示 FacesServlet.service() 的“时间”是由完成其他/基础/调用的操作/流程所花费的时间引起的。
(4) 接下来/最后，我决定单击一个菜单栏选项，它会根据当前日期进行数据库检索以显示数据库中的数据，并导航到和/或在浏览器中呈现不同的页面。下面的屏幕截图将再次向您展示 FacesServlet.service() 的“时间”是由完成其他/基础/调用的操作/流程所花费的时间引起的。
我在 Tomcat 7.0.42 上以生产模式运行 Myfaces 2.1.12。
我也是...通过 TomEE+ 1.6.0 'snapshot' (2013-September-06 version/build)