如何定位Web应用响应慢原因

如何定位Web应用响应慢原因,第1张

运用听云Server解决Web应用过程响应慢,并且定位到具体代码,我们首先登陆听云Server控制台,点击需要查看的应用,进入Web应用过程模块。(听云Server中Web应用过程指:应用程序中处理一次独立的Web访问请求的过程,完整的web应用过程是从应用程序收到请求到响应的整个过程)

Web应用过程功能模块是将当前应用以Web应用过程的维度来展示详细的应用性能数据,包括以下几个功能:

“Web应用过程一览”列出当前应用所有的Web应用过程,并且可以按照耗时百分比、响应时间、吞吐率、Apdex、错误率进行排序。

“TOP5最耗时Web应用过程堆叠图”展示了耗时百分比最大的前5个Web应用过程其墙钟时间比在选定时间内的变化趋势。(墙钟时间比指的是Web应用过程在图表横坐标粒时间度下的总耗时时间/图表横坐标粒度时间)

“Web应用过程响应时间与吞吐率图”展示了应用的平均响应时间和每分钟请求次数在选定时间内的变化趋势。当请求的响应时间大于设定的阈值时会被显示在慢应用追踪列表中。(可在设置中对Web过程跟踪阈值进行设定,例如设置为500毫秒,那么所有响应时间大于500毫秒的请求都会被显示在慢应用过程追踪列表中,具体值根据自己的需求设置即可)

对于Web应用过程响应慢,我们选择按照“响应时间”进行排序,响应时间由长到短排列,选择时间较长的优先进行解决。

点击该Web应用过程进行数据钻取,查看其详细的性能分解。可以看到Web应用过程性能分解堆叠图,显示了这个Web应用过程中各个组件在选定时间内的平均响应时间的变化趋势。

“性能分解表格”展示了其中各个组件的详细性能信息,包括的信息有代码段、性能分类、耗时百分比、调用次数、平均响应时间,排列顺序是按照平均响应时间由长到短进行排序的。

“响应时间和吞吐率图”展示了该Web应用过程在选定时间内平均响应时间和每分钟请求次数的变化趋势。

“慢应用追踪列表”显示了该应用下响应时间大于设定阈值的请求,同样还是按照响应时间由长到短进行排序。

点击其中响应时间较长的请求进行慢应用追踪,跳转至应用过程慢追踪页面。

摘要中可以看到各个组件的响应耗时百分比图,下面还列出了各个最慢组件详细的调用次数、持续时间、响应耗时占比数据。

接下来重点查看追踪详情,可以看到各个代码段的持续时间、时间占比和时间偏移量,其中持续时间长时间占比高的就是响应时间长的代码段,则需要对该代码段进行重点的优化和修改,从而解决Web应用过程响应慢的问题。

后面的相关SQL展示了其中的SQL *** 作以及其调用次数和总耗时。

拓补图展示了相关的调用关系方便更加全面的分析问题,特别说明的是只有发生跨应用调用的应用过程慢追踪才会展示拓补图。

任何一个.NET项目,如果想快速定位问题,日志是少不掉的。但是在缺少日志的情况下,如果发现.NET项目存在访问缓慢、响应耗时长等性能问题,我们必须逐个的去排查。

考虑到不同项目的架构模式和业务模式不同,所以排查方法没有绝对一样的,结合我的工作经验,给出以下方案供各位.NET伙伴参考。

1、检查服务器负载情况

主要查看服务器三个大指标:内存、CPU、宽带的占用情况。如果这3个占用率过高,那就需要逐个再细化排查了。

2、排查前端问题

我们建议使用Chrome来调试,我们打开“开发者模式”(“视图”》开发者》开发者工具)切换到“Network”选项卡;然后在Chrome浏览器里打开B/S项目,看所有请求中,哪些请求耗时最长,如果发现有耗时请求,点击查看具体是哪个环境耗时较长。

一般前端以下请况会影响网页加载:

存在404的资源请求;

请求的图片物理尺寸过大,比如超过1M;

JavaScript文件阻塞了资源加载。

3、数据库性能问题

当发现系统运行缓慢后,我们要开启数据库日志,判断是否存在慢查询,如果有则需要优化SQL语句和表结构。

4、检查程序中是否存在循环或者逻辑缺陷;

5、检查程序中是否存在外部API,如果有,则可能是因为外部API请求超时导致系统缓慢。

综上,一方面我们可以逐步排查,另一方面我们也需要借助.NET性能分析工具来配合排查。性能分析工具很多,如JetBrainsdotTrace也不错可以尝试用下。

基于android的定位无非就两种:network、gps。两者各有优劣。

Network:定位快,准确度低,受环境影响小。

GPS:定位慢,准确度高,受环境影响大。

本文要解决的问题:

1. locationManager.getLastKnownLocation方法返回null。

2. 如何实现快速而又精确的定位。

E文好的话,直接看官网就好了http://developer.android.com/guide/topics/location/strategies.html

在你的程序里如果有这样的代码你就要注意了(现在看来这些倒是多余了)

[java] view plaincopy

Criteria criteria = new Criteria()

criteria.setAccuracy(Criteria.ACCURACY_FINE)//高精度

criteria.setAltitudeRequired(false)//无海拔要求

criteria.setBearingRequired(false)//无方位要求

criteria.setCostAllowed(true)//允许产生资费

criteria.setPowerRequirement(Criteria.POWER_LOW)//低功耗

// 获取最佳服务对象

String provider = locationManager.getBestProvider(criteria,true)

locationManager.getLastKnownLocation(provider)

locationManager.getBestProvider(criteria,true)方法看起来很完美,但其实返回值就network、gps二选一。而且如果你要求高精度,它会优先检查GPS,如果手机开启了GPS就返回GPS,否则返回network。如果都没开启则返回null。

结合Network、GPS两种定位方式的优劣不难看出为什么getLastKnownLocation方法会返回null(这只针对第一次定位)。

当你开启GPS,provider的值为GPS。这时的定位方式为GPS,由于GPS定位慢(我测试的时间大约为50秒),所以它不可能立即返回你一个Location对象,所以就返回null了。还有人用下面的方法解决这个问题:

[java] view plaincopy

while (location ==null) {

location = locationManager.getLastKnownLocation(provider)

}

这绝对是个愚蠢的做法!举个例子:如果你在室内,gps无法定位到,你的程序将陷入死循环。当然使用requestLocationUpdates可以做到定位且不让程序陷入死循环,但是定位耗时长,甚至得不到定位。

如果使用网络定位呢,不得说这也是一个不错的选择。locationManager.requestLocationUpdates(

LocationManager.NETWORK_PROVIDER, 0, 0,networkListener)

网络定位耗时一般在2秒左右(网络差,时间会更长),只要你接入网络,基本上都能获得定位。唯一的缺点就是精度不高。

那能不能将两者结合,这也是本文的重点。既然结合两者,就要同时为两者添加监听

[java] view plaincopy

locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER,1000 * 2,50,gpsListener)

locationManager.requestLocationUpdates(LocationManager.NETWORK_PROVIDER, 0, 0,networkListener)

这样,大概2秒我们就可以得到来自网络的定位,一分钟后得到来自GPS定位。这时用GPS定位替换网络定位就好了。当然这只是个理想的情况,现实要复杂的多。

比如:

你第一次定位成功返回location,由于网络问题第二次返回null。这时会发现,更新的location没有上次的精确,甚至是null,无法使用,这时我们要判断当前的location和新获得的location那个更好。可能你获得GPS定位后,由于天气、进入隧道等原因GPS服务器丢失,无法更新location(这时一个好的做法是切换到network定位)。还有可能用户没有开启GPS和network,根本就谈不上定位(其实每次定位成功都会有个定位缓存的,可以使用getLastKnownLocation获得)。

终上所述,我们要做的就是:

1. 尝试通过getLastKnownLocation获取上次定位信息

2. 开启network和gps监听

3. 获得network定位信息location

4. 比较当前location和新获取的location哪个更好(来自network)

5. 获得gps定位信息location

6. 停掉network监听

7. 比较当前location和新获取的location哪个更好(来自gps)

8. 如果gps服务器丢失,重新开启network监听

以GPS监听为例

[java] view plaincopy

// GPS监听的回调函数

private class GPSLocationListener implements LocationListener {

private boolean isRemove = false//判断网络监听是否移除

@Override

public void onLocationChanged(Location location) {

// TODO Auto-generatedmethod stub

boolean flag =betterLocation.isBetterLocation(location,

currentBestLocation)

if (flag) {

currentBestLocation = location

updateLocation(currentBestLocation)

}

// 获得GPS服务后,移除network监听

if (location !=null &&!isRemove) {

locationManager.removeUpdates(networkListener)

isRemove = true

}

}

@Override

public void onProviderDisabled(String provider) {

// TODO Auto-generatedmethod stub

}

@Override

public void onProviderEnabled(String provider) {

// TODO Auto-generatedmethod stub

}

@Override

public void onStatusChanged(String provider, int status, Bundleextras) {

// TODO Auto-generatedmethod stub

if (LocationProvider.OUT_OF_SERVICE == status) {

Toast.makeText(MainActivity.this,"GPS服务丢失,切换至网络定位",

Toast.LENGTH_SHORT).show()

locationManager

.requestLocationUpdates(

LocationManager.NETWORK_PROVIDER, 0, 0,

networkListener)

}


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/yw/12204128.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-21
下一篇 2023-05-21

发表评论

登录后才能评论

评论列表(0条)

保存