u011790603的博客

一、HttpRequest 请求方法根据HTTP标准，HTTP请求可以使用多种请求方法。HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法。HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。GET 请求指定的页面信息，并返回实体主体。HEAD 类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头POST 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求

一、需求缘起互联网公司，这样的场景是否似曾相识：场景一：pm要做一个很大的运营活动，技术老大杀过来，问了两个问题：（1）机器能抗住么？（2）如果扛不住，需要加多少台机器？场景二：系统设计阶段，技术老大杀过来，又问了两个问题：（1）数据库需要分库么？（2）如果需要分库，需要分几个库？技术上来说，这些都是系统容量预估的问题，容量设计是架构师必备的技能之一。常见的容量评估包括数据量、并发量、带宽、CPU/MEM/DISK等，今天分享的内容，就以【并发量】为例，看看如何回答好这两个问题。二、容量评

线上故障主要会包括cpu、磁盘、内存以及网络问题，而大多数故障可能会包含不止一个层面的问题，所以进行排查时候尽量四个方面依次排查一遍。同时例如jstack、jmap等工具也是不囿于一个方面的问题的，基本上出问题就是df、free、top 三连，然后依次jstack、jmap伺候，具体问题具体分析即可。CPU一般来讲我们首先会排查cpu方面的问题。cpu异常往往还是比较好定位的。原因包括业务逻辑问题(死循环)、频繁gc以及上下文切换过多。而最常见的往往是业务逻辑(或者框架逻辑)导致的，可以使用jsta

近期公司运营同学经常表示线上我们一个后台管理系统运行特别慢，而且经常出现504超时的情况。对于这种情况我们本能的认为可能是代码有性能问题，可能有死循环或者是数据库调用次数过多导致接口运行过慢。应领导要求，我们将主站中进行性能测试的框架代码（见我前面一篇博文记录一次通过性能日志处理线上性能问题的过程）添加到了该后台管理系统中。上线运行一段时间后，查看相关日志可以看到如下分析日志：性能分析日志通过该日志可以发现，dao方法一直获取不到数据库链接池，但是根据实际情况考虑应该不大可能，原因有两点：主站和后台管