Souledge

 project options for firemonkey

每天陷于工作和生活的琐事中，很少有时间打磨这套开源库，加上个人能力实在有限，实在抱歉。 要是有好的改进思路，欢迎提交代码，也可以造福其他使用者，感谢。 发自我的iPhone 在 2021年11月6日，20:05，PassByYou888 ***@***.***> 写道：  1，EPOLL与KQUEUE模型，发送数据块时，在锁定中触发状态事件，在该事件中如果继续调用send方法，发生卡死，应该解锁后来触发，这种问题不易于发现，也不好调试，我刚检查过最后更新代码 2，运营时的问题，socket要给出最大连接限制，例如2万，超过以后连接请求要全部reject 3，一个建议，fpc带上jemalloc/tcmalloc跑服务器是优于d的，希望多关注fpc，少关注设计模式 by.qq600585 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view...

实际上现在是在处理完请求之后就自动调用了Reset了，所以应该不会出现你说的请求响应之后还占用Post的内存， 你可以看看 ParseRecvData 这个方法里有着一段 ` // 处理请求 if (LRequest.FParseState = psDone) then begin DoOnRequest(LHttpConnection); LRequest.Reset; LResponse.Reset; end; `

目前的 SendFile 是可以支持分块压缩发送的，如果改用 TransmitFile，那就无法分块压缩，而且改造起来也颇费时间 我觉得你应该换个思路，你的目的是为了提高发送文件的效率，即便改用 TransmitFile，也只是减少了“用户/内核模式”的切换，TransmitFile 也还是需要从磁盘去读取数据，内存的读写速度远高于磁盘，更高效的方式是实现一个文件缓存的机制，常用的直接从内存中读取发送，这一定比 TransmitFile 效率更高，而且更通用，各平台通吃，还支持分块压缩 不过我暂时实在没啥时间去做这件事，你要是有兴趣的话可以尝试修改，我可以把你修改的代码合并

对于很大的文件，的确不适合放到内存中，这种情况使用 TransmitFile 的效率提升应该很可观 由于 SendFile 每次都会重新打开文件，所以 TBufferedStream 其实并不适用

我这套库，就在我们公司的生产环境中运行，用于编写后台的 REST 接口，发送文件也就是库里面的 SendFile，并没有觉得效率不够用，可能我们的应用场景还没有出现需要频繁发送文件的情况吧，所以并没有针对性的做特别优化 如果你有兴趣，欢迎进行改进

就是直接使用 Net.CrossHttpServer.pas 单元呀，使用 ICrossHttpServer.Get Put Post Delete 生成各种 REST 接口的应答 你如果要做改进的话，直接修改 TCrossHttpResponse.SendFile 即可

EPOLLONESHOT can guarantee that there will never be two threads simultaneously trigger _HandleRead

已更新

很好的建议，不过相关的修改需要耗费不少精力，现在暂时没有这么大块的时间。 不过你如果有时间帮忙按你建议这几条完善这套库的话，欢迎之至 :)