ScubaGear项目中Defender导出模块的性能优化实践

背景与问题发现

在ScubaGear项目的Defender导出模块中，开发团队最近发现当租户规模较大时（例如超过2万用户），模块执行时间显著增加。经过代码审查，发现问题出在用户审计功能检查的实现逻辑上。

技术问题分析

原代码通过调用Get-MgBetaUser API获取未启用高级审计功能的用户数量，但实际实现中存在两个关键问题：

1. 数据过量下载：虽然只需要用户计数结果，但API会返回所有匹配用户的完整数据集。测试显示每个用户记录约24KB，2万用户意味着近500MB的数据传输。

2. 对象创建开销：PowerShell会为每个返回的用户创建包含128个属性的对象，消耗大量内存和处理时间。

测试数据显示，在2041个用户的测试租户中，原查询耗时约10.76秒，这在大型租户环境中将造成明显的性能瓶颈。

解决方案设计

优化方案基于以下技术原理：

1. Graph API的高级查询功能：利用$count和$top参数组合，实现只返回计数结果而不获取完整数据集。

2. 一致性级别设置：通过ConsistencyLevel=eventual头确保计数结果的准确性。

具体实现修改为：

• 将All=$true参数替换为Top=1
• 保持原有的过滤条件和计数功能

优化效果验证

在相同测试环境中：

• 优化后查询时间降至0.65秒
• 数据传输量减少99%以上
• 内存消耗显著降低
• 计数结果准确性保持不变

技术实现细节

在底层实现上，优化后的查询相当于在Graph API中执行：

GET /users?$filter=not assignedPlans/any(...)&$count=true&$top=1
Headers: ConsistencyLevel=eventual

API响应中包含@odata.count字段提供准确计数，而响应体只包含一个示例用户记录，大幅减少了网络传输和数据处理开销。

经验总结

1. API使用最佳实践：在使用Graph API时，应仔细评估实际需求，避免获取不必要的数据。

2. 性能优化思路：对于计数类操作，优先考虑专用计数功能而非获取完整数据集。

3. 大规模租户考量：安全工具开发中需特别关注大规模环境下的性能表现，避免线性增长的资源消耗。

这一优化不仅解决了当前性能问题，也为ScubaGear项目处理大型租户场景提供了有价值的参考模式。