我们有一个运行了 2 年的 Web 应用程序，没有任何问题。一周前突然之间，响应时间变得非常糟糕。比正常速度慢大约 10-50 倍。
一次可能有 10-20 个用户使用该系统。90% 的用户请求导致数据库请求。当没有多少用户在线时，系统会在清晨和晚上正常响应。
- 我们怎样才能发现问题。解决问题的分步文档？
- 是否有专门的公司或专家可以帮助我们解决问题？
环境
Windows Server 2003
Quadcore Intel Xeon X3220, 2.4GHZ, 2 GB Ram
Sybase Anywhere 9 数据库 - 驱动程序：jconn3.jar
Glassfish 2.1
服务器的互联网带宽：100MB/s
应用
外部公司访问的带有 SmartGWT-Frontend (SmartGwt 2.4)
WebService 的 Web 应用程序
没有 EJB，只有 WebContainer
首先，硬件似乎并没有达到极限。
完成繁重的请求时，Java.exe 有时会占用 25% 的 CPU 使用率，使用 374 MB Ram
sybase-db 服务器：220MB ram
可用内存：始终在 1GB 左右
请求快照
我在 8 分钟内对所有请求进行了快照
210 秒客户端请求 (gwtservice) 45%
总共 967 个请求，每个请求 212 毫秒
100 秒网络服务 (BankOrderService) 20%
总共 86 个请求，每个请求 1170 毫秒
160 秒将前端元素加载到浏览器（.js、.png、jpg、.css 等） 35%
总共 623 个请求，每个请求 250 毫秒
最耗时的请求示例（以毫秒为单位）：
15427.302 25.07.2012 11:50 Erfolg user1 REMOTE_WEB xx.yy.zz.228 URI:/BankApp/org.Bank.Main/091FF14E7C1D1187C770833D67B13321.cache.html
13558.571 25.07.2012 1 REMOTEWEB 1 REMOTEWEB URI:/BankApp/org.Bank.Main/sc/modules/ISC_Core.js
12631.877 25.07.2012 11:50 Erfolg user1 REMOTE_WEB xx.yy.zz.228 URI:/BankApp/org.Bank.Main/sc/modules/ ISC_Grids.js
11238.439 25.07.2012 11:50 Erfolg user1 REMOTE_WEB xx.yy.zz.228 URI:/BankApp/org.Bank.Main/sc/modules/ISC_Forms.js
10535.141 25.07.2012 11:50 Erfolg user1 REMOTE_WEB xx。 yy.zz.228 URI:/BankApp/org.Bank.Main/sc/modules/ISC_DataBinding.js
10003.115 25.07.2012 11:55 Erfolg 匿名 REMOTE_WEB xx.yy.zz.25 URI:/BankWebService/BankOrderService
9999.412 25.07.2012 11:49 Erfolg 匿名 REMOTE_WEB xx.yy.zz.25 URI:/BankWebService/BankOrderService
9999.229 25.07.2012 11:55 Erfolg 匿名 REMOTE_WEB xx.yy.zz.25 URI:/BankWebService/BankOrderService
9992.415 25. 11:49 Erfolg 匿名 REMOTE_WEB xx.yy.zz.25 URI:/BankWebService/BankOrderService
9990.473 25.07.2012 11:55 Erfolg 匿名 REMOTE_WEB xx.yy.zz.25 URI:/BankWebService/BankOrderService
9132.848 25.07.2012 11:55 Erfolg user1 REMOTE_WEB xx.yy.zz.228 URI:/BankApp/org.Bank.Main/gwtservice
5933.174 25.07.2012 11:50 Erfolg user2 REMOTE_WEB xx.yy.zz.162 URI:/BankApp/org.Bank.Main/sc /modules/ISC_Grids.js
5864.426 25.07.2012 11:50 Erfolg user2 REMOTE_WEB xx.yy.zz.162 URI:/BankApp/org.Bank.Main/sc/modules/ISC_Core.js
5571.739 25.07.2012 11:50 Erfolg user2 REMOTE_WEB xx.yy.zz .162 URI:/BankApp/org.Bank.Main/sc/modules/ISC_DataBinding.js
5473.637 25.07.2012 11:50 Erfolg user2 REMOTE_WEB xx.yy.zz.162 URI:/BankApp/org.Bank.Main/sc/ modules/ISC_Forms.js
5158.104 25.07.2012 11:50 Erfolg user3 REMOTE_WEB xx.yy.zz.237 URI:/BankApp/org.Bank.Main/gwtservice
4488.047 25.07.2012 11:50 Erfolg user2 REMOTE_WEB xx.yy.zz。 162 URI:/BankApp/images/chf.jpg
4442.574 25.07.2012 11:56 Erfolg user2 REMOTE_WEB xx.yy.zz.162 URI:/BankApp/org.Bank.Main/sc/modules/ISC_Core.js
4072.268 25.07.2012 11:54 Erfolg 匿名 REMOTE_WEB xx.yy.zz.25 URI:/BankWebService/BankOrderService
3939.546 25.07.2012 11:56 Erfolg user2 REMOTE_WEB xx.yy.zz.162 URI:/BankApp/org.Bank.Main /sc/modules/ISC_Grids.js
3876.443 25.07.2012 11:50 Erfolg user1 REMOTE_WEB xx.yy.zz.228 URI:/BankApp/org.Bank.Main/sc/modules/ISC_Foundation.js
3727.795 25.07.2012 11:50 Erfolg user4 REMOTE_WEB xx.yy.zz.162 URI:/BankApp/org.Bank.Main/gwtservice
3630.225 25.07.2012 11:48 Erfolg user4 REMOTE_WEB xx.yy.zz.162 URI:/BankApp/org.Bank.Main/ 091FF14E7C1D1187C770833D67B13321.cache.html
3552.007 25.07.2012 11:50 Erfolg user5 REMOTE_WEB xx.yy.zz.228 URI:/BankApp/org.Bank.Main/gwtservice
会话
18 个活动会话
客户端登录后（由 glassfish，https 提供），一旦用户通过 glassfish 身份验证，应用程序本身就会有第二次登录，用户必须定义他想要登录的分支。第二次登录后，会话中存储了 3 个属性（用户名、分支、IP 地址）。
总是有大约 40%-50% 的会话没有这 3 个属性，我这样解释，第一次登录成功但第二次没有。
示例：会话 id:e6df980ab67cf0456d78761eefa1
8 个没有 3 个属性的会话
会话 id:d72d16bdabb5500e73f721475440:{username=user1, branch=000x, ipadr=xx.xx.xx.xx}
具有 3 个属性的 10 个会话
我想也许这 8 个会话来自黑客？我跑了wireshark来看看是否有一些可疑的IP地址，但是我没有找到很多。有一天，有一个来自瑞典的 ip，我们在瑞典一无所有。然而，这并没有很多流量，在几秒钟内，wireshark 捕获日志中只有几行。
在 2012 年 7 月 17 日，其中一位用户的 msn 帐户已被黑客入侵。
在那一天左右，问题也开始了。可能会延迟 1-2 天。
巧合？
非常感谢任何帮助。