相关分享
你的Spring Boot应用启动很慢?不妨试试这个工具!
睡不着闲逛,在GitHub上看到一个不错的开源项目:Spring Startup Analyzer。
从项目名称中就大概能猜到,这是一个分析Spring应用启动过程的工具。Spring Startup Analyzer通过采集Spring应用启动过程的数据,进而生成一个交互式的分析报告,帮助用户发现Spring应用启动慢的位置。同时,Spring Startup Analyzer还提供了Spring Bean异步初始化的工具,来帮助开发者加快Spring应用的启动时间。
下面一起来看看其提供的强大功能。
Spring 启动流程概述
对于 Spring 启动流程和 Bean 的生命周期,总有一些小地方搞的不是很清楚,干脆直接通过修改代码增加日志输出,使用断点单步调试,把整个流程捋顺了一点点的。
除了加载配置文件或者基础配置类外,Spring 的启动过程几乎都被封装在 AbstractApplicationContext#refresh 方法中,可以说弄清楚了这个方法的执行过程,就摸清楚了 Spring 启动全流程,下面的流程分析也是以这个方法为骨架来展开的。
流程概要 下面完整流程有些太复杂,所以,提炼一个简要的过程,方便糊弄面试官,哈哈哈
Systrace 响应速度实战 2 :响应速度实战分析-以启动速度为例
本文是响应速度系列的第二篇,主要是以 Android App 冷启动为例,讲解如何使用 Systrace 来分析 App 冷启动 。
VS Code 是如何优化启动性能的?
本文主要是对 CovalenceConf 2019: Visual Studio Code – The First Second 这次分享的介绍,CovalenceConf 是一个以 Electron 构建桌面软件为主题的技术会议,这也是 VS Code 团队为数不多的对外分享之一(质量较高),主要分享了 VS Code 是如何优化启动性能的。
Linux 下解决 grep is directory 问题
Grep 是一个很便捷有用的终端工具,它可以帮助我们快速过滤筛选出一些内容。通常配合 find 命令,可以实现更加强大的能力。
但是我们在执行的时候,总会遇到这样的错误提示输出:grep: ./example/android/.gradle: Is a directory。
之所以出现这个问题,原因是 find . -name "*.gradle" 匹配到了 .gradle 目录,而使用 grep 只是单纯扫描这个目录(非包含内部文件)没有任何意义。
还在解决方法有很多,可以轻松规避这个错误输出。
SPA nginx try_files 深度优化
上周有幸帮朋友解决一个线上用户端缓存不更新的问题。问题的表现在项目某次发版后,用户端访问页面提示 JS 报错。报错表明是 JS 返回的是 HTML 代码。
经过一番查看后,发现是用户端在发版的时候有访问过,而像 app.afds320.js 这些 JS 还不存在。命中了 localtion / { try_files } 规则。再加上 CDN 上有些默认的配置,给该 HTTP status 200 的文件加了 cache-control: max-age=7d 的缓存时间。导致用户端只要不强刷新或清缓存,这个文件就在7天内一直有问题了。
这个问题其实就是缓存配置的不合理导致的问题,我们应该适当的利用浏览器缓存、CDN 缓存来优化我们的项目。
iOS15如何让App启动更快?
目前还没有任何文献或会议可以了解更多有关于此更改的信息,但我们可以对其进行逆向工程,以了解 Apple 在新版本上有何不同,它是否优化了App的启动时间。首先,了解控制App启动的程序的一些背景知识。
改hosts不生效?教你清理Chrome的DNS缓存
在进行web开发的时候,我们经常会修改hosts文件进行测试,但是偶尔会发现改了hosts文件并不能立刻生效。这是由于浏览器自身对DNS(域名指向)是有进行缓存的,除了缓存之外,由于HTTP1.1支持连接复用,如果之前打开过这个页面,那么即使清理了DNS缓存也会因为复用连接再继续连接到旧的域名指向地址。如果出现连接被复用的情况就需要手动关闭活跃连接了。
iOS App 启动优化
App的启动一般是指从用户点击App开始到AppDelegate的didFinishLaunching方法执行完成为止,一般又将启动分为冷启动和热启动。
如何加快 Node.js 应用的启动速度
我们平时在开发部署 Node.js 应用的过程中,对于应用进程启动的耗时很少有人会关注,大多数的应用 5 分钟左右就可以启动完成,这个过程中会涉及到和集团很多系统的交互,这个耗时看起来也没有什么问题。
目前,集团 Serverless 大潮已至,Node.js serverless-runtime 作为前端新研发模式的基石,也发展的如火如荼。Serverless 的优势在于弹性、高效、经济,如果我们的 Node.js FaaS 还像应用一样,一次部署耗时在分钟级,无法快速、有效地响应请求,甚至在脉冲请求时引发资源雪崩,那么一切的优势都将变成灾难。
所有提供 Node.js FaaS 能力的平台,都在绞尽脑汁的把冷/热启动的时间缩短,这里面除了在流程、资源分配等底层基建的优化外,作为其中提供服务的关键一环 —— Node.js 函数,本身也应该参与到这场时间攻坚战中。
Faas平台从接到请求到启动业务容器并能够响应请求的这个时间必须足够短,当前的总目标是 500ms,那么分解到函数运行时的目标是 100ms。这 100ms 包括了 Node.js 运行时、函数运行时、函数框架启动到能够响应请求的时间。巧的是,人类反应速度的极限目前科学界公认为 100ms。
