Overview
BIMLauncher cannot provide pipe performance guarantees as there are too many factors that affect performance - Both within and outside the control of BIMLauncher, that return non-linear and non-deterministic results - even between the same set of documents in the same system setup at different times.
Implementation decisions are a shared responsibility of the customer and will be advised by the BIMLauncher team for the best fit performance. The following guide provides a list of known factors to influence the BIMLauncher operations.
BIMLauncher System Overview
BIMLauncher keeps the target platform up to date based on documents in the source platform. In cycles, relevant documents are read, and in no particular order generate tasks to ensure that each exists on the target platform. Read operations produce tasks; write operations consume them.
BIMLauncher ensures that the state in the target is correct according to the state in the source. Performing the operations required for accurate and precise updates across platforms takes time.
Factors That affect performance
Factors that are known to affect the transfer speeds of the pipe from the Aconex Document Register to the ACC Files tool include:
Binary Size - The size of the binary impacts the time to merge a document.
Target Folder Size - Each document that is read from the source is checked for existence in the target folder. In ACC, folders are paginated to 200 files per request, and the operation can only proceed once it discovers (or not) the file in a given page. Therefore, the number of files in the target folder impacts the time to complete a write operation. The processing performance for each document can be observed to slow down as more files are added to the target. As a rule of thumb, more documents in a target folder mean more checks, while fewer documents mean fewer checks. Best practices to reduce time taken for each document to process include writing to a hierarchical / diversified folder structure to reduce the number of files in the folder, and therefore the number of documents that need to be checked for existence.
Source Size - The number of documents read from the source impacts the time to complete the cycle. Each read document needs to complete a write task. The time that it takes to write a document is affected by the number of documents read. A new document that meets the read conditions will be processed in the next cycle. It could be the case that the document becomes readable just after the cycle begins, and therefore, will be read as a part of the next cycle. Since there could be potentially thousands of readable documents available in a source, BIMLauncher performs an optimisation routine to limit the number of documents read as a means to counteract increasing times for transfer as a result as a large source. This optimisation means that only documents modified on that day are read. This optimisation can only be done when document changes in the source from the day before have already been processed. Resolving issues with documents is a shared responsibility between the customer and BIMLauncher.
Move Strategy - Use of a move strategy incorporated into the write operation will increase the time as previous versions need to be checked for existence.
Historical Versions - Inclusion of historical versions is known to affect the transfer time. On the first run, each version must be copied which affects the time to complete the initial sweep. During the continuous transfer, for each cycle, a check for existence for each version is performed. This is because earlier versions could point to different locations or have different document numbers.
Source Size (2) - The number of files to be read on the source is a factor, but is considered less impactful on the overall process time, as processing of files does not wait until the read completes. The write operations consume the majority of the time in a files operation and therefore overshadow the time to read a file from the source.
Platform API Responses - Platform API response times are known to vary. This may be because the platform servers are more busy than otherwise at the time of transfer.
Network Latency - This impacts the time each request takes to travel between platforms and BIMLauncher. Using the OSI model for context, BIMLauncher has a shared responsibility with AWS to work within the application layer (layer 7) only. Layers 1-6 (e.g. network, transport etc.) may also impact the transfer times.