Edge 控制的文件传输
Axeda Agent/平台启动的文件上传
如图所示，
• 在步骤 2 中，将执行以下输入验证。
◦ 如果作业受 Edge 控制，请验证是否超出了最大并发传输数量和每个事物的最大并发传输数量。
◦ 如果未超出，作业将排队等待稍后传输。否则，复制失败，作业不会加入队列。
• 在输出期间，于步骤 5 中：
◦ 确定是否存在任何要执行的下载、上传、SCM 操作或远程属性写入操作。
◦ 仅当未超出传输限制时，才能启动文件传输。
• 在步骤 8 中创建或写入二进制文件时，文件将被锁定以便进行写入操作。如果这是最后一个数据块且提供了校验和，则系统会对其进行验证。
• 将作业标记为失败或已完成。此外，如果提供了校验和，还需对校验和进行验证。
ThingWorx Platform 启动的文件下载
如图所示，
• 在文件复制期间，将于步骤 1 中执行以下输入验证。
◦ 如果作业受 Edge 控制，请验证是否超出了最大并发传输数量和每个事物的最大并发传输数量。
◦ 如果未超出，作业将排队等待稍后传输，否则复制失败，作业不会加入队列。
• 在输出 (即步骤 4) 期间，
◦ 确定是否存在任何要执行的下载、上传、SCM 操作或远程属性写入操作。
◦ 仅当未超出传输限制时，才能启动文件传输。
• 在创建或写入二进制文件 (即步骤 7) 期间，文件将被锁定以便进行写入操作。
• 平台会将作业相应标记为失败或已完成。
重要的可调参数
• 必须仔细调整文件传输子系统上的配置设置，以获得理想的文件传输并发度。下面列出了部分设置。有关详细信息，请参阅文件传输子系统
◦ 整个平台的边缘控制文件传输最大数目 → 平台中用于取消排队作业并将作业移至活动队列的最大并行文件传输数目。如果需要更高的平行度，必须调大该值。
◦ 单个事物的边缘控制文件传输最大数目 → 平台中用于取消排队作业并将作业移至活动队列的单个事物的最大并行文件传输数目。如果事物数量较少，但每个事物要传输的文件数量较多，则增大此值可能会大有助益。
 | 增大此值可能导致可用位置与设备间的最大并行文件传输数目分布不均匀。 |
◦ 离线队列允许的文件传输最大数目 → 如果文件传输上传速率很高但处理速度相对较慢，则必须调大该值，以便作业保持离线状态，免遭拒绝。
◦ 离线队列中每个事物允许的文件传输最大数目 → 如果每个事物的文件传输上传速率很高但处理速度相对较慢，则必须调大该值。随后，作业将保持离线状态，进而免遭拒绝。
• Edge 控制的文件传输需借助 WSExecutionProcessor 线程池执行。因此，必须有足够的线程才能执行文件传输。可使用 WSExecutionProcessingSubsystem 中的“执行处理器设置”调整此线程池。详细信息请参阅 WebSocket 执行处理子系统。
• 有关调节 eMessage 连接器的详细信息，请参阅微调 eMessage 连接器。
最佳做法
• ThingWorx Platform 支持在文件信息库中同时读写文件。为防止数据损坏并确保一致性，Platform 必须获取读取/写入操作期间文件和目录的锁定状态。避免写入同一目录或同时写入多个文件，可提高并发度，并增加文件操作的吞吐量。
• 传输大量文件时，文件 input/ouput 必须能够处理并发读/写操作，且必须放置在除 /ThingworxPlatform 外的单独存储位置。
• 连续监控文件传输性能。请参阅文件指标文档。
• 应用程序开发人员应意识到 ThingWorx 订阅与文件传输操作之间的关系，因为有些服务执行涉及与文件传输事件完成相关的大量输入/输出，此类执行将利用特定于快速运行操作的有限 TWEventProcessor 线程。相应调整 TWEventProcessor 线程池设置并确保基础设施性能，以免其他订阅的执行性能受到影响。