关键词：

通过分析TLS握手过程的细节我们会发现HTTPS比HTTP会增加多个RTT网络传输时间，既增加了服务端开销，又拖慢了客户端响应时间。因此，性能优化是必不可少的工作。很多文章都集中在服务端的性能优化上，但对于电商行业而言，大部分的用户流量源于App，因此客户端的性能优化配合服务端才能使收益最大化。

• 1. HTTPS带来的负担
  • 1.1 增加的传输延时
  • 1.2 服务端额外开销
• 2. 服务端性能优化
  • 2.1 HSTS的合理使用
  • 2.2 会话恢复的合理使用
  • 2.3 Ocsp stapling的合理使用
  • 2.4 TLS协议的合理配置
  • 2.5 False Start的合理使用
  • 2.6 SNI功能的合理使用
  • 2.7 HTTP 2.0的合理使用
  • 2.8 SSL硬件加速卡合理使用
• 3. 客户端性能优化
  • 3.1 移动端HTTP2加速代理
  • 3.2 HttpsDns解决DNS攻击劫持

1. HTTPS带来的负担

凡事都有两面性。

1.1 增加的传输延时

使用HTTPS传输增加的开销不仅仅是两次TLS握手的过程。优化性能首先要知己知彼。了解性能损耗在哪里，才能有针对性的进行部署。
对于用户来说，使用HTTP请求，首次请求时只要和服务端TCP三次握手建立连接，便可以开始应用数据传输了。

而对于HTTPS而言，事情就不那么简单了。

1. 用户习惯于使用HTTP请求你的网站。要保护用户的安全，首先要让用户强制302/301到HTTPS。这次跳转至少增加1个RTT的延时；
2. 302跳转后要再次TCP建连，增加1个RTT的延时；
3. 开始两阶段TLS握手，细节如下图所示，增加至少两个RTT的延时。

- Client Hello: 客户端开始新的握手，并将自身支持的功能提供给服务端；
- Server Hello:服务端选择连接参数；
- Certificate*:服务端发送证书链；
- ServerKeyExchange*:服务端发送公钥（public key）等生成主密钥（premaster secrect）的额外信息给客户端；
- ServerHelloDone:服务端通知完成协商过程；
- ClientKeyExchange:客户端发送加密后的主密钥给服务端
- [ChangeChiperSpec]:客户端如果要切换加密方式通知服务端
- Finished:客户端完成
- [ChangeChiperSpec]:服务端如果要切换加密方式通知客户端
- Finished:服务端完成
4. 另外客户端如果第一次获取服务端的证书链信息，还需要通过Oscp来验证证书的吊销状态，又需要至少1个RTT延时。
5. 最终，开始应用层数据的传输。

1.2 服务端额外开销

TLS握手过程中密钥交换和加密对CPU都会产生额外的计算开销。选择不同的算法（身份验证算法、密钥交换算法、加密算法）开销不同。比如，2048位RSA作为密钥交换算法对CPU压力就会很大，而ECDHE_RSA（椭圆曲线密钥交换）开销就小的多，RSA可以仍保留用于身份验证。
当然，不管选用多优化的算法，开销是避免不了的，如下图所示。

2. 服务端性能优化

服务端性能优化，主要体现在Web服务器配置的优化，我们以Ngnix 1.11.0版本为例。当然你也可以选择Apache、H2O等。

2.1 HSTS的合理使用

HSTS（HTTP Strict Transport Security, HTTP严格传输安全协议）表明网站已经实现了TLS，要求浏览器对用户明文访问的Url重写成HTTPS，避免了始终强制302重定向的延时开销。
HSTS的实现原理是：当浏览器第一次HTTP请求服务器时，返回的响应头中增加Strict-Transport-Security，告诉浏览器在指定的时间内，这个网站必须通过HTTPS协议来访问。也就是对于这个网站的HTTP地址，浏览器需要现在本地替换为HTTPS之后再发送请求。
其配置如下所示。max-age表明HSTS在浏览器中的缓存时间，includeSubdomainscam参数指定应该在所有子域上启用HSTS，preload参数表示预加载，稍后会具体解释。

add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"

在CanIUse上我们可以查询HSTS协议的浏览器支持度：

在使用HSTS的过程中仍有一些值得注意的问题：
1. HSTS将全部的证书错误视为致命的。因此，一旦主域使用HSTS，浏览器将放弃对域名所有无效证书站点的连接。
2. 首次访问仍然使用HTTP，然后才能激活HSTS。无法保障首次访问的安全性如何解决？可以通过preloading预加载的方式，与浏览器厂商约定好一份支持HSTS的网站清单来缓解。目前Google已经提供了在线注册服务https://hstspreload.appspot.com/
3. 如何撤销HSTS？通过Strict-Transport-Security: max-age=0将缓存设置为0可以撤销HSTS。但是只有当浏览器再次访问网站并且得到响应更新配置时才能生效。

2.2 会话恢复的合理使用

会话恢复机制是指在一次完整协商的连接断开时，客户端和服务端会将会话的安全参数保存一段时间。后续的连接，双方使用简单握手恢复之前协商的会话。大大减少了TLS握手的开销。
会话恢复的方案可以分为两种：会话ID（Session ID）和会话票证（Session Ticket）。会话ID通过服务端为会话指定唯一的标识，并缓存会话状态。在第一次完整协商的过程中，ServerHello消息中将会话ID发回客户端。希望恢复会话的客户端在下一次握手中将会话ID放入ClientHello，服务端认可后接着使用之前协商的主密钥进行加密。而会话票证将所有会话状态保持在客户端（类似于HTTP Cookie）。
1. 配置会话票证较为简单：

ssl_session_tickets on;
ssl_session_ticket_key /usr/local/nginx/ssl_cert/session_ticket.key;

生产key的命令通过openssl生成：

openssl rand –out session_ticket.key 48

注意集群情况下key值保持一致。另外注意使用会话票证前需要开启支持前向性加密支持的密钥套件。
2. 配置会话ID需要注意，会话状态是保存在服务器上的，集群状态下如何保证会话ID的命中率？最简单的方式是负载的轮询策略使用IP_HASH，保证同一客户端总是被分发到集群中的相同节点，但这样未免不够灵活。因此需要采用分布式缓存的方式，将会话状态存储在集群共享的redis中。
如何操作Nginx中的TLS会话信息，可以参考openresty中的ssl_session_fetch_by_lua_block 模块。具体见https://github.com/openresty/lua-nginx-module#ssl_session_store_by_lua_file。

2.3 Ocsp stapling的合理使用

OCSP（Online Certificate Status Protocol, 在线证书状态协议）用于查询证书的吊销信息。OCSP实时查询会增加客户端的性能开销。因此，可以考虑通过OCSP stapling的方案来解决：OCSP stapling是一种允许在TLS握手中包含吊销信息的协议功能，启用OCSP stapling后，服务端可以代替客户端完成证书吊销状态的检测，并将全部信息在握手过程中返回给客户端。增加的握手信息大小在1KB以内，但省去了用户代理独立验证吊销状态的时间。
启用OCSP stapling的方式有很多种，比如在线校验。此方式需要支持服务器能够主动访问证书校验服务器才能生效，并且在每次重启nginx的时候会主动请求一次，如果网络不通会导致nginx启动缓慢。

# 启用OCSP stapling
ssl_stapling on;
# valid表示缓存5分钟，resolver_timeout表示网络超时时间
resolver 8.8.8.8 8.8.4.4 223.5.5.5 valid=300s;
resolver_timeout 5s;         
# 启用OCSP响应验证，OCSP信息响应适用的证书   
ssl_stapling_verify on;  
ssl_trusted_certificate /usr/local/nginx/ssl_cert/trustchain.crt;      

为了更可靠，你也可以人工负责更新文件内容，设定Nginx直接从文件获取OCSP响应而无需从服务商拉取。

# 启用OCSP stapling
ssl_stapling on;
ssl_stapling_file /usr/local/nginx/oscp/stapling_file.ocsp;            
# 启用OCSP响应验证，OCSP信息响应适用的证书   
ssl_stapling_verify on;  
ssl_trusted_certificate /usr/local/nginx/ssl_cert/trustchain.crt;      

2.4 TLS协议的合理配置

首先要指定TLS协议的版本，不安全的SSL2和SSL3要废弃掉

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

其次，建议启用ssl_prefer_server_ciphers，用来告诉Nginx在TLS握手时启用服务器算法优先，由服务器选择适配算法而不是客户端：

ssl_prefer_server_ciphers on

然后，选择最优的加密套件以及优先顺序，具体可参考Mozilla的https://wiki.mozilla.org/Security/Server_Side_TLS。优先选择支持前向加密的算法，且按照性能的优先顺序排列：

ssl_ciphers ssl_ciphers "ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-RSA-CHACHA20-POLY1305 ECDHE-ECDSA-AES128-GCM-SHA256 
        ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES128-GCM-SHA256 
        DHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-ECDSA-AES128-SHA 
        ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES128-SHA ECDHE-ECDSA-AES256-SHA384 ECDHE-ECDSA-AES256-SHA ECDHE-RSA-AES256-SHA 
        DHE-RSA-AES128-SHA256 DHE-RSA-AES128-SHA DHE-RSA-AES256-SHA256 DHE-RSA-AES256-SHA ECDHE-ECDSA-DES-CBC3-SHA 
        ECDHE-RSA-DES-CBC3-SHA EDH-RSA-DES-CBC3-SHA AES128-GCM-SHA256 AES256-GCM-SHA384 AES128-SHA256 AES256-SHA256 
        AES128-SHA AES256-SHA DES-CBC3-SHA !DSS";

最后，如果有双向验证的需求，可以开启Nginx的客户端身份验证。Nginx将只接受包含有效客户端证书的请求。如果请求未包含证书或者证书校验失败，Nginx会返回一个400错误响应。

# 要求客户端身份验证
ssl_verify_client on;
# 指定客户端证书到根证书的最大证书路径长度
ssl_verify_depth 3;
# 指定允许签发客户端证书的CA证书
ssl_client_certificate trustchain.crt;
# 完整证书链中需要包含的其他CA证书
ssl_trusted_certificate root-ca.crt;
# 证书吊销列表
ssl_crl revoked-certificates.crl;

2.5 False Start的合理使用

TLS False Start是指客户端在发送ChangeCipherSpec Finished 同时发送应用数据（如HTTP请求），服务端在 TLS 握手完成时直接返回应用数据（如HTTP响应）。这样，应用数据的发送实际上并未等到握手全部完成，故谓之False Start。

要实现False Start，服务端必须满足两个条件：
1. 服务端必须支持NPN（Next protocol negotiation, ALPN的前身）或者ALPN（Application layer protocol negotiation, 应用层协议协商）；
2. 服务端必须采用支持前向加密的算法。
补充说明下什么是前向加密（perfect forward secrecy）。前向加密要求一个密钥只能访问由它所保护的数据；用来产生密钥的元素一次一换，不能再产生其他的密钥；一个密钥被破解，并不影响其他密钥的安全性。

2.6 SNI功能的合理使用

SNI（Server Name Indicate）允许客户端在发起SSL握手请求时（ClientHello阶段），就提交请求的Host信息，使得服务器能够切换到正确的域并返回相应的证书。通过这种方式解决了一个IP（虚拟机）部署多个域名服务的问题。
Nginx支持SNI的方式并自动开启。当遇到不支持这一特性的客户端用户时，通常情况下，Nginx会返回默认站点的服务器证书。比如下面的情况下，不支持SNI的客户端，Nginx返回serversuning.pem。这样证书是否能正确匹配是无法保障的，会带来不必要的麻烦和困扰。因此，移动端开发都应该要求启用SNI扩展。

server 
    listen 443 ssl default_server;

    ssl_certificate /usr/local/nginx/cert/serversuning.pem;  
    ssl_certificate_key /usr/local/nginx/cert/suning.key; 
    ...


server 
    listen 443 ssl;
    server_name sit1.suning.com;

    ssl_certificate /usr/local/nginx/cert/serversuningcom.pem;  
    ssl_certificate_key /usr/local/nginx/cert/suningcom.key; 
    ...

server 
    listen 443 ssl default_server;
    server_name sit1.suning.cn;

    ssl_certificate /usr/local/nginx/waf/serversuningcn.pem;  
    ssl_certificate_key /usr/local/nginx/waf/suningcn.key; 
    ...

2.7 HTTP 2.0的合理使用

HTTP 2笔者在《 HTTP 2.0 原理详细分析》和《 Nginx实现HTTP/2——原理、实践与数据分析》中都有详细地介绍，这里就不再展开。需要提示下，Nginx在1.9.x版本就开始尝试支持http2协议，但每个版本都会有bugfix，仍需要谨慎开启，具体可参考Nginx版本更新日志。

2.8 SSL硬件加速卡合理使用

可以通过SSL硬件加速卡设备来代替CPU进行TLS握手过程中的运算。推荐的有Cavium的加速卡，Cavium引擎可以集成到Nginx模块中，支持物理机和虚拟机环境。同时，虚拟机环境下的测试效果要比物理机好。建议开启Nginx异步请求Cavium引擎模式，更有效提高使用率。
下面是我们压测的CPU到20%情况下，使用TLS 1.2协议、加密套件采用ECDHE-RSA-AES128-SHA256 、HTTPS 短连接的各种环境性能数据，可见使用Cavium，物理机性能提升比：325%，虚拟机性能提升比：588%。

环境	流量类型	TPS	延迟(s)
虚拟机	HTTPS	172	0.066
虚拟机 + Cavium加速卡	HTTPS	1012	0.066
物理机	HTTPS	832	0.066
物理机 + Cavium加速卡	HTTPS	2708	0.059

另外，是否使用硬件加速见仁见智了，其在性能提升上肯定是有效果的，但由于设备价格高昂，很难大规模化，对于大部分互联网公司是一件奢侈品。借用Facebook关于硬件加速的说法：
“我们发现当前基于软件的TLS实现在普通CPU上已经运行的足够快，无需借助专门的加密硬件就能够处理大量的HTTPS请求。我们使用运行于普通硬件上的软件提供全部HTTPS服务。”

最后，我们来总结下服务端Nginx的配置，一个配置模板仅供参考：

server 
    listen 443 ssl http2 default_server;
    server_name  site1.suning.com;
        add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";

        ssl_certificate /usr/local/nginx/cert/serversuningcom.pem;  
        ssl_certificate_key /usr/local/nginx/cert/suningcom.key;  

        # 分配10MB的共享内存缓存，不同工作进程共享TLS会话信息
        ssl_session_cache shared:SSL:10m;
        # 设置会话缓存过期时间24h
        ssl_session_timeout 1440m;

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 SSLv3;   
        ssl_prefer_server_ciphers on;  
        ssl_ciphers ssl_ciphers "ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-RSA-CHACHA20-POLY1305 ECDHE-ECDSA-AES128-GCM-SHA256 
        ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES128-GCM-SHA256 
        DHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-ECDSA-AES128-SHA 
        ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES128-SHA ECDHE-ECDSA-AES256-SHA384 ECDHE-ECDSA-AES256-SHA ECDHE-RSA-AES256-SHA 
        DHE-RSA-AES128-SHA256 DHE-RSA-AES128-SHA DHE-RSA-AES256-SHA256 DHE-RSA-AES256-SHA ECDHE-ECDSA-DES-CBC3-SHA 
        ECDHE-RSA-DES-CBC3-SHA EDH-RSA-DES-CBC3-SHA AES128-GCM-SHA256 AES256-GCM-SHA384 AES128-SHA256 AES256-SHA256 
        AES128-SHA AES256-SHA DES-CBC3-SHA !DSS";

        ssl_session_tickets on;
        ssl_session_ticket_key /usr/local/nginx/ssl_cert/session_ticket.key;

        #设置TLS日志格式
        log_format ssl "$time_local $server_name $remote_addr $connection $connnection_requests $ssl_protocol 
        $ssl_cipher $ssl_session_id $ssl_session_reused";
    access_log /usr/local/nginx/logs/access.log ssl;

    ssl_stapling on;
        ssl_stapling_file /usr/local/nginx/oscp/stapling_file.ocsp;            
        ssl_stapling_verify on;  
        ssl_trusted_certificate /usr/local/nginx/ssl_cert/trustchain.crt;      

    root   html;
    index  index.html index.htm;

    location / 
        ...
    
        error_page 403 /403.html;
        location = /403.html 
            root /usr/local/nginx/waf/403/default;
        
        error_page 500 502 503 504 /502.html;
        location = /502.html 
            root /usr/local/nginx/waf/403/default;
        

3. 客户端性能优化

App中使用HTTPS请求，建议设计客户端的代理层SDK。代理层的主要目的包括两点：（1）统一以HTTP 2协议向服务端转发请求；（2）调用服务端HttpDns接口，获取准确的地址解析信息。

3.1 移动端HTTP2加速代理

比如Android使用组件OkHttp 3，IOS使用组件NSURLSession，都可以支持HTTP 2.0协议。我也曾翻译介绍过《OkHttp, 安卓和Java应用的HTTP&HTTP2.0客户端》。深入到具体代码开发和使用层面不在本文中展开。只有当客户端和服务端都采用HTTP 2.0进行通信，才能达到加速的效果。通过数据也能印证HTTP 2.0的效果。

3.2 HttpsDns解决DNS攻击劫持

Dns劫持通过篡改用户的解析指向，将用户的流量导向第三方，以实现恶性盈利的目的。另外还有一些运营商为了避免网间结算费用，会在内网做站点镜像，再通过Dns劫持的方式，使用户直接访问镜像。

当全站实现HTTPS后，由于缺乏证书和私钥等必要信息，能够保证他人Dns劫持用户后无法达到非法目的，但同时也无法正常响应用户的请求。这就是一把双刃剑，因为普通用户只会认为是你的网站加载不出来。

所以，全站HTTPS只能避免Dns劫持带来的损失，解决Dns劫持问题还需要另觅良法。从根本上而言Dns劫持的原因是我们无法控制本地的LocalDNS不被黑（毕竟是运营商的东西你懂的），那么有没有可能绕开运营商解析？PC端我们肯定是做不到的，而移动端App我们可以使用HttpsDns的方案。
HttpsDns方案：用Https协议（IP代替域名）向HttpDns集群（权威DNS）的443端口进行请求，代替传统的DNS协议向DNS服务器的53端口进行请求。也就是使用Https协议去进行dns解析请求，将服务器返回的解析结果，也就是域名对应的服务器ip获得，直接向该ip发起对应的api服务请求，代替使用域名。备选情况下（HttpsDns解析失败），再走传统的LocalDNS解析方式。

HttpsDns的方案优势在于：
1. 防止了LocalDNS劫持问题
2. 平均访问延迟下降，由于后续请求直接通过IP访问，省去了域名解析时间。并且可以通过一些算法计算出最优性能的服务端IP（Ping延时最小），缓存在客户端本地地址库；
3. 用户连接失败率下降
目前提供HttpDns服务端能力的厂商有中网、dnspod等，基本上是以约定接口的形式供客户端来调用，返回解析结果。比如：

客户端的实现并没有想象的简单，用ip替换域名访问，要考虑很多问题，比如：
1. Https场景下ip直连出现的证书校验问题
2. 代理场景下的HttpDns问题
3. ip访问的时候Cookie的问题
在这里我们不再展开，有兴趣可以参考：
《Android 使用OkHttp支持HttpDNS》 http://blog.csdn.net/sbsujjbcy/article/details/50532797
《Android OkHttp实现HttpDns的最佳实践（非拦截器）》 http://blog.csdn.net/sbsujjbcy/article/details/51612832
CNSRE/HTTPDNSLib https://github.com/CNSRE/HTTPDNSLib

以上，针对TLS层的性能优化就已经完结了。然而，这就结束了吗？性能提升就到此为止了吗？当然不是。一方面，我们还应该关注与最大限制地去提升TCP层的性能，来配合TLS的优化。包括初始拥塞窗口调优、防止空闲时慢启动、keep-alive等；
另一方面，关注更新的技术成果和动态，比如追求0RTT损耗的TLS 1.3、QUIC协议等

电商网站https实践之路——概述篇(代码片段)

...HTTPS已经是互联网企业发展的大势所趋。继淘宝、京东等电商完成全站HTTPS化后，笔者负责领导了公司的全站HTTPS工作。在整个过程中，笔者深刻体会到对于一个大型网站而言，全站HTTPS绝对是一个挑战巨大且需要严谨... 查看详情

电商网站https实践之路——系统改造篇(代码片段)

首先是要让系统支持HTTPS。需要有接入层来统一处理TLS握手。页面资源的替换也存在一些坑。对于不同的域证书选择上也要注意，最好的方式是提前整理好域列表绑定成一张支持多域名和泛域名的证书。大多数互联网公司的CD... 查看详情

电商网站https实践之路——灰度上线篇

对于电商而言，不能因为技术的升级就轻易影响了线上业务，毕竟最宝贵的是用户流量。当我们一鼓作气完成了系统的HTTPS改造和优化后，上线过程则是小心翼翼逐步完成的，毕竟这么大的调整动作牵一发而动全... 查看详情

flutter性能优化实践——ui篇(代码片段)

...越好。这篇集中整理了deer在UI流畅上的优化细节，以实践为主，源码为辅。分享出来，希望对你有所启发 查看详情

vue性能优化篇（图片优化）(代码片段)

一、图片保存阶段ps或sketch等图片，保存时或保存后，使用photoshop1、.jpg图片选择“连续”2、.png图片选择“优化”二、图片压缩1、访问https://tinypng.com/对所有图片进行压缩，后替换（图片质量不变，可多图一起压缩）三、单色ico... 查看详情

flutter性能优化实践——ui篇(代码片段)

...越好。这篇集中整理了deer在UI流畅上的优化细节，以实践为主，源码为辅。分享出来，希望对你有所启发和帮助。既然要优化，那么首先就要掌握定位问题、分析性能问题的方法，这样才可以对比优化前后的... 查看详情

高并发服务优化篇：从rpc预热转发看服务端性能调优(代码片段)

...群” ，拉你进程序员交流群????????作者丨Coder的技术之路来源丨Coder的技术之路Part1RPC为了性能做了哪些努力1.1Provider分组和直连路由寻址，负载均衡是很好，可以保证流量均匀从而保护服务节点稳定。但是，我们... 查看详情

ja17-大型电商分布式系统应用实践+性能优化+分布式应用架构+负载均衡+高并发设计+持久化存储视频教程

JA17-大型电商分布式系统应用实践+性能优化+分布式应用架构+负载均衡+高并发设计+持久化存储视频教程新年伊始，学习要趁早，点滴记录，学习就是进步!不要到处找了，抓紧提升自己。对于学习有困难不知道如何提升自己可以... 查看详情

网站优化之路---图片优化，图片从模糊到清晰(代码片段)

前言作为一个有追求有信仰的程序员，做一个网站绝不是仅仅能用就行了，当我们实现功能后，或者在写代码的过程中就要考虑怎么去优化，一个网站要去优化，作为前端要考虑的是资源优化（减少http请求啊，固定图片压缩啊... 查看详情

转web程序优化的最佳实践：javascript和css篇

...并在各种会议上参与探讨。最佳实践的核心就是旨在提高网站性能。ExcetionalPerformance团队总结出了一系列可以提高网站速度的方法。可以分为7大类34条。包括内容、服务器、cookie、CSS、JavaScript、图片、移动应用等 查看详情

vue项目性能优化—实践指南（网上最全）(代码片段)

copyfrom:https://github.com/fengshi123/blog/issues/13Vue框架通过数据双向绑定和虚拟DOM技术，帮我们处理了前端开发中最脏最累的DOM操作部分，我们不再需要去考虑如何操作DOM以及如何最高效地操作DOM；但Vue项目中仍然存在项目... 查看详情

sparksql优化之路——hive篇(代码片段)

文章目录前言优化方向数据存储结构优化分区设计分桶设计数据压缩存储格式数据生产者应注意的事项优化场景个别Task运行缓慢源端数据倾斜处理过程中的数据倾斜不合理的哈系分布大小表JoinTask数量多源数据小文件多写入时小... 查看详情

性能优化篇）(代码片段)

...。还是编辑好让朋友发的。今天来更新一下第二章，性能优化篇。想看之前的可以看看辞职-旅游-疫情-闭关-复习-大厂offer（第一章）整个复习稿分为如下几大部分：1.Android基础篇2.性能优化篇3.Framework篇4.compose篇5.... 查看详情

前端性能优化之路——图片篇。

...学一起学习交流一下，话不多说，就来分享我的性能优化之路，有什么不对的知识点，麻烦大家指出批评。yahoo军规把大部分的前端优化都提到了，而在js优化这一块如果有兴趣的额，推荐大家去看《高性能javascript》,书里讲的非... 查看详情

kafkakafka生产问题总结及性能优化实践(代码片段)

Kafka可视化管理工具kafka-manager安装及基本使用可参考：https://www.cnblogs.com/dadonggg/p/8205302.html线上环境规划（参考）注意：对于单机抗高并发（上万）的机器，一定要上大内存JVM参数设置kafka是scala语言开... 查看详情

kafkakafka生产问题总结及性能优化实践(代码片段)

Kafka可视化管理工具kafka-manager安装及基本使用可参考：https://www.cnblogs.com/dadonggg/p/8205302.html线上环境规划（参考）注意：对于单机抗高并发（上万）的机器，一定要上大内存JVM参数设置kafka是scala语言开... 查看详情

这个夏天，走向前端性能优化之路(代码片段)

优化其实是一件很有趣的事。。　　以我的项目为例，dist文件从20M到2M...一.使用工具查看项目各个包的大小　首先你需要先安装webpack的一个插件webpack-bundle-analyzer，专门用来分析各个包的依赖，查看包的体积。npmintallwebpack-bundle... 查看详情

「offer来了」快来关注这些性能优化问题(代码片段)

...能优化问题。6、如果一个页面上有大量的图片（大型电商网站），网页加载很慢，可以用哪些方法优化这些图片的加载，从而提升用户体验？7、如何对网站的文件进行优化？8、请说出几种缩短页面加... 查看详情