本地主机缓存大小和伸缩
在XenApp和XenDesktop 7.12中引入了本地主机缓存，取代了XenDesktop 7.6中的连接租赁特性。本地主机缓存涵盖了比连接租赁更多的场景，但需要不同的设计考虑。
- 本地主机缓存支持比连接租赁更多的用例。
- 当操作时，本地主机缓存需要更多的资源（CPU和内存）而不是连接租赁。
- 在中断模式下，每个区域只有一个代理处理VDA注册和代理会话。
- 选举过程决定中断期间将有效的经纪人，但不考虑经纪人资源。
- 如果区域中的任何单个代理能够在正常操作期间无法处理所有登录，则在中断模式下它将很好地运行。
- 中断模式下不提供网站管理。
- 高度可用的SQL Server仍然是推荐的设计。
- 对于间歇性的数据库连接场景，最好隔离SQL Server并让站点处于停机模式，直到所有底层问题得到解决。
- 每个区域有5,000个VDA（未实施）。
- 没有14天的限制。
- 在默认配置中，在停机模式下不支持池式桌面。
体系结构
在XenDesktop 7.6中引入了连接租赁，允许在站点数据库中断期间继续访问资源。它不支持VDI池化桌面，默认情况下，用户必须在过去14天内连接到某个资源。进一步的限制是，它将尝试将用户连接到他们在正常操作期间连接到的最后一个桌面或应用程序主机。如果此选项不可用，则不会代理连接。
这两种技术（连接租赁和本地主机缓存）的架构非常不同，并且它们需要不同的资源来运行。连接租赁创建各个XML租赁文件，这可能需要几个GB的磁盘空间，具体取决于站点中的资源数量。本地主机缓存使用本地SQL Server数据库，并且在磁盘空间使用中更有效，但是确实需要比连接租赁更多的内存和CPU。两者都有同步的阶段，其中来自主站点数据库的详细信息同步到经纪人（控制器）。由于文件系统上创建的单个文件编号，连接租赁初始同步可能导致相当大的IOP。虽然本地主机缓存使用仍需要IOPS的SQL数据库，但它具有SQL优化这些写入的优势。
在具有多个经纪人的连接租赁设置中，每个代理都有XML租赁的副本，并且在中断期间能够经纪人连接，帮助平衡负载。但是，对于本地主机缓存，单个代理被选为代理所有连接并处理VDA注册。本网站中的所有VDA都将重新注册此单个代理，因此，与正常运行中的多个代理站点相比，该经纪人将对资源进行更高的需求，特别是在具有大量VDA的站点。
本地主机缓存使用Microsoft LocalDB，它在任务管理器中显示为SQLServer.exe进程。它已配置为为数据库缓冲池缓存使用高达1 GB的内存。但是，随着SQL引擎为自己的存储器和其他较小的缓存需要存储器，该过程将超出此类。通常，中断模式访问的中断和资源越长，即localDB内存使用就越多。但是，当恢复站点数据库连接时，SQLServer.exe将保持此内存，并不会立即将其返回到主池。
CPU插座和核心在中断模式下的影响
在以前的XenApp和XenDesktop的版本中，管理员并不一定与经纪人（控制器）机器的CPU配置关注自己：在物理或虚拟机中的套接字和核心数的布局。
本地主机缓存使用名为localDB的SQL Server的运行时版本，该SQL Server具有将其限制为四个核或单个套接字的较小的许可。当物理或虚拟机配置有多个套接字时，这可以具有显着的性能效果，只有单个套接字，只有单个或双核。具有4个套接字的经纪人和每个插座的一个核心将限制LotelodDB以使用单个核心，而配置为1个套接字4核心机器的相同VM意味着LocalDB可以访问所有4个核心（尽管使用其他进程共享它们）。在中断模式下，LocalDB将在正常操作期间运行相同的代理和SQL代码。许多SQL查询可以是CPU密集型，并对中断模式的闯入性能直接影响。
其他因素包括网站配置本身：
- 已发布的应用程序数量
- 被斡旋的用户数量
- 用户试图启动会话的费率
- Active Directory性能
随着总代理CPU利用率接近100％，经纪响应时间将增加，登录将需要更长的时间来处理，并且某些登录尝试可能会失败。
具有多个经纪人的网站
在站点中断模式期间，只有单个代理处理注册和登录请求。在多个代理站点中，发生选举过程以提名在中断期间将处于活动的经纪人。但是，这一选举过程不考虑经纪人可用的物理资源。This means that in a site where brokers have different amounts of resources, the elected broker will not necessarily be the most powerful in terms of CPU or RAM, which could potentially lead to poor performance during outage mode.It is important that each broker meets the additional requirements of Local Host Cache, in case it is elected.
与站点数据库同步
CitrixConfigSync服务处理将数据从站点数据库导入到代理上的本地副本。它监视站点数据库以查看站点配置的更改，并在发生更改时触发新的导入。在导入开始之前生成当前本地数据库的副本。站点内的资源(如VDAs)越多，导入时间越长，但VDAs为5000的站点导入时间应小于10分钟。
数据库位置
本地数据库存储在：
C：\ Windows \ ServiceProfiles \ networkservice \ hadatabasename.mdf
为确保可靠性，CitrixConfigsync服务在启动新站点数据库同步之前，请备份先前成功的同步数据库导入。如果由于任何原因同步未成功，则使用备份直到成功的同步完成。您不应该手动复制数据库。
与连接租赁的本地主机缓存的比较
| 连接租赁 | 本地主机缓存 | |
|---|---|---|
| 磁盘空间 | 建议2 GB | 取决于站点配置。对于具有125 K用户的50个RDS主机，使用300 MB。 |
| 内存 | 100 MB | 3gb， ~1GB用于SQL Server, 2gb用于高可用性服务和CitrixConfigSync服务。 |
| 时间同步配置 | IOPS依赖;40000年的共识:~ 26分钟 | 5,000 VDAs：〜7分钟 |
| 在中断期间激活的时间 | 150秒，30秒默认SQL超时+ 120秒等待时间(可配置) | 取决于VDA的数量和与代理的最后一个注册同步。在中断模式下，只有单个代理可用于VDA注册，因此对于大量VDA，可以在所有VDA都注册之前几分钟。 |
| 是时候恢复正常操作 | 租赁到停用120秒，然后VDA必须用经纪人重新注册 | 如上所述，VDA需要从次级经纪人注册并重新注册主要经纪人。 |
| 支持的vda个数 | 50，000 | 5,000。一个网站可以有多个，但同步站点数据库所需的时间将随着VDA的数量而增长。具有大量VDA的单个代理的性能可能导致某些连接在中断期间没有经过斡旋。 |
| 中断期间的网站管理 | 不 | 不 |
配置localDB内存限制
对于缓存，LocalDB过程限制为1 GB的RAM，通常不需要改变。如果需要，可以更改此值;为了使更改生效，网站必须处于正常操作（而不是中断模式），并且必须强制站点数据库同步。
将内存减少到768 MB：
第1步。编辑文件c：\ program files \ citrix \ broker \ service \ highavailabilityservice.exe.config。
寻找
<添加键=“maxservermemoryinmb”值=“768”/>
第2步。要强制数据库同步，请停止高可用性服务。如果sqlserver.exe正在运行，请使用任务管理器或PowerShell停止它。
第3步。现在对网站进行琐碎的变化，例如通过添加“。”来改变传递组的描述，然后再次删除它。然后，启动高可用性服务;应该启动SQLSERVER.EXE和一个同步。
减少内存过多会影响性能，并不建议。但是，将其增加到2 GB不会显着提高性能，并且CPU资源的瓶颈比RAM更多。
启用或禁用本地主机缓存
连接租赁和本地主机缓存都可以禁用，但只有其中一个可以一次激活。
set-brokersite -connectionLeasingEnabled $ false
set-brokersite -localhostcacheenabled $ true
限制
必须在中断模式下使用之前分配桌面。未分配的桌面将无法进行经纪人。如果在所有分配在所有分配在所有分配都发生在所有分配之前，这可能导致桌面不可用并在维护模式中报告“维护模式”，尽管实际分配了桌面。
在默认配置中，在停机模式下不支持池式桌面。有一个解决方案，但它有潜在的安全性和性能影响。如果将包含合用桌面的交付组配置为下线时不重新启动，则该组中的任何开机的合用桌面将在停机模式下可用。但是，当用户注销后，由于桌面没有重新启动，桌面不会处于干净状态。在任何场景中，这都可能是一个安全问题。如果该桌面的下一个用户是该桌面的本地管理员，则可以访问前一个用户的数据。尽管对于标准(非管理员)用户来说，这种风险不太值得关注，但请记住，应用程序可能会行为不当，并随着时间的推移导致性能问题。重要的：管理员应仔细考虑使用此解决方法使用中断模式下的非重新启动池桌面的潜在影响。
与连接租赁一样，在中断期间不能更改站点;该数据库实际上是主站点数据库的快照，每次发生新的同步时都会丢弃该数据库。
压力条件下6和8 vCPU代理的性能比较
网站配置了50名RDS工人和5075 VDI VDA。每个RDS工作人员都能够支持2500个模拟用户。设置了每秒20个用户的发射速率。在网站上添加了不同数量的已发布的应用程序。
对于RDS工作人员，为VDI 5075启动了100,000名用户。
在正常和本地主机缓存运行（中断）模式下进行测试。
在6个VCPU系统中，CPU余量很少，并且当发布的应用程序数为0时发生少量异常（<10）。
按组策略禁用Windows更新，因为在多个运行期间，发现Tiworker.exe进程（Windows Installer模块）被发现在延长的时间段内使用几乎整个核心。这导致了大量的发射失败，因此测试重新运行。经纪人处理器非常陈旧，但TiWorker进程将消耗一个较新的核心，影响测试。
虚拟机管理程序配置
- XenServer 7.0
- AMD Opteron 8431 2.4 GHz - 4x6核心
- 128 GB RAM.
- 读取启用缓存
- Windows Storage Server 2012R2基于SSD的存储器
经纪人配置
- 2个插座，带3个芯和2个带4个核心的插座
- 10 GB RAM
- Windows Server 2016.
- 每个VDA类型的单个递送组
- 所有应用程序对用户可见
- XenDesktop 7.12.
店面的配置
- 6店面服务器
- Windows Server 2016.
- 4 VCPU.
- 10 GB RAM
NetScaler配置
- VPX 8000版本11.063.16
SQL Server配置
- 英特尔E5-2630 2.3GHz 2x12核心
- SQL Server 2012.
- 64 GB RAM.
笔记：只有站点数据库脱机;在测试期间仍可访问监控和配置数据库。这意味着监视器服务在测试期间消耗了一些CPU。
通常，随着应用程序的数量增加，登录响应时间增加和中断响应时间比正常操作更差。增加VCPU的数量改善了响应时间。请记住测试中使用的CPU是相当古老的，更多的现代CPU通常会提供更好的表现。
“理论分钟”行是100,000用户将要登录的绝对最短时间，如果环境能够每秒推出20个，请给出1小时23分20秒。在这些测试中，0应用程序行在6个VCPU案例中管理1:30:57，在8个VCPU案例中1:30:48。Active Directory域的性能将对用户经过身份验证的速度产生一些影响。
在正常条件下，在操作期间，LocalDB内存使用将增加，除非系统有压力，否则除非有压力;处理的用户越多，使用的内存越大，1 GB的限制。在第一个VDI测试中，LocalDB没有从之前的RDS运行中释放内存。对于后续VDI测试，在测试之前重新启动代理并使用更少的内存。
笔记：值已被标准化为全系统CPU，因此33.33％是六个核中的两个，30％是8 VCPU设置上的2-1 / 2核。
术语“关”是指正常的现场运作;“开”表示本地主机缓存是活动的。
即使在正常运行下，经纪人也需要每秒20个用户的请求发射率。在正常操作下，6个VCPU系统没有净空;随着已发布应用程序的数量增加，代理CPU增加，导致响应时间较慢。当本地主机缓存处于活动状态时，辅助代理（HA）服务必须与CPU资源的LocalDB（SQL）进行竞争，从而给出比正常操作更差的响应时间。
在8个VCPU系统中，有一些余量，LotelodB将扩大，但在这种环境中，它在2-1 / 2核心达到峰值，尽管仍有少量CPU仍然可用。
在正常操作期间，LocalDB不会消耗CPU，除非发生同步。
在停机期间，主代理几乎不使用CPU。
数据库大小
对于5075 VDI配置，LocalDB大约为40 MB，对于100,000个RDS，根据应用程序和登录的数量，LocalDB的大小在100-300 MB之间。由于在新的导入开始之前获取了数据库的副本，因此允许为LocalDB提供1gb的空间。
概括
在站点数据库中断期间，Local Host Cache支持比连接租赁更广泛的资源和条件，但在操作时需要更多的CPU和内存。
在多个代理站点中，任何代理都可能被选为中断代理，因此所有代理都必须有足够的资源来应对中断模式。没有对代理资源进行评估，因此在具有较弱的和较强的代理的站点中，有可能在中断期间选出最弱的代理。
核心和插座的布局必须被视为经纪人设计的一部分。
已发布的应用程序的数量将对登录响应时间和最大登录吞吐量产生影响。
CPU资源不足的经纪商可能导致启动失败。
与连接租赁相比，额外的两个核和2 GB的RAM是在本地主机缓存中断模式下测试性能的良好起点。
LocalDB数据库的1 GB磁盘空间将足够。
重载的代理将导致连接失败。
这篇文章是由Joe Deller撰写的。