性能是优化出来的，不管是在上生产前，还是在上生产后。大部分性能在性能测试阶段就能发现问题，但也有一些性能问题，结合生产的环境，生产数据才能表现出来，成为一个显著的瓶颈。
这次是生成pdf造成的内存泄露，大体代码如下，具体表现是内存缓慢增长，在docker中比windows增长速度要快，但都有只增不回收的特点。
using System.Data;using System.Reflection.Metadata;using QuestPDF.Helpers;using QuestPDF.Infrastructure;using QuestPDF.Fluent;using QRCoder;using Microsoft.AspNetCore.Mvc;using QuestPDF.Drawing;using QuestPDF;var builder = WebApplication.CreateBuilder(args);var app = builder.Build();app.MapGet(“/getpdf”, () =>{var table = new DataTable();for (var i = 0; i {using var stream = File.OpenRead(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, “fonts”, “MEIRYO.TTC”));FontManager.RegisterFont(stream);Settings.EnableCaching = true;Settings.EnableDebugging = false;container.Page(page =>{page.Size(PageSizes.A4);page.Margin(2, Unit.Centimetre);page.PageColor(Colors.White);page.DefaultTextStyle(x => x.FontSize(14).FontFamily(“Meiryo”));page.Content().PaddingVertical(1, Unit.Centimetre).Column(x =>{x.Item().Table(table =>{table.ColumnsDefinition(columns =>{for (var i = 0; i {foreach (DataColumn col in dt.Columns){header.Cell().Element(CellStyle).Text(col.ColumnName);}});foreach (DataRow row in dt.Rows){for (var i = 0; i {x.Span(“Page “);x.CurrentPageNumber();x.Span(“/ “);x.TotalPages();});});});return doc.GeneratePdf();}
各种.net的调试工具用上，都只能证明内存只增不减，连pmap都用上了，发现下面的一个大文件的内存占用，并且很多，大体都是在65M左右。
Address Kbytes RSS Dirty ModeMapping00007f4d54000000 65536 65536 65536 rw— [ anon ]
经过一天的测试，找不到具体的问，最后推测是生成Pdf后，生成的内存是非托管内存，GC回收不掉，每当有用户下载PDF时，就会积累内存，直到Pod崩掉。
干不掉bug，就干掉需求吧，因为经过统计这个下载pdf的使用量很低，可以下掉功能。同时把这个问题给QuestPDF提了个issues。就准备躺平。QuestPDF回应很快，说注册字体只用注册一次就行，多次注册会重复累加字体，37到40行代码，只在服务启动时加载一次即可，经过测试果然有效果。
在复盘时，总结，常规的思维在win下注册字体，多次注册不会让相同的字体保存多份，从而认知QuestPDF注册也是同理，造成下载一次就注册一次，造成内存积加，这也是为什么65M左右的内存一起在累加的原因。
后来，我又思考了一下，如果做一个支持高并发，高性能的web服务，像下载Excel，PDF这些操作，是不能在后台生成的，因为用户的一个文件的体积和用户的数据是有关系的，大小很难控件，如果耦合在web服务端来做这件事，肯定是个“雷”。也有的建议是用其他服务或cli异步生成，然后放在云存储上让用户下载，这也是一种解决方案。
我觉还是让web服务做自己擅长的事，提供数据，把文件生成组装操作转嫁给客户的浏览器来完成，这样既能减轻web服务的负载，又能充分利用客户端的资源，一举两得。
