A lightweight server intelligent scheduling method and system for heterogeneous BIM models

Abstract

This invention discloses an intelligent scheduling method and system for lightweight servers in heterogeneous BIM models. The method includes: constructing a data storage structure and designing engine information tables, server information tables, and task information tables; obtaining unit task memory consumption and server memory configuration information from the engine information tables and server information tables based on the engine identifier code; calculating the total number of server tasks and the number of successful lightweight tasks from the task information tables and calculating the lightweight success rate; and counting the number of tasks in processing from the cache structure; calculating memory usage, memory occupancy rate, and remaining computing power based on unit task memory consumption, server memory configuration, lightweight success rate, and the number of tasks in processing, and determining a weighted remaining computing power based on the lightweight success rate; and implementing server scheduling based on the calculated memory occupancy rate and weighted remaining computing power. Using this invention, model resource consumption and server remaining computing power can be dynamically matched, improving the average utilization rate of cluster memory.

Description

Technical Field

[0001] This invention relates to the fields of computer software and building information technology, specifically to an intelligent scheduling method and system for lightweight servers of heterogeneous BIM models. Background Technology

[0002] In the field of digital engineering, Building Information Modeling (BIM) models serve as data carriers throughout the entire lifecycle of a project. Through parametric modeling tools (such as Autodesk Revit and Bentley MicroStation), they integrate multi-dimensional data including geometry, materials, and schedule, covering information from multiple disciplines such as architecture, structure, and MEP. Heterogeneous BIM models refer to models generated by different vendors' software, with varying data formats and structures, such as Autodesk Revit's RVT format, Bentley MicroStation's DGN format, and the IFC format following open standards. These models require lightweight processing to reduce data complexity, adapting to scenarios such as cross-platform collaborative design, construction simulation, and operation and maintenance management. Lightweighting methods utilize engine tools to compress, convert formats, and optimize rendering of the models. For example, Bimface supports cloud conversion of RVT, DGN, and IFC formats and provides lightweight rendering on the web; Itwin achieves high-precision data lightweighting for DGN models; and Three.js, as an open-source WebGL engine, is compatible with .obj / .gltf formats and supports front-end interactive development.

[0003] As the hardware platform for running lightweight tools and systems, the server's resource scheduling mechanism must allocate computing resources based on the characteristics of the input BIM model. The core objective of server scheduling is to select the optimal node from the server cluster to execute the lightweight task based on parameters such as the model's memory requirements and format type. However, due to differences in data structure, component complexity, and lightweighting algorithms, heterogeneous BIM models exhibit significant differences in their consumption of server memory, CPU, and other resources during lightweighting. For example, the RVT model, due to its high parametric component complexity, requires 8GB of memory per task for a single lightweighting operation, while the DGN model only requires 2GB of memory per task.

[0004] In existing technologies, server scheduling generally adopts a static resource allocation strategy, which has the following technical bottlenecks: First, the fixed server grouping strategy cannot match the differentiated resource needs of heterogeneous models, resulting in a resource mismatch problem of "large models being stuck and small models being idle"; Second, there is a lack of an evaluation system for the server's ability to process specific format models. A server may have a low success rate in lightweighting RVT models due to engine compatibility issues, but it is still frequently assigned the same type of task, leading to an increase in the overall failure rate; Third, relying on periodic polling to obtain server status cannot respond to sudden task requests in real time, and when the server memory utilization rate is ≥95%, it is prone to system crashes or task timeouts.

[0005] Although BIM model creation tools (such as AutoCAD and ArcGIS), lightweight engines, and engineering applications (such as clash detection in the design phase and 4D progress simulation in the construction phase) have formed a mature ecosystem, the scheduling layer lacks a "data-driven + dynamic optimization" mechanism, making it difficult to meet the efficiency and reliability requirements of large-scale heterogeneous model processing. How to design a dynamically weighted intelligent scheduling scheme that takes into account the resource consumption characteristics of heterogeneous BIM models, historical server processing performance, and real-time load status has become a key technical issue in the current field of engineering digitization. Summary of the Invention

[0006] To address the technical bottlenecks in heterogeneous BIM model scheduling, such as inefficient resource allocation, lack of historical performance monitoring, and delayed real-time response, this invention aims to provide a lightweight server intelligent scheduling method and system for heterogeneous BIM models. This method achieves the following: recording resource consumption values ​​for different model formats under various engines through a database, enabling precise mapping between "model format - engine - resource requirements"; dynamically adjusting scheduling weights based on the lightweighting success rate of specific model formats over a past period, prioritizing reliable nodes; and utilizing high-speed caching to track concurrent task counts in real time, combined with memory usage thresholds to dynamically filter overloaded nodes, ensuring stable cluster operation.

[0007] To achieve the above technical objectives, the present invention provides a lightweight server intelligent scheduling method for heterogeneous BIM models, which includes the following steps:

[0008] 1) Construct the data storage structure, design the engine information table, server information table, task information table, and cache structure for storing task information during processing, and initialize the engine information table and server information table;

[0009] 2) Receive the model lightweighting request, extract and parse the model file, obtain the engine identification code corresponding to the model file from the engine information table, and enter it into the task information table along with the task name, task status and task generation time automatically generated by the system to generate the initial task record.

[0010] 3) Start the data acquisition process based on the engine identification code, obtain the unit task memory consumption and server memory configuration information from the engine information table and server information table, count the total number of server tasks and the number of successful lightweight tasks from the task information table and calculate the lightweight success rate, and count the number of tasks in processing from the cache structure.

[0011] 4) Based on the unit task memory consumption, server memory configuration, lightweight success rate and number of tasks in processing, calculate memory usage, memory occupancy rate and remaining computing power, and determine the weighting factor according to the lightweight success rate to obtain the weighted remaining computing power.

[0012] 5) Server scheduling is implemented based on the calculated memory occupancy rate and weighted remaining computing power.

[0013] Preferably, the engine information table includes the model file extension, engine identifier, and unit task memory consumption fields; the server information table includes the server primary key, engine identifier, total memory, reserved memory space value, service IP address, and service port fields; and the task information table includes the server primary key, engine identifier, task status, and task generation time fields.

[0014] Preferably, the data acquisition process based on the engine identifier code includes the following aspects:

[0015] 1) Based on the obtained engine identifier, the unit task memory consumption of the corresponding engine is obtained by querying the engine information table;

[0016] 2) Based on the obtained engine identifier, the server primary key and server memory configuration information supporting the engine are obtained by querying the server information table;

[0017] 3) Based on the obtained server primary key, retrieve the lightweight success rate of each server model by searching the task information table;

[0018] 4) Based on the obtained engine identifier and server primary key, the number of tasks currently being processed by the server is obtained by retrieving the cache structure.

[0019] Preferably, the weighted remaining computing power calculation includes the following aspects:

[0020] 1) Calculate the server memory usage based on the obtained unit task memory consumption, server reserved space, and number of tasks being processed by the server;

[0021] 2) Based on the total amount of server memory obtained and the calculated server memory usage, calculate the memory utilization rate and the remaining schedulable computing power of the server.

[0022] 3) Calculate the weighted remaining computing power based on the lightweight success rate weight factor and the remaining computing power.

[0023] Preferably, the server scheduling based on the calculated memory occupancy rate and weighted remaining computing power includes the following aspects:

[0024] 1) Target servers are filtered based on memory occupancy using preset thresholds;

[0025] 2) Based on the selected target servers, determine the optimal server using weighted remaining computing power;

[0026] 3) Based on the optimal server, distribute the BIM model lightweighting task to the target server and update the task status in the task information table synchronously.

[0027] The following beneficial effects can be achieved by using the technology of this invention:

[0028] (1) Resource utilization is significantly improved. By dynamically matching model resource consumption with the remaining computing power of the server, large models are prevented from failing due to insufficient resources or small models from wasting memory, thereby improving the average memory utilization of the cluster.

[0029] (2) The success rate of task lightweighting has been significantly improved. For example, the weighted strategy prioritizes servers with a lightweighting success rate of ≥95% to undertake similar tasks, resulting in a significant decrease in the failure rate of lightweighting in the RVT model of a certain project.

[0030] (3) Real-time scheduling latency is greatly reduced. The response time for querying the number of concurrent tasks based on high-speed cache can be controlled at the millisecond level, supporting the instant allocation of bursty tasks.

[0031] (4) Enhanced cross-heterogeneous environment adaptability, compatible with various mainstream model formats such as RVT, DGN, and IFC, as well as various lightweight engines such as Bimface and Itwin, and achieves dynamic adaptation through engine identification code. Attached Figure Description

[0032] Hereinafter, some specific embodiments of the present invention will be described in detail by way of example and not limitation, with reference to the accompanying drawings.

[0033] Figure 1 This is a schematic diagram of an embodiment of the lightweight server scheduling method for heterogeneous BIM models according to the present invention;

[0034] Figure 2 This is a schematic diagram of the structure field design of the data storage structure engine information table in an embodiment of the present invention;

[0035] Figure 3 This is a schematic diagram of the data storage structure server information table structure field design in an embodiment of the present invention;

[0036] Figure 4 Design diagram of the database task information table structure fields;

[0037] Figure 5 A diagram illustrating the initialization of engine information table data records;

[0038] Figure 6 A diagram illustrating the initialization of server information table data records;

[0039] Figure 7 This is a diagram illustrating the data recording in the task information table after receiving a task request.

[0040] Figure 8 This is a schematic diagram illustrating how the system updates the task information table data records in real time after task distribution in an embodiment of the present invention. Detailed Implementation

[0041] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. The described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0042] Terminology Explanation:

[0043] Lightweight engines: Tools used to compress and convert BIM models to reduce computational resource consumption, such as Bimface which supports RVT format conversion and Itwin which supports DGN format conversion;

[0044] Hutool: A Java-based utility library that provides general utility methods such as snowflake ID generation, file parsing, collection operations, and date processing;

[0045] Request: A network request object used to transfer model files and parameters between the client and the server;

[0046] Snowflake ID: A distributed unique identifier generation algorithm that generates a 64-bit unique code using elements such as timestamp and machine ID to ensure the uniqueness of task identifiers in a cluster environment;

[0047] Redis: An open-source in-memory data storage system that supports high-performance key-value pair queries and is used to cache real-time task status;

[0048] The SCAN command: An iterator command provided by Redis, used to iterate through a large number of keys without blocking the server;

[0049] HTTP request: A network request based on the Hypertext Transfer Protocol (HTTP) used to transfer task data between the client and the server;

[0050] Model file file stream: refers to the binary data transmission format of BIM model files, carried by the file stream field of HTTP requests, and used to transmit the original model data between the client and the server.

[0051] Example 1

[0052] See Figure 1 This embodiment provides a method for intelligent scheduling of lightweight servers for heterogeneous BIM models, including the following steps:

[0053] Step S1: Construct the data storage structure, design the engine information table, server information table, task information table, and cache structure for storing task information during processing, and initialize the engine information table and server information table.

[0054] In this embodiment, to achieve intelligent scheduling of heterogeneous BIM model servers, it is necessary to design engine information tables, server information tables, task information tables, and a supporting cache structure to realize structured storage and efficient querying of model resource consumption, server configuration, and historical task data. The data storage system includes three types of core data tables:

[0055] Engine Information Table: Records the lightweight engines and their memory consumption corresponding to different model formats. For example, it records that the memory consumption per task for the RVT model under the Bimface engine is 8.00GB. This table includes fields such as file extension, engine identifier, and memory consumption per task, and can support resource requirement statistics by model format and engine type.

[0056] The server information table stores server hardware configurations, such as total memory and reserved memory space, as well as network information, such as server IP address and service port. It also records the types of engines supported by the server. For example, a server has a total memory of 32.00GB, a reserved memory space of 5.00GB, and supports the engine identifier BIMFACE_001.

[0057] Task Information Table: Records historical task execution data, including task status (e.g., successful, failed, or in progress), task generation time, engine identifier, and server primary key. Using the server primary key and task generation time, task information and total task counts can be queried within a specified timeframe. It also calculates the total number of successfully lightweighted tasks based on their success status and finally, the success rate of lightweighting specific server model files. For example, it can calculate the success rate of lightweighting the BIM-Server1 server model over the past hour.

[0058] In this embodiment, the three data tables are linked through the engine identifier and the server primary key. The engine information table is linked to the server information table through the engine identifier, and the server information table is linked to the task information table through the server primary key, supporting the scheduling and tracing of historical task performance. Specifically:

[0059] The engine information table and the server information table are linked through engine identifiers. The engine information table stores the mapping between model file extensions and engine identifiers, and records the memory consumption per unit task. The server information table is linked to the engine information table through foreign key engine identifiers to record the total memory and reserved memory space of servers supporting the corresponding engine. During data retrieval, the engine identifier and memory consumption per unit task are first obtained from the engine information table by model file extension. Then, based on the engine identifier, the server information table is used to filter out servers that support lightweight models of that format, along with their total memory and reserved memory space information. This association mechanism achieves a three-level data mapping of "model format-engine-server," enabling the identification of servers that support lightweight models based on their file format, and constructing a complete data link from model characteristics to server resources to support dynamic scheduling.

[0060] The server information table and the task information table are linked via a foreign key using the server's primary key. The task information table is linked to the server information table through the server's primary key field, allowing retrieval of all lightweight model file tasks executed by that server, including task generation time and task status. The task generation time field allows filtering and querying of task records within a predetermined time period, and calculating the total number of tasks within that time period. Simultaneously, the task status field filters for records with a status of "lightweighting successful," calculating the total number of successfully lightweighted tasks. Finally, the success rate of a specific server in processing lightweight model files is calculated using a formula (e.g., total number of successful tasks / total number of tasks × 100%), thereby tracing the server executing the tasks and its reliability performance.

[0061] The following will combine Figure 2 , Figure 3 , Figure 4 Further examples illustrate the design of the fields in each table of this database and the cache structure:

[0062] 1. Engine Information Table, named analysis_manager_engine, records the memory consumption of lightweight engines corresponding to different file extensions. It supports resource requirement statistics by model format and engine type. The table contains the following fields:

[0063] 1) Engine primary key field

[0064] Field name: id; Data type: INT AUTO_INCREMENT; Primary key: Yes; Unique: Yes; Field description: Engine primary key, auto-incrementing integer, uniquely identifies each record.

[0065] 2) Model file extension field

[0066] Field name: file_suffix; Data type: VARCHAR(10); Primary key: No; Unique: No; Field description: Model file extension, such as rvt, dgn, dwg.

[0067] 3) Engine Name Field

[0068] Field name: engine_name; Data type: VARCHAR(50); Primary key: No; Unique: No; Field description: Lightweight engine name, such as Bimface, Itwin, CBE.

[0069] 4) Engine Identifier Field

[0070] Field name: engine_code; Data type: VARCHAR(30) UNIQUE; Primary key: No; Unique: Yes; Field description: Engine identifier code (such as BIMFACE_001, ITWIN_002), ensuring consistency across tables.

[0071] 5) Unit task memory consumption field

[0072] Field name: memory_consumption; Data type: FLOAT(10,2); Primary key: No; Unique: No; Field description: Memory consumption per task, in GB, accurate to 2 decimal places, 8.00, 2.00.

[0073] 6) Creator field

[0074] Field name: creator; Data type: VARCHAR(50); Primary key: No; Unique: No; Field description: Creator account.

[0075] 7) Create a time field

[0076] Field name: create_time; Data type: DATETIME DEFAULT CURRENT_TIMESTAMP; Primary key: No; Unique: No; Field description: Creation time, defaults to current time.

[0077] 8) Updater field

[0078] Field name: updater; Data type: VARCHAR(50); Primary key: No; Unique: No; Field description: Last updated user's account.

[0079] 9) Update time field

[0080] Field name: update_time; Data type: DATETIME ON UPDATE CURRENT_TIMESTAMP; Primary key: No; Unique: No; Field description: Last update time, automatically refreshed during updates.

[0081] 10) Delete the status field

[0082] Field name: delete_status; Data type: TINYINT(1) UNSIGNED; Primary key: No; Unique: No; Field description: Delete status, 0 for not deleted, 1 for deleted, default 0.

[0083] The deletion status field serves as a logical deletion indicator. 0 indicates the record is valid and not deleted, while 1 indicates the record is logically invalid but remains in the database. It is used for data auditing, accidental deletion recovery, and to prevent physical deletion from causing data corruption. In engine information queries, valid records are filtered by using "delete_status=0".

[0084] 2. Server Information Table, named analysis_manager_server, records the server's hardware configuration, network information, and the engine it belongs to, providing basic data for resource scheduling. The table contains the following fields:

[0085] 1) Server primary key field

[0086] Field name: id; Data type: INT AUTO_INCREMENT; Primary key: Yes; Unique: Yes; Field description: Server primary key, auto-incrementing integer, uniquely identifies each server.

[0087] 2) Server Name Field

[0088] Field name: server_name; Data type: VARCHAR(50); Primary key: No; Unique: Yes; Field description: Server name, such as Server-01, BIM-Server.

[0089] 3) Engine Identifier Field

[0090] Field name: engine_code; Data type: VARCHAR(30); Primary key: No; Unique: No; Field description: Engine identifier code, used to associate with the engine information table, indicating the type of engine supported by the server.

[0091] 4) Total Memory Field

[0092] Field name: total_memory; Data type: FLOAT(10,2); Primary key: No; Unique: No; Field description: Total server memory capacity, in GB, such as 32.00, 64.00.

[0093] 5) Reserved memory space field

[0094] Field name: reserved_memory; Data type: FLOAT(10,2); Primary key: No; Unique: No; Field description: Reserved memory space, in GB, such as 5.00, 8.00.

[0095] 6) Server IP address field

[0096] Field name: ip_address; Data type: VARCHAR(45); Primary key: No; Unique: No; Field description: Server IP address, such as 192.168.1.100.

[0097] 7) Service Port Field

[0098] Field name: port; Data type: INT UNSIGNED; Primary key: No; Unique: No; Field description: Service port, such as 8080, 3000.

[0099] 8) Creator field

[0100] Field name: creator; Data type: VARCHAR(50); Primary key: No; Unique: No; Field description: Creator account.

[0101] 9) Create a time field

[0102] Field name: create_time; Data type: DATETIME DEFAULT CURRENT_TIMESTAMP; Primary key: No; Unique: No; Field description: Creation time, defaults to current time.

[0103] 10) Updater field

[0104] Field name: updater; Data type: VARCHAR(50); Primary key: No; Unique: No; Field description: Last updated user's account.

[0105] 11) Update time field

[0106] Field name: update_time; Data type: DATETIME ON UPDATE CURRENT_TIMESTAMP; Primary key: No; Unique: No; Field description: Last update time, automatically refreshed during updates.

[0107] 12) Delete the status field

[0108] Field name: delete_status; Data type: TINYINT(1) UNSIGNED; Primary key: No; Unique: No; Field description: Delete status, 0 for not deleted, 1 for deleted, default 0.

[0109] The deletion status field serves as a logical deletion indicator. 0 indicates the record is valid and not deleted, while 1 indicates the record is logically invalid but remains in the database. It is used for data auditing, accidental deletion recovery, and to prevent physical deletion from causing data corruption. In server information queries, valid records are filtered by using "delete_status=0".

[0110] 3. Task Information Table, named analysis_manager_task, records historical data of task execution, providing a basis for lightweight success rate calculation for the weighted scheduling algorithm. The table contains the following fields:

[0111] 1) Task primary key field

[0112] Field name: id; Data type: INT AUTO_INCREMENT; Primary key: Yes; Unique: Yes; Field description: Task primary key, auto-incrementing integer, uniquely identifies each task record.

[0113] 2) Engine Identifier Field

[0114] Field name: engine_code; Data type: VARCHAR(30); Primary key: No; Unique: No; Field description: Engine identifier code, used to associate with the engine information table, indicating the engine used by the task.

[0115] 3) Server primary key field

[0116] Field name: server_id; Data type: INT; Primary key: No; Unique: No; Field description: Server primary key, used to associate with the server information table, representing the server number that handles the task.

[0117] 4) Task Name Field

[0118] Field name: task_name; Data type: VARCHAR(100); Primary key: No; Unique: No; Field description: Task name, such as RVT model lightweighting-20250518.

[0119] 5) Task Status Field

[0120] Field name: task_status; Data type: VARCHAR(20); Primary key: No; Unique: No; Field description: Task status (lightweighting successful, lightweighting failed, queued, processing).

[0121] The task status (task_status) includes several states: queued, processing, lightweighting successful, and lightweighting failed. Queued indicates the status of the initial record generated when the task request is received; processing indicates the status of task scheduling completed after the optimal service selection; lightweighting successful indicates that the model file has been successfully converted to its original format on the lightweighting server; lightweighting failed indicates that the model file has failed to be converted to its original format on the lightweighting server.

[0122] 6) Task generation time field

[0123] Field name: parse_time; Data type: DATETIME; Primary key: No; Unique: No; Field description: Task generation time, used to count the number of tasks in the past hour.

[0124] 7) File Name Field

[0125] Field name: file_name; Data type: VARCHAR(200); Primary key: No; Unique: No; Field description: Model file name, such as Project.rvt.

[0126] 8) File extension field

[0127] Field name: file_suffix; Data type: VARCHAR(10); Primary key: No; Unique: No; Field description: Model file extension, such as rvt, dgn.

[0128] 9) Task lightweighting time consumption field

[0129] Field name: parse_duration; Data type: INT; Primary key: No; Unique: No; Field description: Time consumed by task lightweighting, in milliseconds, used for performance analysis.

[0130] 10) Creator field

[0131] Field name: creator; Data type: VARCHAR(50); Primary key: No; Unique: No; Field description: Creator account.

[0132] 11) Create a time field

[0133] Field name: create_time; Data type: DATETIME DEFAULT CURRENT_TIMESTAMP; Primary key: No; Unique: No; Field description: Creation time, defaults to current time.

[0134] 4. Cache structure, used to store task information during processing.

[0135] It should be noted that for the real-time statistical requirement of "number of tasks in processing" in the task information table (i.e., the number of tasks with the status "in processing"), the traditional database query method based on "server primary key + task status" has an efficiency bottleneck. Therefore, a key-value pair cache structure is introduced to store task information.

[0136] Tasks go through different stages in their lifecycle: upon receiving a task request, an initial record is generated and marked as "queued"; after the optimal server scheduler completes the process, it is updated to "processing"; and after the model file completes format conversion on the lightweight server, it is marked as "lightweighting successful" or "lightweighting failed" based on the result. Tasks only in the "processing" state need to reflect the server's current load in real time; therefore, these tasks are stored in a cache structure to achieve high-concurrency read / write operations with millisecond-level responses through in-memory databases (such as Redis, AMDC) or local caches (such as Java HashMap), ensuring efficient real-time monitoring of server load status.

[0137] In this embodiment, to achieve efficient statistics of tasks being processed within the server, a key-value pair cache structure is designed to store task information during processing. The key-value pair cache structure typically has a KEY-VALUE format, where the key KEY serves as an index for fast location, and the value VALUE stores the core information of the task in a structured data format.

[0138] The cache key format adopts a hierarchical naming rule: MODEL:POOL:{engineCode}:{serverId}:{taskId}, where engineCode corresponds to the engine identifier, serverId is the server primary key, and taskId is the task primary key. MODEL and POOL are custom prefixes. The former clearly defines the business scenario of the cache, isolating it from cached data of other non-model tasks; the latter indicates that the task enters a "processing" state after being scheduled to the server, stored in the "pool" waiting for or executing processing, and is removed from the cache pool when the task is completed. This two-layer prefix design of "MODEL" and "POOL" facilitates developers' quick understanding of the data meaning through the key, and also supports the system in batching similar data through prefix matching (e.g., MODEL:POOL:*), improving cache management efficiency.

[0139] Taking Redis as an example, executing the command `SCANMODEL:POOL:{engineCode}:{serverId}:*` iterates through keys matching the specified format, and the result represents the number of tasks currently being processed on the designated server. Each task in the "processing" state generates a unique key following the format `MODEL:POOL:{engineCode}:{serverId}:{taskId}`. For example, the key for a task in processing with engine ID BIMFACE_001, server primary key 101, and task primary key 20250520001 would be `MODEL:POOL:BIMFACE_001:101:20250520001`. If the server is currently processing 10 tasks simultaneously, it will generate 10 keys with values ​​ranging from MODEL:POOL:BIMFACE_001:101:20250520001 to MODEL:POOL:BIMFACE_001:101:202505200010. Each key corresponds to a task instance in a "processing" state. By matching all task keys under the server using the Redis wildcard *, the number of results reflects the real-time number of tasks currently being processed by the server.

[0140] This design ensures that N tasks in the process will generate N independent keys, and all keys follow a unified naming convention (MODEL:POOL:{engineCode}:{serverId}:{taskId}). This ensures that regardless of the number of tasks, the same SCAN command pattern can be used to quickly count the number of tasks. A single SCAN operation is sufficient to obtain the accurate number of tasks, providing instant data support for real-time computing power calculations in step S401 and avoiding the performance overhead of multiple database queries.

[0141] The VALUE value of the cache structure stores core task information in structured data format, including fields such as task primary key, engine identifier, server primary key, task name, task status, task generation time, file name, and file extension. Only tasks in the "processing" state are stored in this cache structure. An example of its VALUE format is shown below:

[0142] {"id":"201","engine_code":"BIMFACE_001","server_id":"101","task_name":"RVT Lightweight-20250510","task_status":"Processing", "parse_time":"2025-05-1909:10","file_name":"Factory-F1.rvt","file_suffix":"rvt"}.

[0143] Through the detailed data storage structure described above, standardized management of the unit task memory consumption, total server memory, reserved server memory space, number of tasks being processed on the server, and success rate of lightweight model file processing on the server is achieved, providing a data foundation for the subsequent intelligent scheduling process.

[0144] In this embodiment, multiple relational databases are supported for data storage, including but not limited to MySQL, SQL Server, Oracle, DM, and PolarDB, for persistent storage of structured data. The system achieves data linkage by constructing a three-level association model (engine information table, server information table, and task information table), with each table establishing relationships through foreign key fields such as engine identifier and server primary key.

[0145] During system initialization, basic data needs to be entered through the management interface. This includes engine information such as file extensions supported by the Bimface engine and memory consumption per unit task, as well as server information such as total memory, reserved memory space, server IP address, and service port. This data forms the basis for subsequent calculations and intelligent scheduling. The system ensures data accuracy through regular maintenance and uses a standardized structure to store static configurations and dynamic records to support the entire business logic process. The following are examples of the initialization engine information table and server information table.

[0146] like Figure 5 The image shows a data record in the engine information table. One record has the following characteristics: file extension is .rvt, engine name is Bimface, engine identifier is BIMFACE_001, and unit task memory consumption is 8.00GB.

[0147] like Figure 6 The image shows a data record in the server information table. One record has the following characteristics: server primary key is 101, server name is BIM-Server1, engine identifier is BIMFACE_001, total memory is 32.00GB, reserved memory space is 5.00GB, service IP address is 192.168.1.97, and service port is 8080.

[0148] Step S2: The parsing module receives the BIM model lightweighting request, extracts and parses the model file, queries the engine identification code corresponding to the model file from the engine information table, and enters it into the task information table along with the task name, task status and task generation time automatically generated by the system to generate the initial task record.

[0149] In this embodiment, the system's parsing module receives a BIM model lightweighting task request, automatically generates a task name, task status, and task generation time, and extracts the model file's file stream from the Request object based on the HTTP request protocol. It then parses the model file name and extension from the file stream, queries the engine information table based on the extension to obtain the corresponding engine identifier code, and finally enters the parsed model file name and extension, the queried engine identifier code, and the automatically generated task name, task status, and task generation time into the task information table to generate an initial task record.

[0150] The following are examples.

[0151] In this embodiment, when the system receives a BIM model lightweighting task request, it will automatically generate the task name, task status, and task generation time.

[0152] The task name can be in the format "lightweight_snowflake ID", where the snowflake ID can be generated by the IdUtil.getSnowflake() method of the Hutool component to ensure global uniqueness.

[0153] The task status (task_status) includes several states such as queued, processing, lightweighting successful, and lightweighting failed. Whenever the system receives a BIM model lightweighting task request, the task status is initialized to "queued," indicating that the task is waiting for scheduling.

[0154] The task generation time (parse_time) is the time when the model task was initialized and generated, which can be automatically obtained through the database function CURRENT_TIMESTAMP. This record is persisted through database operations to provide data support for subsequent processing.

[0155] Parsing the file stream of the model file can be done using the Hutool utility component in the Java programming language. The file processing method `FileUtil.getSuffix()` can be called to parse the model file name and extension from the file stream, and then the corresponding engine identifier code can be obtained by querying the engine information table based on the extension. For example... Figure 5 As shown, the file name Project.rvt has the .rvt extension, its engine name is Bimface, and its engine identifier is BIMFACE_001.

[0156] After parsing out the model file name and extension, as well as the retrieved engine identifier, these are entered into the task information table along with the automatically generated task name, task status, and task generation time to generate the initial task record.

[0157] The above describes the process of generating an initial record for a model request task. The system needs to generate an initial record according to this process for each received model request task. Figure 7 The image shows the information data record of all task requests received by the system, which records the task primary key, engine identifier code, task name, task status, task generation time, file name, and file extension.

[0158] It should be noted that: in Figure 7 When generating the initial task record, the server primary key field in the task information table is empty, and the task status is marked as "queuing". After the optimal server allocation is completed in the subsequent S5 step, the system updates the primary key of the allocated server in the task information table, updates the task status to "processing", and sends a BIM model file lightweighting request to the server. When the server completes the model lightweighting process, the task status is updated according to the processing result: if lightweighting is successful, the task status is updated to "lightweighting successful"; if processing fails, the task status is updated to "lightweighting failed". The above process ensures that the task information table reflects the task scheduling progress and execution results in real time.

[0159] Step S3: For the model lightweighting request, the preprocessing module obtains the unit task memory consumption, server primary key, server memory configuration information and network information from the engine information table and server information table based on the engine identifier code, obtains the total number of server tasks and the number of successful lightweighting tasks from the task information table and calculates the lightweighting success rate, and obtains the number of tasks in processing from the cache structure.

[0160] In this embodiment, the preprocessing module initiates the data acquisition process based on the engine identification code obtained in step S2:

[0161] First, query the unit task memory consumption from the engine information table, and obtain the server primary key, server memory configuration information and network information from the server information table. The server memory configuration information includes the total memory and reserved memory space, and the server network information includes the server IP address and service port.

[0162] At the same time, extract the task records of the server associated with the engine identification code within the predetermined time from the task information table, filter and count the total number of tasks and the total number of lightweight successful tasks according to the task status, and calculate the lightweight success rate.

[0163] In addition, the number of keys for tasks in processing is obtained by scanning the cache structure of the in-memory database, and the number of tasks in processing is counted.

[0164] It should be noted that the system processes each task cyclically according to the above procedure. For each lightweight task, the preprocessing module independently executes a complete process, including querying unit task memory consumption, obtaining server memory configuration and network information, calculating the lightweight success rate, and counting the number of tasks in progress. Through this cyclical processing mechanism for each single task, the system can generate a unique resource evaluation dataset for each task, providing fine-grained data support for subsequent task queue scheduling, server resource allocation, and task priority determination, ensuring resource balance and processing efficiency during concurrent multi-task processing.

[0165] In this embodiment, as a preprocessing step, based on the engine identification code obtained in step S2, data including unit task memory consumption, total memory, reserved memory space, server IP address, service port, lightweight success rate, and number of tasks in processing are integrated to provide data support for the calculation in the subsequent step S4, thereby supporting the server intelligent scheduling decision in step S5.

[0166] Specifically, the following steps are included:

[0167] S301: Based on the engine identification code obtained in step S2, obtain the unit task memory consumption of the corresponding engine by querying the engine information table.

[0168] In this embodiment, based on the engine identifier code obtained in step S2, the unit task memory consumption of the corresponding engine is obtained through database query. This parameter is used to quantify the server memory resource requirements of a single BIM model lightweighting task.

[0169] In this embodiment, data retrieval is achieved by executing the SQL statement `SELECT id,file_suffix, engine_code, engine_name, memory_consumption FROM analysis_manager_engine WHERE engine_code = #{engineCode} AND delete_status = 0`, using engine identifier code and deletion status as filtering conditions. The meaning of this statement is:

[0170] The query matches the engine identifier code determined in step S2 with the engine_code field, filters out valid records by delete_status=0, and finally returns a complete data record containing the engine primary key, file extension, engine name, and unit task memory consumption.

[0171] like Figure 5 As shown, when the engine identifier is BIMFACE_001, executing the above SQL query can obtain a valid record, which includes the engine primary key 1, the supported file extension rvt, the engine name Bimface Lightweight Engine, and the unit task memory consumption of 8.00GB. The unit task memory consumption value in this record will be used in the calculation process in step S4.

[0172] S302: Based on the engine identifier obtained in step S2, obtain the server primary key, server memory configuration information and network information that support the engine by querying the server information table.

[0173] In this embodiment, based on the engine identifier code obtained in step S2, the server memory configuration information and network information supporting the engine are obtained by querying the server information table. This process extracts key parameters such as total memory, reserved memory space, server IP address, and service port from the server information table using the engine identifier code. These parameters are used in the calculation process in step S4 and provide basic data for task scheduling in step S5.

[0174] In this embodiment, data retrieval is achieved by executing the SQL statement `SELECT id,server_name, total_memory, reserved_memory, ip_address, port FROM analysis_manager_server WHERE engine_code = #{engineCode} AND delete_status = 0`, using engine identifier code and deletion status as filtering conditions. The meaning of this statement is:

[0175] The query matches the engine identifier code determined in step S2 with the engine_code field, filters out valid records by delete_status=0, and finally returns a complete data list containing the server primary key, server name, memory configuration, and network address.

[0176] like Figure 6 As shown, when the engine identifier is BIMFACE_001, executing the above SQL query can retrieve multiple valid records, including server primary key 101, server name BIM-Server1, total memory 32.00GB, reserved memory space 5.00GB, server IP address 192.168.1.97, and service port 8080. The total memory and reserved memory space parameters in this list will be used in the calculation process in step S4, while the server IP address and service port information provide network connection information for task distribution in step S5.

[0177] S303: Based on the server primary key obtained in step S302, obtain the lightweight success rate of each server model by retrieving the task information table.

[0178] In this embodiment, based on the server primary key set obtained in step S302, the model lightweighting success rate of each server within a predetermined time (e.g., within 1 hour) is statistically analyzed by retrieving the task information table. This process distinguishes between successful and failed lightweighting records by task status, and calculates the lightweighting success rate by grouping servers, providing a basis for evaluating the historical performance of servers for subsequent dynamic scheduling in S5. The predetermined time can be customized by the user.

[0179] In this embodiment, the server primary key set and task generation time are used as filtering conditions, and the predetermined time is set to 1 hour. The SQL statement `SELECT id, engine_code, server_id, task_name, task_status, parse_time, file_name, file_suffix FROM analysis_manager_task WHERE server_id IN (${serverIds}) AND parse_time>= DATE_SUB(NOW(), INTERVAL 1HOUR)` is executed to retrieve data. The meaning of this statement is:

[0180] This query matches the target server using server_id IN (${serverIds}), filters task records from the past hour using parse_time>=DATE_SUB(NOW(), INTERVAL 1 HOUR), and returns a complete list of data containing fields such as task status and server primary key.

[0181] like Figure 7 As shown, assuming that after executing the query, 200 task records are obtained from the server pointed to by server primary key 101 (engine identifier BIMFACE_001) and 150 task records are obtained from the server pointed to by server primary key 102, after grouping by server_id using CollUtil.groupBy() from the Hutool toolkit, statistics are performed on each group of tasks:

[0182] Of the 200 records pointed to by server primary key 101, 190 have a task status of "lightweighting successful", and the lightweighting success rate is 190 / 200×100%=95%.

[0183] Of the 150 records on the server pointed to by primary key 102, 135 have a task status of "lightweighting successful", and the success rate of lightweighting is 135 / 150×100%=90%.

[0184] The calculation results are associated with the server's primary key (e.g., {101: 0.95, 102: 0.90}) through successRateMap.

[0185] S304: Based on the engine identifier obtained in step S2 and the server primary key obtained in step S302, the number of tasks currently being processed by the server is obtained by searching the cache structure.

[0186] In this embodiment, based on the engine identifier code obtained in step S2 and the server primary key set obtained in step S302, the number of tasks currently being processed by each server is retrieved through a cache structure. This process can be achieved by constructing a cache key to match real-time task records.

[0187] In this embodiment, the server list in step S302 is traversed, and a cache key pattern MODEL:POOL:{engineCode}:{serverId}:* is constructed for each server's primary key. The Redis SCAN command or keys method is used to iteratively match the currently processed task keys. The execution logic is as follows:

[0188] Map<Integer, Integer> concurrentTaskMap = new HashMap<>();

[0189] serverList.forEach(server ->{

[0190] String keyPattern="MODEL:POOL:" +engineCode+":"+server.getServerId()+":*";

[0191] Set <string>keys=redisTemplate.keys(keyPattern);

[0192] concurrentTaskMap.put(server.getServerId(), CollUtil.size(keys));}).

[0193] This method allows you to obtain the number of tasks currently in the "processing" state on each server in real time.

[0194] Assuming the engine identifier is BIMFACE_001, the server pointed to by server primary key 101 and server primary key 102 obtained in step S302, after executing the above logic, may result in:

[0195] The server primary key 101 points to a server that matches 3 keys, meaning there are currently 3 tasks in progress.

[0196] The server primary key 102 points to a server with a matching key count of 2, meaning there are currently 2 tasks in progress.

[0197] This parameter will be used in the calculation process in step S4 to help determine the server load status and optimize the scheduling strategy.

[0198] Step S4: The calculation module calculates real-time memory usage, memory occupancy rate, and remaining computing power based on the unit task memory consumption, server memory configuration, lightweighting success rate, and number of tasks in processing. It also determines the weighting factor based on the lightweighting success rate to obtain the weighted remaining computing power.

[0199] In this embodiment, the calculation module, based on the data extracted in step S3, such as the unit task memory consumption, total server memory and reserved space, number of tasks in processing, and lightweight success rate, quantifies the real-time server load and available resources through mathematical modeling, providing a quantitative basis for intelligent server scheduling in step S5. The specific process is as follows:

[0200] First, calculate memory usage based on "number of tasks in process × memory consumption per task + reserved memory space";

[0201] Secondly, the memory utilization rate is calculated as "memory usage / total memory × 100%" to screen qualified servers whose memory load does not exceed the threshold.

[0202] Next, calculate the remaining computing power based on "total memory - memory usage";

[0203] Then, the weighting factor is determined based on the success rate of lightweighting;

[0204] Finally, the weighted remaining computing power is obtained by "weight factor × remaining computing power". This weighted remaining computing power serves as the core parameter for scheduling and ranking. It combines the server's remaining computing power with historical processing performance to achieve a dynamic scheduling strategy of "load priority + historical performance weighting".

[0205] It should be noted that the system processes each task cyclically according to the above procedure. That is, whenever a task enters the computation phase, the computation module extracts real-time data from the server associated with that task, including unit task memory consumption, total server memory, reserved memory space, number of tasks in processing, and lightweight success rate. It then independently executes a complete calculation process for memory usage, memory utilization, remaining computing power, and weighted remaining computing power. When multiple tasks enter concurrently, the computation module performs the above calculations for each task sequentially, ensuring that the scheduling decisions for each task are based on the latest server load status and historical performance data, guaranteeing efficient utilization of server resources and balanced task processing.

[0206] Specifically, the following steps are included:

[0207] S401: Based on the unit task memory consumption, server reserved space, and number of tasks being processed by the server obtained in step S3, calculate the server memory usage.

[0208] In this embodiment, based on the unit task memory consumption, server reserved space, and number of tasks being processed by the server obtained in step S3, the real-time memory usage of the server is calculated using the formula: Memory Usage = Number of Tasks Being Processed by the Server × Unit Task Memory Consumption + Reserved Memory Space. This formula integrates the dynamic memory consumption during task execution with the static memory requirements reserved by the system, and is used to quantify the current load status of the server.

[0209] In this embodiment, assuming the unit task memory consumption obtained in step S301 is 8.00GB, the server reserved space obtained in step S302 is 5.00GB, and the number of tasks being processed by the server is 2 as counted in step S304, then the memory usage = 2 × 8.00GB + 5.00GB = 21.00GB. This result indicates that the server has currently allocated 16.00GB of memory for running tasks, plus the 5.00GB reserved by the system, for a total of 21.00GB of memory resources.

[0210] S402: Based on the total server memory obtained in step S302 and the server memory usage calculated in step S401, calculate the memory occupancy rate and the server's currently schedulable idle memory resources, i.e., the remaining computing power.

[0211] In this embodiment, based on the total server memory obtained in step S302 and the memory usage calculated in step S401, the current server load status is calculated using the formula: Memory Utilization Rate = 100% × Memory Usage / Total Memory. This indicator quantifies the degree of memory resource utilization as a percentage, used to determine whether the server is under normal operating pressure, providing a key basis for scheduling decisions.

[0212] In this embodiment, assuming the total server memory obtained in step S302 is 32.00GB and the memory usage calculated in step S401 is 21.00GB, then the memory utilization rate = 100% × 21.00GB / 32.00GB = 65.625%. If the system sets the memory utilization rate threshold to 95%, then the current server is within the normal load range (65.625% < 95%) and can safely accept new scheduling tasks; if the threshold is exceeded, a rate limiting or load balancing strategy is triggered to ensure stable server operation.

[0213] In this embodiment, based on the total server memory obtained in step S302 and the memory usage calculated in step S401, the currently available free memory resources of the server are calculated using the formula: Remaining computing power = Total memory - Memory usage. This indicator directly reflects the server's capacity to handle new tasks and is the core basis for determining whether to accept a new scheduling request.

[0214] In this embodiment, assuming the total server memory obtained in step S302 is 32.00GB and the memory usage calculated in step S401 is 21.00GB, then the remaining computing power = 32.00GB - 21.00GB = 11.00GB. This result indicates that the server currently has 11.00GB of memory available for allocating new BIM model lightweighting tasks. If the memory requirement for a single task is 8.00GB, then theoretically, one more such task can be processed simultaneously.

[0215] S403: Determine the weighting factor based on the lightweight success rate, and calculate the weighted remaining computing power in combination with the remaining computing power.

[0216] By introducing a dynamic adjustment weighting factor based on the lightweight success rate of tasks and combining it with the remaining computing power to calculate a weighted remaining computing power, priority can be tilted towards historically reliable servers. In this embodiment, the weighting factor is determined by "lightweight success rate > A?B1:B2", where A is a preset threshold, and B1 and B2 are preset weighting factors, which can actually be selected by the user.

[0217] The lightweight success rate dynamic adjustment weighting factor introduced in this embodiment is determined according to the following rule: the weighting factor is determined based on the formula "weighting factor = lightweight success rate > 95% ? 1.1 : 1.0", where "95%" is the preset threshold selected in this embodiment, "1.1" and "1.0" are the preset weighting factors selected in this embodiment, and "lightweight success rate" is the task lightweight success rate of the server in the past hour, where "1 hour" is the predetermined time selected in this embodiment. This rule assigns a weighting coefficient of 1.1 to servers with a task lightweight success rate ≥ 95% in the past hour, otherwise the default value of 1.0 is used; then, the real-time available resources of the server are calculated using the formula "weighted remaining computing power = weighting factor × remaining computing power", combining the server's real-time memory resources with historical performance to form a comprehensive scheduling index.

[0218] For example: If step S303 shows a model lightweighting success rate of 50% for a server in the past hour, it does not meet the condition of ">95%", so the weight factor is determined to be 1.0. If step S403 calculates the remaining computing power to be 11.00GB, then the weighted remaining computing power = 1.0 × 11.00GB = 11.00GB. If another server has a model lightweighting success rate of 98% in the past hour, meeting the threshold condition, then the weight factor is 1.1. If its remaining computing power is also 11.00GB, the weighted remaining computing power will be increased to 12.10GB. In this way, the scheduling system will prioritize servers with higher weighted remaining computing power, taking into account both current memory resources and resource allocation to historically stable servers.

[0219] It should be noted that the above weighting factor rules are only an example. In actual applications, other rules can be selected or customized according to business needs, such as:

[0220] 1) Determining weighting factors using the linear gradient weighting method:

[0221] The weighting factor is determined by the formula "B + (lightweight success rate - A) × C", where A is the preset threshold, B is the preset base weight, and C is the preset fitting coefficient. The actual weighting factor can be selected by the user.

[0222] For example: the preset threshold is set to "90%", the base weight is set to "1.0", and the fitting coefficient is set to "0.2". When the success rate of lightweighting is 95%, the weight factor is determined to be 1.1 according to the formula "weight factor = 1.0 + (95% - 90%) × 0.2". For every 1% increase in the success rate, the weight increases by 0.002.

[0223] 2) Determining weighting factors using a segmented, step-weighted method:

[0224] Divide the gradient intervals according to the success rate and set different weights. When the lightweight success rate >= A1, the weight factor is B1; when the lightweight success rate >= A2 but < A1, the weight factor is B2; when the lightweight success rate < A2, the weight factor is B3. Where A1 and A2 are preset thresholds, B1, B2, and B3 are preset weight factors, and A1 > A2, and it can be actually selected according to the user's choice.

[0225] For example: the preset threshold A1 is selected as 98%, the preset threshold A2 is selected as 95%, the weight factor B1 is selected as 1.2, the weight factor B2 is selected as 1.1, and the weight factor B3 is selected as 1.0. When the lightweight success rate is 90%, the weight factor is determined to be 1.0; when the lightweight success rate is 95%, the weight factor is determined to be 1.1; when the lightweight success rate is 98%, the weight factor is determined to be 1.2.

[0226] 3) Determine the weight factor by the dynamic floating weighting method:

[0227] Determine the weight factor by the formula "lightweight success rate > A? F + D1 : F - D2", and set upper and lower limits for the weight factor. Where A is the preset threshold, F is the current reference weight, D1 is the preset upward adjustment factor, and D2 is the preset downward adjustment factor, and it can be actually selected according to the user's choice;

[0228] For example: the preset threshold is selected as "95%", the reference weight is selected as "1.1", the upward adjustment factor is selected as "0.05", the downward adjustment factor is selected as "0.1", and the lower limit of the weight factor is not less than 1.0 and the upper limit is not higher than 1.5. When the lightweight success rate is 96%, determine the weight factor 1.15 according to the formula "lightweight success rate > 95%? 1.1 + 0.05 : 1.1 - 0.1"; when the lightweight success rate is 94%, determine the weight factor 1.0 according to the formula "lightweight success rate > 95%? 1.1 + 0.05 : 1.1 - 0.1".

[0229] Step S5: The server scheduling module realizes server scheduling based on the memory occupancy rate and weighted remaining computing power calculated in step S4.

[0230] In this embodiment, the scheduling module first filters out the servers with a rate lower than the threshold based on the memory occupancy rate and the preset threshold, then selects the one with the largest weighted remaining computing power as the allocation target, and finally distributes the task to the target server and synchronously updates the corresponding task status in the task information table to processing.

[0231] This step, as the server intelligent scheduling link, based on the memory occupancy rate and weighted remaining computing power calculated in step S4, determines the optimal server through the dual strategies of "first filtering the load and then optimizing the performance", and realizes the implementation from data indicators to scheduling decisions.

[0232] In this embodiment, the scheduling module achieves intelligent server scheduling through a three-step process:

[0233] First, servers with memory usage below a preset threshold are selected and included in the candidate pool, while high-load devices are excluded.

[0234] Then, the candidate servers are sorted in descending order according to the weighted remaining computing power calculated in step S403, and the server with the largest value can be selected using the CollUtil.sort tool.

[0235] Finally, after determining the optimal server, the BIM model task flow and parameters are sent to the target server via the HTTP protocol, and the task information table status is updated to "processing". The server primary key is recorded synchronously to form a complete closed loop of "scheduling decision-execution feedback".

[0236] It should be noted that the system processes each task cyclically according to the above procedure. That is, whenever a task enters the scheduling phase, the scheduling module independently executes the complete triple process. Through this cyclical scheduling mechanism for single tasks, each task receives its own "filtering-sorting-allocation-feedback" processing flow. This ensures that in multi-task concurrent scenarios, every scheduling decision is based on the optimal match between the server's real-time load and historical performance, forming a closed-loop management from task access to resource allocation, guaranteeing the efficiency, accuracy, and traceability of intelligent server scheduling.

[0237] The complete three-stage process includes the following steps:

[0238] S501: Target servers are filtered based on memory occupancy using preset thresholds.

[0239] In this embodiment, based on the memory utilization data of each server calculated in step S402, target servers are filtered using a preset threshold. Specifically, the server list is traversed using whether the memory utilization rate is below the threshold as the filtering condition. Servers with a utilization rate below the threshold are included in the candidate pool, while servers with a utilization rate above or equal to the threshold are excluded from task allocation. This strategy ensures that tasks are only allocated to servers that are not approaching resource bottlenecks, avoiding task failures or decreased system stability due to overload.

[0240] In this embodiment, assuming a memory utilization threshold of 95%, step S402 calculates that the memory utilization of the server pointed to by server primary key 101 is 65.625%, significantly lower than the preset threshold of 95%. Therefore, this server is marked as available and added to the candidate pool. If the memory utilization of the server pointed to by server primary key 102 is 96%, it is automatically excluded because it exceeds the threshold. Through this filtering mechanism, the system can dynamically filter high-load devices, providing a safe and reliable server list for subsequent task allocation.

[0241] S502: Based on the selected target servers, determine the optimal server using weighted remaining computing power.

[0242] In this embodiment, based on the candidate server list selected in step S501, the optimal server is determined by sorting the candidates in descending order using a weighted remaining computing power index. Specifically, the CollUtil.sort tool is used to sort the candidate servers from highest to lowest according to the weighted remaining computing power calculated in step S404, and finally, the server with the largest weighted remaining computing power value is selected as the task allocation target. This strategy combines the server's real-time remaining memory with the lightweight success rate, prioritizing the scheduling of devices with "sufficient resources and stable performance" to achieve optimized decision-making in task allocation.

[0243] In this embodiment, the server task allocation mechanism achieves optimal server selection through dynamic weighted calculation and intelligent sorting: at the beginning of each task cycle, the system first traverses the candidate server pool and calculates the weighted remaining computing power of each server, so that the server with better overall performance forms a numerical differentiation advantage.

[0244] Taking a specific scenario as an example, when the candidate servers include the server pointed to by server key 101 with a weighted remaining computing power of 11.00GB and the server pointed to by server key 102 with a weighted remaining computing power of 12.10GB, the system sorts them in descending order of weighted remaining computing power using the CollUtil.sort method. The server pointed to by server key 102 with the higher value will be selected first to execute the task. If the candidate pool only contains the server pointed to by server key 101, then the server is directly selected to simplify the process.

[0245] This dynamic calculation mechanism, embedded in each task loop, ensures that even when multiple servers have similar initial remaining computing power, servers with better historical performance can receive allocation priority through weighting factors. For example, a server with a 98% success rate due to lightweighting might receive higher weighted remaining computing power due to triggering a 1.1 weighting factor, even if its remaining computing power is similar to other servers, thus gaining priority in task allocation. Through this mechanism of dynamic calculation, sorting, and selection in each task loop, the system can accurately locate the target server with the best overall performance, ensuring the rationality and efficiency of task allocation.

[0246] S503: Based on the optimal server, distribute the BIM model lightweighting task to the target server and update the task status in the task information table synchronously.

[0247] In this embodiment, based on the optimal server information determined in step S502, including the server primary key, server IP address, and service port, the BIM model lightweighting task is distributed to the target server via the HTTP protocol, and the task status in the task information table is updated synchronously. Specifically, an HTTP request (such as a POST request) containing the model file stream and task parameters is constructed and sent to the server in the format "http: / / server IP address:service port / API path" to trigger the lightweighting process. Simultaneously, the status field of the corresponding record in the task information table is updated to "processing," and the allocation time and server identifier are recorded to ensure traceability of the scheduling status. In this embodiment, if the optimal server primary key determined in step S502 is 101, its IP address is 192.168.1.97, and its port is 8080, then the scheduling request path is: http: / / 192.168.1.100:8080 / api / lightweight, and the request parameters include the model file binary stream and metadata such as the task primary key and file extension (e.g., JSON format).

[0248] After a task is distributed, the system immediately updates the task information table: such as Figure 8 As shown, the record with task primary key 207 is changed from "queuing" to "processing" and populated with server primary key 101, forming a complete closed loop of "scheduling decision - task execution - status synchronization". This operation ensures that the task is executed correctly on the server side and provides accurate status information for subsequent monitoring and log analysis.

[0249] Example 2

[0250] This embodiment also provides an intelligent scheduling system for lightweight servers of heterogeneous BIM models, which includes:

[0251] 1) Data storage structure, including engine information table, server information table, task information table, and cache structure for storing task information in the process;

[0252] 2) Parsing module, used to receive model lightweighting requests, extract and parse model files, obtain the engine identification code corresponding to the model file from the engine information table, and enter it into the task information table along with the task name, task status and task generation time automatically generated by the system to generate the initial task record.

[0253] 3) Preprocessing module, used to start the data acquisition process based on the engine identification code, obtain the unit task memory consumption and server memory configuration information from the engine information table and server information table, count the total number of server tasks and the number of successful lightweight tasks from the task information table and calculate the lightweight success rate, and count the number of tasks in processing from the cache structure.

[0254] 4) The calculation module is used to calculate memory usage, memory occupancy rate, and remaining computing power based on the unit task memory consumption, server memory configuration, lightweight success rate, and number of tasks being processed. It also determines the weighting factor based on the lightweight success rate to obtain the weighted remaining computing power.

[0255] 5) Server scheduling module, used to implement server scheduling based on the calculated memory usage rate and weighted remaining computing power.

[0256] The computing module includes:

[0257] 1) Unit task memory consumption acquisition submodule, which is used to obtain the unit task memory consumption of the corresponding engine by querying the engine information table based on the obtained engine identifier code;

[0258] 2) Server memory configuration information acquisition submodule, which is used to obtain the server primary key and server memory configuration information that support the engine by querying the server information table based on the obtained engine identifier code;

[0259] 3) Task processing success rate acquisition submodule, which is used to obtain the lightweight success rate of each server model by retrieving the task information table based on the obtained server primary key;

[0260] 4) The submodule for obtaining the number of tasks in processing is used to obtain the number of tasks currently being processed by the server by searching the cache structure based on the obtained engine identifier and server primary key.

[0261] Example 3

[0262] This embodiment proposes an electronic device, including:

[0263] Memory, used to store computer programs;

[0264] The processor is used to execute the program stored in the memory to implement the steps of the above embodiments of the intelligent scheduling method for lightweight servers of heterogeneous BIM models.

[0265] For details on the specific implementation of each step and related explanations, please refer to the aforementioned implementation example of the intelligent scheduling method for lightweight servers of heterogeneous BIM models, which will not be repeated here.

[0266] The memory of the electronic device mentioned in this embodiment may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device.

[0267] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0268] Example 4

[0269] This invention also proposes a computer-readable storage medium storing a computer program. When executed by a processor, this computer program implements the steps of the above-described embodiment of the intelligent scheduling method for lightweight heterogeneous BIM models. For details on the specific implementation and explanations of each step, please refer to the aforementioned embodiment of the intelligent scheduling method for lightweight heterogeneous BIM models, which will not be repeated here.

[0270] It should be noted that all embodiments in this specification are described in a related manner, and the same or similar parts between the embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0271] In particular, the embodiments of apparatus, electronic devices, and computer-readable storage media are basically similar to the method embodiments, so the description is relatively simple, and relevant details can be found in the description of the method embodiments.

[0272] The above description is merely an embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the present invention should be included within the scope of the claims of the present invention.< / string>

Claims

1. A lightweight server intelligent scheduling method for heterogeneous BIM models, characterized in that... This includes the following aspects: 1) Constructing a data storage structure, designing the engine information table, server information table, task information table, and cache structure for storing task information during processing, and initializing the engine information table and server information table; 2) Receive the model lightweighting request, extract and parse the model file, obtain the engine identification code corresponding to the model file from the engine information table, and enter it into the task information table along with the task name, task status and task generation time automatically generated by the system to generate the initial task record. 3) Start the data acquisition process based on the engine identification code, obtain the unit task memory consumption and server memory configuration information from the engine information table and server information table, count the total number of server tasks and the number of successful lightweight tasks from the task information table and calculate the lightweight success rate, and count the number of tasks in processing from the cache structure. 4) Based on the unit task memory consumption, server memory configuration, lightweight success rate and number of tasks in processing, calculate memory usage, memory occupancy rate and remaining computing power, and determine the weighting factor according to the lightweight success rate to obtain the weighted remaining computing power. 5) Server scheduling is implemented based on the calculated memory occupancy rate and weighted remaining computing power.

2. The intelligent scheduling method for lightweight servers of heterogeneous BIM models as described in claim 1, characterized in that: The engine information table includes fields for model file extension, engine identifier, and unit task memory consumption; the server information table includes fields for server primary key, engine identifier, total memory, reserved memory space, service IP address, and service port; the task information table includes fields for server primary key, engine identifier, task status, and task generation time.

3. The intelligent scheduling method for lightweight servers of heterogeneous BIM models as described in claim 1, characterized in that, The process of starting the data acquisition based on the engine identifier code includes the following aspects: 1) Based on the obtained engine identifier, the unit task memory consumption of the corresponding engine is obtained by querying the engine information table; 2) Based on the obtained engine identifier, the server primary key and server memory configuration information supporting the engine are obtained by querying the server information table; 3) Based on the obtained server primary key, retrieve the lightweight success rate of each server model by searching the task information table; 4) Based on the obtained engine identifier and server primary key, the number of tasks currently being processed by the server is obtained by retrieving the cache structure.

4. The intelligent scheduling method for lightweight servers of heterogeneous BIM models as described in claim 1, characterized in that, The weighted residual computing power calculation includes the following aspects: 1) Calculate the server memory usage based on the obtained unit task memory consumption, server reserved space, and number of tasks being processed by the server; 2) Based on the total amount of server memory obtained and the calculated server memory usage, calculate the memory utilization rate and the remaining schedulable computing power of the server. 3) Calculate the weighted remaining computing power based on the lightweight success rate weight factor and the remaining computing power.

5. The intelligent scheduling method for lightweight servers of heterogeneous BIM models as described in claim 1, characterized in that, The server scheduling based on the calculated memory occupancy rate and weighted remaining computing power includes the following aspects: 1) Target servers are filtered based on memory occupancy using preset thresholds; 2) Based on the selected target servers, determine the optimal server using weighted remaining computing power; 3) Based on the optimal server, distribute the BIM model lightweighting task to the target server and update the task status in the task information table synchronously.

6. A lightweight server intelligent scheduling system for heterogeneous BIM models, characterized in that, include: 1) Data storage structure, including engine information table, server information table, task information table, and cache structure for storing task information in the process; 2) Parsing module, used to receive model lightweighting requests, extract and parse model files, obtain the engine identification code corresponding to the model file from the engine information table, and enter it into the task information table along with the task name, task status and task generation time automatically generated by the system to generate the initial task record. 3) Preprocessing module, used to start the data acquisition process based on the engine identification code, obtain the unit task memory consumption and server memory configuration information from the engine information table and server information table, count the total number of server tasks and the number of successful lightweight tasks from the task information table and calculate the lightweight success rate, and count the number of tasks in processing from the cache structure. 4) The calculation module is used to calculate memory usage, memory occupancy rate, and remaining computing power based on the unit task memory consumption, server memory configuration, lightweight success rate, and number of tasks being processed. It also determines the weighting factor based on the lightweight success rate to obtain the weighted remaining computing power. 5) Server scheduling module, used to implement server scheduling based on the calculated memory usage rate and weighted remaining computing power.

7. The intelligent scheduling system for lightweight servers of heterogeneous BIM models as described in claim 6, characterized in that: The engine information table includes fields for model file extension, engine identifier, and unit task memory consumption; the server information table includes fields for server primary key, engine identifier, total memory, reserved memory space, service IP address, and service port; the task information table includes fields for server primary key, engine identifier, task status, and task generation time.

8. The intelligent scheduling system for lightweight servers of heterogeneous BIM models as described in claim 6, characterized in that, The computing module includes: 1) Unit task memory consumption acquisition submodule, which is used to obtain the unit task memory consumption of the corresponding engine by querying the engine information table based on the obtained engine identifier code; 2) Server memory configuration information acquisition submodule, which is used to obtain the server primary key and server memory configuration information that support the engine by querying the server information table based on the obtained engine identifier code; 3) Task processing success rate acquisition submodule, which is used to obtain the lightweight success rate of each server model by retrieving the task information table based on the obtained server primary key; 4) The submodule for obtaining the number of tasks in processing is used to obtain the number of tasks currently being processed by the server by searching the cache structure based on the obtained engine identifier and server primary key.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing a program stored in memory to implement the steps of the method according to any one of claims 1-5.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1-5.

Images