当portal设置为PRO的时候页面加载缓慢，设置成其他的值就没问题

[xiakedong]

• 我已经检查过discussions
• 我已经搜索过issues
• 我已经仔细检查过FAQ

描述bug

简洁明了地描述一下bug
我把这个ENVS设置成非PRO的时候速度很快，我设置成其他的值并且从新部署会很快，反复实验了多次，其他条件都是一样的 只有找个ENVS的值不一样，造成 了两种不同的结果
复现

通过如下步骤可以复现：

1. 设置成非PRO观察加载速度
2. 设置成PRO观察加载速度

期望

简介明了地描述你希望正常情况下应该发生什么

截图

如果可以，附上截图来描述你的问题

额外的细节和日志

• 版本：
• 错误日志
• 配置：
• 平台和操作系统

[xiakedong]

再次强调下，除了envs的值不一样，其他条件完全一致。 设置成PRO和prod的时候会加载很慢。我看代码逻辑是吧prod转换为pro的 所以请问下对PRO是有特殊处理方式吗

[github-actions]

🤖 感谢反馈。为便于维护者快速定位，请补充以下最小信息：

1. Apollo 版本号或 commit
2. 部署与运行环境（JDK 版本、操作系统、MySQL/H2、部署模式）
3. portal 配置（特别是 apollo.portal.envs 的完整配置）
4. 相关错误日志（portal 后台日志，浏览器控制台 Network 和 Console 面板的慢请求信息）
5. 数据规模（PRO 环境有多少个应用、配置项数量）

PRO 环境加载慢可能与数据量、数据库性能、网络连接等因素有关。收到补充信息后维护者可以更快跟进。

AI generated by Apollo Issue Triage

[xiakedong]

Apollo 版本号：2.5.0
部署与运行环境： helm 部署 K8S1.33 集群内
portal 配置
name: apollo-portal
fullNameOverride: ""
replicaCount: 1
containerPort: 8070
image:
repository: apolloconfig/apollo-portal
tag: "2.5.0"
pullPolicy: IfNotPresent
imagePullSecrets: []
service:
fullNameOverride: ""
annotations: {}
port: 8070
targetPort: 8070
type: ClusterIP
sessionAffinity: ClientIP
ingress:
ingressClassName: null
enabled: false
annotations: {}
hosts:
- host: ""
paths: []
tls: []
liveness:
initialDelaySeconds: 100
periodSeconds: 10
readiness:
initialDelaySeconds: 30
periodSeconds: 5

environment variables passed to the container, e.g. JAVA_OPTS

env:
JAVA_OPTS: "-Dapi.connectTimeout=3000 -Dapi.readTimeout=30000"
strategy: {}
resources: {}
nodeSelector: {}
tolerations: []
affinity: {}
annotations: {}

config:

spring profiles to activate

profiles: "github,ldap"

specify the env names, e.g. dev,pro

envs: PRO

specify the meta servers, e.g.

dev: http://apollo-configservice-dev:8080

pro: http://apollo-configservice-pro:8080

metaServers:
pro: http://apollo-service-old-apollo-configservice:8080

uat: http://br-apollo-config-service-stage.gwmcloud.com

specify the context path, e.g. /apollo

contextPath: ""

extra config files for apollo-portal, e.g. application-ldap.yml

files:
application-ldap.yml: |
spring:
ldap:
base: "DC=gwm,DC=com"
username: "CN=globalops_sso,OU=Apollo,OU=role,OU=administrator,DC=gwm,DC=com"
password: "ybfU6w*N30Vel3fB"
searchFilter: "(sAMAccountName={0})"
urls:
- "ldap://172.17.64.10:389"
ldap:
mapping:
objectClass: "person"
loginId: "sAMAccountName"
userDisplayName: "cn"
email: "mail"

portaldb:
name: apollo-portaldb

apolloportaldb host

host: 10.60.***
port: 3306
dbName: apolloportaldb_new

apolloportaldb user name

userName: root

apolloportaldb password

password: YK!Pro@******
connectionStringProperties: characterEncoding=utf8&useSSL=false
service:
# whether to create a Service for this host or not
enabled: false
fullNameOverride: ""
port: 3306
type: ClusterIP
相关错误日志（portal 后台日志，浏览器控制台 Network 和 Console 面板的慢请求信息）
非PRO

设置成PRO

数据规模（PRO 环境有多少个应用、配置项数量）

[xiakedong]

以上问题为同一个环境，所有条件都一样 都是单一环境。只有ENVS的值不一样，PRO和其他的页面加载速度差距很大

[xiakedong]

只要是配置成PRO页面就加载很慢， 设置成FAT\DEV\UAT\或者其他任意值加载速度就很快。 以上操作都是统一环境下操作 架构体系为同一套，反复重新部署发现该问题

[nobodyiam]

暂未本地复现到你环境里的实际时延，但从代码看，PRO 本身没有单独的 meta server 特殊逻辑；如果 configView.memberOnly.envs 包含 pro，那么 PRO/prod 会触发额外的成员权限校验，所以页面只在 PRO 变慢是有代码依据的。

原因是：Portal 会把 prod/PROD 归一化成 PRO。命中 configView.memberOnly.envs 后，读取 namespace 配置、发布历史、分支信息等接口前，都会先走 shouldHideConfigToCurrentUser(...)。这一步不是简单判断，还会继续检查当前用户是否是 app admin，或者是否有该 namespace 的 modify/release 权限。

当前实现里这类权限检查会查 PortalDB 的 Permission、UserRole、RolePermission 等表，而且没有 request 级缓存。namespace 多时，这部分查询会被放大，所以页面体感会明显变慢。

所以这里更像是：开启 configView.memberOnly.envs 后，PRO 多了一层权限校验成本，而不是 PRO 走了另一套特殊环境逻辑。

建议先临时把 configView.memberOnly.envs 里的 pro 去掉再对比一次；如果恢复正常，基本就能确认瓶颈在这条 member-only 权限校验链路。

补充一下，相关代码可以参考：apollo-portal/src/main/java/com/ctrip/framework/apollo/portal/component/UserPermissionValidator.java、apollo-portal/src/main/java/com/ctrip/framework/apollo/portal/component/config/PortalConfig.java。

另外，你在评论里贴出了 LDAP 凭据，建议尽快轮换并编辑删除敏感信息。