.NET 大对象堆和 JSON 交互
我有一个 asp.net 应用程序，它使用 JSON 将数据序列化到客户端。 一旦负载达到一定水平，应用程序就会在 GC 中花费过多的时间，并且在使用 WinDbg/SOS 和相关工具一段时间后，由于生成的 JSON 的大小，似乎会发生大量的 LOH 碎片通常大到足以超过 LOH 的 86K 边界。
我的问题2折 1) 是否有人运行过这种影响并导致 LOH 碎片的 JSON 生成特定场景？ 2）有人对如何处理有什么建议吗？
I have an asp.net application that serializes data to the client using JSON. Once load reaches a certain level, the app is spending an in-ordinate time in GC and after spending some time with WinDbg/SOS and related tools it appears that there is a substantial amount of LOH fragmentation taking place because the size of the generated JSON is frequently large enough to exceed the 86K boundary of the LOH.
My question 2 fold
1) Has anybody run this specific scenario of JSON generation impacting and causing LOH fragmentation and
2) Does anybody have any suggestions on how to handle it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您正在生成大量> 无论如何，85K 字符串在性能方面都是有问题的。
您是否需要在将数据发送给客户端之前完整生成数据？ 如果您的 JSON 库支持将数据写入 Stream/TextWriter 并且客户端响应 api 支持它，我将简单地将一个链接到另一个，完全解决问题。
如果你不能做到这一点，你可能不得不求助于对象池，这不适用于字符串，你将不得不求助于 char[] 或 byte[] （MemoryStream 将使这变得容易）并重用后备数组。 也许每个线程一个就足够了。 您可能需要处理这样的情况：不常见的大规模响应导致底层数组膨胀，然后保留下来。
If you are generating a large number of > 85K strings then that's problematic performance wise anyway.
Do you have a need to generate the data fully before sending it to the client? If your JSON library supports writing the data to a Stream/TextWriter and the client response api supports it I would simply chain one to the other entirely side stepping the problem.
If you can't do this you may have to resort to object pooling, which won't work on strings and you will have to resort to char[] or byte[] (A MemoryStream will make this easy) and reuse the backing array. Probably one per thread is sufficient. You may want to deal with the cases where by an uncommon massive response causes the underlying array to balloon and then be kept around.