Heterogeneous BIM model lightweight server intelligent scheduling method and system

Abstract

The invention discloses a heterogeneous BIM model lightweight server intelligent scheduling method and system. The method comprises the steps that a data storage structure is constructed, and an engine information table, a server information table and a task information table are designed; according to the engine identification code, obtaining unit task memory consumption and server memory configuration information from the engine information table and the server information table, counting the total number of server tasks and the number of lightweight task success from the task information table, calculating a lightweight success rate, and counting the number of tasks in processing from the cache structure; based on the unit task memory consumption, the server memory configuration, the lightweight success rate and the number of tasks in processing, calculating a memory usage amount, a memory occupancy rate and a residual computing power, and determining a weight factor according to the lightweight success rate to obtain a weighted residual computing power; and realizing server scheduling based on the calculated memory occupancy rate and weighted residual computing power. By adopting the method, model resource consumption and server residual computing power can be dynamically matched, and the average utilization rate of a cluster memory is improved.

Description

Technical Field

[0001] The present invention relates to the field of computer software and building information technology, and in particular to a method and system for intelligent scheduling of lightweight servers for heterogeneous BIM models. Background Art

[0002] In the field of engineering digitization, Building Information Models (BIM) serve as data carriers throughout the entire project lifecycle. Using parametric modeling tools (such as Autodesk Revit and Bentley MicroStation), they integrate multidimensional data, including geometry, materials, and schedules, encompassing information from multiple disciplines, including architecture, structure, and mechanical and electrical engineering. Heterogeneous BIM models are generated by different vendors' software and have varying data formats and structures, such as Autodesk Revit's RVT format, Bentley MicroStation's DGN format, and the open-standard IFC format. These models require lightweight processing to reduce data complexity and adapt to scenarios such as cross-platform collaborative design, construction simulation, and operations and maintenance management. This lightweight approach utilizes engine tools to compress, convert formats, and optimize rendering. For example, Bimface supports cloud-based conversion between RVT, DGN, and IFC formats and provides lightweight web rendering. Itwin achieves high-precision data lightweighting for DGN models. Three.js, an open-source WebGL engine, is compatible with .obj and .gltf formats and supports interactive front-end development.

[0003] As the hardware carrier 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 goal of server scheduling is to select the optimal node from the server cluster to perform lightweight tasks based on parameters such as the model's memory requirements and format type. However, due to differences in data structure, component complexity, and lightweight algorithms, heterogeneous BIM models consume significantly different amounts of server memory, CPU, and other resources during lightweighting. For example, due to the high complexity of parametric components, the RVT model requires 8GB of memory per task for a single lightweighting operation, while the DGN model only requires 2GB of memory per task.

[0004] In the existing technology, 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 requirements of heterogeneous models, resulting in the resource mismatch problem of "large models stuck and small models idle"; second, there is a lack of an evaluation system for the server's ability to process models in specific formats. A server may have a low success rate in lightweighting RVT models due to engine compatibility issues, but it is still frequently assigned similar tasks, resulting in an increase in the overall failure rate; third, it relies on periodic polling to obtain server status and cannot respond to sudden task requests in real time. When the server memory usage rate is ≥95%, it is easy to cause system crashes or task timeouts.

[0005] While a mature ecosystem of BIM model creation tools (such as AutoCAD and ArcGIS), lightweight engines, and engineering applications (such as collision checking during the design phase and 4D progress simulation during construction) has emerged, the scheduling layer lacks a "data-driven + dynamic optimization" mechanism, making it difficult to meet the efficiency and reliability requirements for large-scale heterogeneous model processing. Designing a dynamically weighted intelligent scheduling solution 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 challenge in the field of engineering digitization. Summary of the Invention

[0006] In response to the technical bottlenecks of extensive resource allocation, historical performance oversight, and delayed real-time response in heterogeneous BIM model scheduling, the present invention aims to provide a method and system for intelligent scheduling of lightweight servers for heterogeneous BIM models, which can achieve: recording the resource consumption values ​​of different format models under each engine through a database to achieve accurate mapping of "model format-engine-resource demand"; dynamically adjust the scheduling weight based on the lightweight success rate of specific format models in a certain period of time on the server, and give priority to reliable nodes; use the cache to track the number of concurrent tasks in real time, and dynamically filter overloaded nodes in combination with the memory usage threshold to ensure stable operation of the cluster.

[0007] To achieve the above technical objectives, the present invention provides a method for intelligent scheduling of lightweight servers for heterogeneous BIM models, which includes the following steps: 1) Build a data storage structure, design the engine information table, server information table, task information table, and a cache structure for storing task information in progress, and initialize the engine information table and server information table; 2) Receive the model lightweight request, extract the model file and parse it, 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 progress from the cache structure; 4) Based on the unit task memory consumption, server memory configuration, lightweight success rate and the number of tasks being processed, calculate the memory usage, memory occupancy rate and remaining computing power. Determine the weight factor based on the lightweight success rate to obtain the weighted remaining computing power. 5) Implement server scheduling based on the calculated memory usage and weighted remaining computing power.

[0008] Preferably, the engine information table includes the model file suffix, engine identification code, and unit task memory consumption field; the server information table includes the server primary key, engine identification code, total memory, reserved memory space value, service IP address, and service port field; the task information table includes the server primary key, engine identification code, task status, and task generation time field.

[0009] Preferably, the process of starting the data acquisition process based on the engine identification code includes the following aspects: 1) Based on the obtained engine identification code, obtain the unit task memory consumption of the corresponding engine by querying the engine information table; 2) Based on the obtained engine identification code, query the server information table to obtain the server primary key and server memory configuration information that supports the engine; 3) Based on the obtained server primary key, obtain the lightweight success rate of each server model by searching the task information table; 4) Based on the obtained engine identification code and server primary key, the number of tasks currently being processed by the server is obtained by searching the cache structure.

[0010] Preferably, the weighted remaining 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 the number of tasks being processed by the server; 2) Based on the obtained total server memory and the calculated server memory usage, calculate the memory occupancy rate and the server's currently schedulable remaining computing power; 3) Based on the lightweight success rate weight factor and combined with the remaining computing power, the weighted remaining computing power is calculated.

[0011] Preferably, the server scheduling based on the calculated memory occupancy and weighted remaining computing power includes the following aspects: 1) Based on memory usage, select target servers using a preset threshold. 2) Based on the selected target servers, determine the optimal server based on the weighted remaining computing power; 3) Based on the optimal server, the BIM model lightweight task is distributed to the target server, and the task status in the task information table is updated synchronously.

[0012] The technology of the present invention can bring the following beneficial effects: (1) Resource utilization is significantly improved. By dynamically matching model resource consumption with the remaining computing power of the server, we can avoid large models failing due to insufficient resources or small models wasting memory, thereby improving the average memory utilization of the cluster.

[0013] (2) The success rate of task lightweighting has been significantly improved. For example, the weighted strategy prioritizes servers with a lightweighting success rate ≥ 95% for similar tasks, significantly reducing the failure rate of lightweighting the RVT model of a certain project.

[0014] (3) Real-time scheduling delay is greatly reduced. The response time of concurrent task number query based on cache can be controlled to millisecond level, supporting the immediate allocation of sudden tasks.

[0015] (4) The ability to adapt to heterogeneous environments is enhanced, and it is compatible with various mainstream model formats such as RVT, DGN, IFC, and various lightweight engines such as Bimface and Itwin, and dynamic adaptation is achieved through engine identification codes. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Hereinafter, some specific embodiments of the present invention will be described in detail in an illustrative and non-limiting manner with reference to the accompanying drawings.

[0017] Figure 1 This is a flow chart of an embodiment of a method for scheduling lightweight servers for heterogeneous BIM models according to the present invention; Figure 2 A schematic diagram showing the structural field design of the data storage structure engine information table according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure fields of the data storage structure server information table according to an embodiment of the present invention; Figure 4 Design a schematic diagram for the database task information table structure fields; Figure 5 This is a schematic diagram of initializing the engine information table data record; Figure 6 Schematic diagram of initializing the data record of the server information table; Figure 7 This is a diagram of data records in the task information table after receiving a task request; Figure 8 This is a schematic diagram of the system instantly updating data records in the task information table after task distribution in an embodiment of the present invention. DETAILED DESCRIPTION

[0018] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. The described embodiments are only part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0019] Explanation of terms: Lightweight engine: A tool used to compress and convert BIM models to reduce computing resource consumption, such as Bimface, which supports RVT format conversion, and Itwin, which supports DGN format conversion. Hutool: A Java-based tool library that provides general tools such as snowflake ID generation, file parsing, set operations, and date processing. Request: Network request object, used to transfer model files and parameters between the client and the server; Snowflake ID: A distributed unique identifier generation algorithm that generates a 64-bit unique code using factors such as timestamp and machine ID to ensure the uniqueness of task identifiers in a cluster environment. Redis: an open-source in-memory data storage system that supports high-performance key-value queries and is used to cache real-time task status. SCAN command: an iterator command provided by Redis, used to traverse a large number of keys without blocking the server; HTTP request: A network request based on the Hypertext Transfer Protocol (HTTP) used to transfer task data between the client and the server; File stream of a model file: refers to the binary data transmission form of a BIM model file, carried by the file stream field of an HTTP request, and used to transmit the original model data between the client and the server.

[0020] Example 1

[0021] See Figure 1 This embodiment provides a method for intelligent scheduling of lightweight servers for heterogeneous BIM models, including the following steps: Step S1: Construct a data storage structure, design an engine information table, a server information table, a task information table and a cache structure for storing task information in processing, and initialize the engine information table and the server information table.

[0022] In this embodiment, in order to realize intelligent scheduling of heterogeneous BIM model servers, it is necessary to design engine information tables, server information tables, task information tables and supporting cache structures to realize structured storage and efficient query of model resource consumption, server configuration, and historical task data. The data storage system includes three core data tables: Engine Information Table: This table records the lightweight engines corresponding to different model formats and their memory consumption. For example, it records that the unit memory consumption of an RVT model in the Bimface engine is 8.00GB. This table includes fields such as file extension, engine identification code, and unit memory consumption. It supports resource requirements statistics by model format and engine type.

[0023] Server Information Table: This table stores server hardware configuration, such as total memory and reserved memory, as well as network information such as the server IP address and service port. It also records the engine types supported by the server. For example, a server may have 32.00GB of total memory, 5.00GB of reserved memory, and the supported engine identifier is BIMFACE_001.

[0024] Task Information Table: This table records historical task execution data, including task status (e.g., whether lightweighting succeeded, failed, or is in progress), as well as information such as the task generation time, engine identification code, and server primary key. Using the server primary key and task generation time, you can query task information and count the total number of tasks within a predetermined timeframe. Furthermore, you can calculate the total number of successful lightweighting tasks based on the lightweighting success status of each task. Finally, you can calculate the success rate of lightweighting for a specific server model file. For example, you can calculate the success rate of lightweighting for the BIM-Server1 server model within the past hour.

[0025] In this embodiment, the three data tables are associated through the engine identification code and the server primary key. The engine information table is associated with the server information table through the engine identification code, and the server information table is associated with the task information table through the server primary key, supporting scheduling and tracing task history performance. Specifically: The engine information table and the server information table are associated through the engine identification code. The engine information table stores the mapping relationship between the model file suffix and the engine identification code, and records the unit task memory consumption; the server information table is associated with the engine information table through the foreign key engine identification code to record the total server memory and reserved memory space that supports the corresponding engine. When retrieving data, first obtain the engine identification code and unit task memory consumption from the engine information table through the model file suffix, and then filter out the servers that support the lightweight model of this format and their total memory and reserved memory space information from the server information table based on the engine identification code. This association mechanism realizes the three-level data mapping of "model format-engine-server", and can clearly support its lightweight server based on the model file format, and build a complete data link from model characteristics to server resources to support dynamic scheduling.

[0026] The server information table and the task information table establish a foreign key relationship through the server primary key. The task information table is linked to the server information table through the server primary key field, allowing access to information about all model file lightweighting tasks executed by that server, including task generation time and task status. The task generation time field allows filtering and querying task records within a predetermined timeframe, counting the total number of tasks within that timeframe. Simultaneously, the task status field filters out task records with a "Lightweight Successful" status and counts the total number of successful lightweighting tasks. Finally, a formula (e.g., total number of successful tasks / total number of tasks × 100%) is used to calculate the success rate of model file lightweighting for a specific server, allowing for tracing back the server executing the task and its reliability performance.

[0027] The following will be combined Figure 2 、 Figure 3 、 Figure 4 The following examples further illustrate the design of each data table field and cache structure of the database: 1. Engine information table, named analysis_manager_engine, is used to record the memory consumption of lightweight engines corresponding to different file suffixes. It supports statistical resource requirements by model format and engine type. The table contains the following fields: 1) Engine primary key field Field name: id; Data type: INT AUTO_INCREMENT; Primary key: Yes; Unique: Yes; Field description: Engine primary key, an auto-increment integer that uniquely identifies each record.

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

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

[0030] 4) Engine identification code field Field name: engine_code; Data type: VARCHAR(30) UNIQUE; Primary key: No; Unique: Yes; Field description: Engine identification code (such as BIMFACE_001, ITWIN_002), ensuring cross-table association consistency.

[0031] 5) Unit task memory consumption field 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.

[0032] 6) Creator field Field name: creator; Data type: VARCHAR(50); Is it the primary key: No; Is it unique: No; Field description: Creator's account.

[0033] 7) Create a time field Field name: create_time; Data type: DATETIME DEFAULT CURRENT_TIMESTAMP; Primary key: No; Unique: No; Field description: Creation time, default is current time.

[0034] 8) Updater field Field name: updater; Data type: VARCHAR(50); Is it a primary key: No; Is it unique: No; Field description: The account number of the person who last updated it.

[0035] 9) Update time field Field name: update_time; Data type: DATETIME ON UPDATE CURRENT_TIMESTAMP; Primary key: No; Unique: No; Field description: Last updated time, automatically refreshed when updated.

[0036] 10) Delete the status field Field name: delete_status; Data type: TINYINT(1) UNSIGNED; Is it a primary key: No; Is it unique: No; Field description: Deletion status, 0 means not deleted, 1 means deleted, the default is 0.

[0037] The deletion status field serves as a logical deletion indicator. 0 indicates that the record is valid, while 1 indicates that the record is logically invalid but retained in the database. This field is used for data auditing and accidental deletion recovery to prevent anomalies caused by physical deletion of associated data. In engine information queries, valid records are filtered by "delete_status=0".

[0038] 2. Server information table, named analysis_manager_server, is used to record the server's hardware configuration, network information, and engine, providing basic data for resource scheduling. The table contains the following fields: 1) Server primary key field Field name: id; Data type: INT AUTO_INCREMENT; Primary key: Yes; Unique: Yes; Field description: Server primary key, an auto-increment integer that uniquely identifies each server.

[0039] 2) Server Name Field Field name: server_name; Data type: VARCHAR(50); Is it a primary key: No; Is it unique: Yes; Field description: Server name, such as Server-01, BIM-Server.

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

[0041] 4) Total memory field 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.

[0042] 5) Reserved memory space field 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.

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

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

[0045] 8) Creator field Field name: creator; Data type: VARCHAR(50); Is it the primary key: No; Is it unique: No; Field description: Creator's account.

[0046] 9) Create a time field Field name: create_time; Data type: DATETIME DEFAULT CURRENT_TIMESTAMP; Primary key: No; Unique: No; Field description: Creation time, default is current time.

[0047] 10) Updater field Field name: updater; Data type: VARCHAR(50); Is it a primary key: No; Is it unique: No; Field description: The account number of the person who last updated it.

[0048] 11) Update time field Field name: update_time; Data type: DATETIME ON UPDATE CURRENT_TIMESTAMP; Primary key: No; Unique: No; Field description: Last updated time, automatically refreshed when updated.

[0049] 12) Delete the status field Field name: delete_status; Data type: TINYINT(1) UNSIGNED; Is it a primary key: No; Is it unique: No; Field description: Deletion status, 0 means not deleted, 1 means deleted, the default is 0.

[0050] The deletion status field serves as a logical deletion indicator. 0 indicates that the record is valid, while 1 indicates that the record is logically invalid but retained in the database. This field is used for data auditing and accidental deletion recovery to avoid anomalies caused by physical deletion of associated data. In server information queries, valid records are filtered by "delete_status=0".

[0051] 3. Task information table, named analysis_manager_task, is used to record historical data of task execution and provide a basis for calculating the lightweight success rate of the weighted scheduling algorithm. The table contains the following fields: 1) Task primary key field Field name: id; Data type: INT AUTO_INCREMENT; Primary key: Yes; Unique: Yes; Field description: Task primary key, an auto-increment integer that uniquely identifies each task record.

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

[0053] 3) Server primary key field 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, indicating the server number for processing the task.

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

[0055] 5) Task status field Field name: task_status; Data type: VARCHAR(20); Primary key: No; Unique: No; Field description: Task status (lightweight success, lightweight failure, queued, processing).

[0056] Task status (task_status) includes several states: Queued, Processing, Lightweight Success, and Lightweight Failure. Queued indicates the status of the initial record generated when receiving a task request; Processing indicates the status of task scheduling completion after the optimal service selection; Lightweight Success indicates the status of successful format conversion of the model file on the lightweight server; Lightweight Failure indicates the status of failed format conversion of the model file on the lightweight server.

[0057] 6) Task generation time field 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.

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

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

[0060] 9) Task lightweight time consumption field Field name: parse_duration; Data type: INT; Primary key: No; Unique: No; Field description: The duration of the lightweight task in milliseconds, used for performance analysis.

[0061] 10) Creator field Field name: creator; Data type: VARCHAR(50); Is it the primary key: No; Is it unique: No; Field description: Creator's account.

[0062] 11) Create a time field Field name: create_time; Data type: DATETIME DEFAULT CURRENT_TIMESTAMP; Primary key: No; Unique: No; Field description: Creation time, default is current time.

[0063] 4. Cache structure, used to store task information in processing.

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

[0065] A task goes through different stages in its lifecycle: When a task request is received, an initial record is generated and marked as "queued." After optimal server scheduling is complete, the record is updated to "processing." After the model file is formatted on the lightweight server, it is marked as "lightweight successful" or "lightweight failed" based on the result. Only tasks in the "processing" state need to reflect the current server load in real time. Therefore, these tasks are stored in a cache structure, enabling high-concurrency read and write with millisecond response times through in-memory databases (such as Redis and AMDC) or local caches (such as Java HashMap), ensuring efficient real-time monitoring of server load status.

[0066] In this embodiment, in order to achieve efficient statistics of tasks being processed within the server, a cache structure in the form of key-value pairs is designed to store information about tasks being processed. The cache structure in the form of key-value pairs usually has a KEY-VALUE format, where the key KEY is used as an index to achieve fast positioning, and the value VALUE stores the core information of the task in structured data.

[0067] The cache structure's key format uses a hierarchical naming convention, with the format being MODEL:POOL:{engineCode}:{serverId}:{taskId}, where engineCode corresponds to the engine identification code, serverId is the server primary key, and taskId is the task primary key. MODEL and POOL are custom prefixes. The former clarifies the business scenario of the cache and isolates the cached data from other non-model tasks; the latter reflects that a task enters the "processing" state after being dispatched to the server, where it is stored in the "pool" awaiting or executing processing. When the task is completed, it is removed from the cache pool. The double-layer prefix design of "MODEL" and "POOL" not only makes it easier for developers to quickly understand the meaning of data through KEY, but also supports the system to batch operate on similar data through prefix matching (such as MODEL:POOL:*), improving cache management efficiency.

[0068] Taking Redis as an example, you can run the SCANMODEL:POOL:{engineCode}:{serverId}:* command to iterate over keys matching the format. The result is the number of currently processing tasks for the specified server. Each task in the "processing" state generates a unique key in the format MODEL:POOL:{engineCode}:{serverId}:{taskId}. For example, if the engine code is BIMFACE_001, the server primary key is 101, and the task primary key is 20250520001, the corresponding key is MODEL:POOL:BIMFACE_001:101:20250520001. If the server is currently processing 10 tasks simultaneously, it will generate 10 keys ranging from MODEL:POOL:BIMFACE_001:101:20250520001 to MODEL:POOL:BIMFACE_001:101:202505200010, each corresponding to a task instance in the "processing" state. The Redis wildcard * character is used to match all task keys under the server. The number of traversal results reflects the number of tasks currently being processed by the server in real time.

[0069] This design ensures that N active tasks 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 them. A single SCAN operation is all that's needed to obtain the precise number of tasks, providing instant data support for the real-time computing power calculation in step S401 and avoiding the performance loss of multiple queries in traditional databases.

[0070] The cache structure's value VALUE stores core task information in structured data format, including fields such as the 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. The VALUE format is as follows: {"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"}.

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

[0072] This embodiment supports multiple relational databases for data storage, including but not limited to MySQL, SQL Server, Oracle, DM, and PolarDB, for persistent storage of structured data. The system implements data linkage by building a three-level association model (engine information table, server information table, and task information table). Each table is linked using foreign key fields such as the engine identifier and server primary key.

[0073] During the system initialization phase, basic data must be entered through the management interface. This includes engine information such as the Bimface engine's supported file extensions and unit task memory consumption, as well as server information such as total memory, reserved memory space, server IP address, and service port. This data forms the foundation 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 process. The following is an example of initializing the engine information table and server information table.

[0074] like Figure 5 The following is a diagram of data records in the engine information table, one of which has the following records: the file suffix is ​​rvt, the engine name is Bimface, the engine identification code is BIMFACE_001, and the unit task memory consumption is 8.00 GB.

[0075] like Figure 6 The following is a diagram of data records in the server information table, one of which has the following records: the server primary key is 101, the server name is BIM-Server1, the engine identification code is BIMFACE_001, the total memory is 32.00GB, the reserved memory space is 5.00GB, the service IP address is 192.168.1.97, and the service port is 8080.

[0076] Step S2: The parsing module receives the BIM model lightweight 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 together with the task name, task status and task generation time automatically generated by the system to generate an initial task record.

[0077] In this embodiment, when the system's parsing module receives a BIM model lightweight task request, it will automatically generate a task name, task status, and task generation time, and extract the file stream of the model file from the Request object based on the HTTP request protocol, parse the model file name and suffix from the file stream, and then query the engine information table based on the suffix to obtain the corresponding engine identification code. Finally, the parsed model file name and suffix, the queried engine identification code, and the task name, task status, and task generation time automatically generated by the system are entered into the task information table to generate an initial task record.

[0078] The following examples illustrate this.

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

[0080] The task name can use the "Lightweight_Snowflake ID" format, where the snowflake ID can be generated through the IdUtil.getSnowflake() method of the Hutool component to ensure global uniqueness.

[0081] The task status (task_status) includes several states, such as queued, processing, lightweighting successful, lightweighting failed, etc. Every time the system receives a BIM model lightweighting task request, the task status is initialized to "queued", indicating that the task is waiting to be scheduled.

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

[0083] To parse the file stream of the model file, you can use the Hutool tool component of the Java programming language to call its file processing method FileUtil.getSuffix() to parse the model file name and suffix from the file stream, and query the engine information table based on the suffix to obtain the corresponding engine identification code. Figure 5 As shown, the suffix of the file name Project.rvt is rvt, the engine name is Bimface, and the engine identification code is BIMFACE_001.

[0084] After parsing the model file name and suffix, as well as the queried engine identification code, they are entered into the task information table together with the task name, task status, and task generation time automatically generated by the system to generate an initial task record.

[0085] The above is the process of generating an initial record for a model request task. The system needs to generate an initialization record according to the above process for each model request task it receives. Figure 7 The following table shows the information data records of all task requests received by the system, which records the task primary key, engine identification code, task name, task status, task generation time, file name, and suffix.

[0086] It should be noted that: Figure 7 When the initial task record is generated, the server primary key field in the task information table is empty, and the task status is marked as "Queued." After the optimal server is assigned in step S5, the system updates the assigned server primary key in the task information table, simultaneously 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, it updates the task status based on the results: if lightweighting is successful, the task status is updated to "Lightweight Successful"; if it fails, the task status is updated to "Lightweight Failed." This process ensures that the task information table reflects the task scheduling progress and execution results in real time.

[0087] Step S3: For model lightweighting requests, 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 the server information table based on the engine identification code, obtains the total number of server tasks and the number of successful lightweight tasks from the task information table and calculates the lightweight success rate, and obtains the number of tasks in processing from the cache structure.

[0088] In this embodiment, the pre-processing module starts the data acquisition process based on the engine identification code obtained in step S2: 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. Server memory configuration information includes total memory and reserved memory space, and server network information includes server IP address and service port. At the same time, extract the task records of the server associated with the engine identification code within the scheduled time from the task information table, filter and count the total number of tasks and the total number of lightweight successful tasks by task status, and calculate the lightweight success rate; In addition, the number of keys of the tasks being processed is scanned from the cache structure of the in-memory database to count the number of tasks being processed.

[0089] It should be noted that the system must perform the above process in a loop for each task. For each lightweight task, the pre-processing module will independently execute the complete process of querying the unit task memory consumption, obtaining server memory configuration information and network information, calculating the lightweight success rate, and counting the number of tasks in processing. Through this loop processing mechanism for a single task, the system can generate a unique resource evaluation data set 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 when processing multiple tasks concurrently.

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

[0091] The specific steps include: S301: Based on the engine identification code obtained in step S2, the unit task memory consumption of the corresponding engine is obtained by querying the engine information table.

[0092] In this embodiment, based on the engine identification 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 demand for server memory resources occupied by a single BIM model lightweight task.

[0093] In this embodiment, the engine identification code and deletion status are used as filtering conditions to execute 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 to implement data retrieval. The meaning of this statement is: The query matches the engine identification code determined in step S2 through the engine_code field and filters out valid records through delete_status=0. Finally, it returns a complete data record containing the engine primary key, file suffix, engine name, and unit task memory consumption.

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

[0095] S302: Based on the engine identification code obtained in step S2, the server information table is queried to obtain the server primary key, server memory configuration information, and network information that supports the engine.

[0096] In this embodiment, based on the engine identification code obtained in step S2, the server information table is queried to obtain the memory configuration and network information of the server supporting the engine. This process uses the engine identification code to extract key parameters such as total memory, reserved memory space, server IP address, and service port from the server information table. These parameters are used in the calculation process in step S4 and provide basic data for task scheduling in step S5.

[0097] In this embodiment, the engine identification code and deletion status are used as filtering conditions to execute 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 to implement data retrieval. The meaning of this statement is: The query matches the engine identification code determined in step S2 through the engine_code field, filters out valid records through delete_status=0, and finally returns a complete data list including the server primary key, server name, memory configuration, and network address.

[0098] like Figure 6 As shown, when the engine identification code is BIMFACE_001, executing the above SQL query will obtain 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 are 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.

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

[0100] In this embodiment, based on the server primary key set obtained in step S302, the task information table is retrieved to calculate the model lightweighting success rate for each server within a predetermined time (e.g., one hour). This process distinguishes lightweighting success and lightweighting failure records based on task status, and calculates the lightweighting success rate based on server grouping. This provides a basis for evaluating server historical performance for subsequent S5 dynamic scheduling. The predetermined time can be customized by the user.

[0101] In this example, the server primary key set and task generation time are used as filtering conditions, and the scheduled 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 implement data retrieval. The meaning of this statement is: This query matches the target server through server_id IN (${serverIds}), filters task records within the past hour through parse_time>=DATE_SUB(NOW(), INTERVAL 1 HOUR), and returns a complete data list including fields such as task status and server primary key.

[0102] like Figure 7 As shown, assuming that after executing the query, 200 task records of the server pointed to by the server primary key 101 with the engine identification code BIMFACE_001 and 150 task records of the server pointed to by the server primary key 102 are obtained. After grouping by server_id through CollUtil.groupBy() of the Hutool toolkit, statistics are performed on each group of tasks: Among the 200 records of the server pointed to by server primary key 101, 190 have a task status of "Lightweight Successful", and the lightweight success rate is 190 / 200 × 100% = 95%; Among the 150 records of the server pointed to by the server primary key 102, 135 have a task status of "lightweight success", and the lightweight success rate is 135 / 150×100%=90%.

[0103] The calculation result is associated with the server primary key through successRateMap (such as {101: 0.95, 102: 0.90}).

[0104] S304: Based on the engine identification code 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.

[0105] In this embodiment, based on the engine identification 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 the cache structure. This process can match real-time task records by constructing a cache key.

[0106] 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 primary key. The Redis SCAN command or keys method is used to iteratively match the task key currently being processed. The execution logic is as follows: Map<Integer, Integer> concurrentTaskMap = new HashMap<>(); serverList.forEach(server ->{ String keyPattern="MODEL:POOL:" +engineCode+":"+server.getServerId()+":*"; Set <string>keys=redisTemplate.keys(keyPattern); concurrentTaskMap.put(server.getServerId(), CollUtil.size(keys));}).

[0107] This method can be used to obtain the number of tasks currently in the "processing" state on each server in real time.

[0108] Assuming the engine identification code is BIMFACE_001, the server primary key 101 obtained in step S302 and the server pointed to by the server primary key 102 may yield the following after executing the above logic: The server primary key 101 points to has 3 matching keys, which means there are currently 3 tasks being processed. The server primary key 102 points to has 2 matching keys, which means there are currently 2 tasks being processed.

[0109] This parameter will be used in the calculation process in step S4 to assist in determining the server load status and optimizing the scheduling strategy.

[0110] Step S4: The calculation module calculates the real-time memory usage, memory occupancy rate, and remaining computing power based on the unit task memory consumption, server memory configuration, lightweight success rate, and the number of tasks being processed, and determines the weight factor according to the lightweight success rate to obtain the weighted remaining computing power.

[0111] In this embodiment, the calculation module quantifies the server's real-time load and available resources through mathematical modeling based on the data extracted in step S3, such as the unit task memory consumption, the total server memory and reserved space, the number of tasks being processed, and the lightweight success rate, providing a quantitative basis for the server intelligent scheduling in step S5. The specific process is as follows: First, calculate the memory usage by "number of tasks being processed × memory consumption per task + reserved memory space"; Secondly, the memory usage is calculated as "memory usage / total memory × 100%" to screen qualified servers whose memory load does not exceed the threshold. Next, calculate the remaining computing power according to "total memory - memory usage"; Then, the weight factor is determined according to the lightweight success rate; Finally, the weighted remaining computing power is obtained by "weight factor × remaining computing power". It is used as the core parameter for scheduling and sorting. It combines the server's remaining computing power with historical processing performance to implement a dynamic scheduling strategy of "load priority + historical performance weighting".

[0112] It should be noted that the system needs to process each task in a loop according to the above process. That is, every time a task enters the calculation phase, the calculation module will extract data such as unit task memory consumption, total server memory, reserved memory space, number of tasks being processed, and lightweight success rate for the server associated with the task in real time, and independently execute the complete calculation process of memory usage, memory occupancy, remaining computing power, and weighted remaining computing power. When multiple tasks enter concurrently, the calculation module will complete the above calculations for each task in turn, ensuring that the scheduling decision of each task is based on the latest load status and historical performance data of the current server, ensuring efficient utilization of server resources and balanced task processing.

[0113] The specific steps include: S401: Calculate the server memory usage based on the unit task memory consumption, server reserved space and the number of tasks being processed by the server obtained in step S3.

[0114] 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 server's real-time memory usage 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 to quantify the current server load.

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

[0116] 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 free memory resources, i.e., the remaining computing power.

[0117] In this embodiment, based on the total server memory obtained in step S302 and the memory usage calculated in step S401, the server's current load is calculated using the formula: Memory occupancy = 100% × memory usage / total memory. This metric quantifies memory resource usage as a percentage and is used to determine whether the server is within its normal operating load range, providing a key basis for scheduling decisions.

[0118] In this example, assuming the total server memory obtained in step S302 is 32.00 GB and the memory usage calculated in step S401 is 21.00 GB, the memory utilization ratio is 100% × 21.00 GB / 32.00 GB = 65.625%. If the system sets the memory utilization ratio threshold at 95%, the server is currently within the normal load range (65.625% < 95%) and can safely accept new scheduled tasks. If the threshold is exceeded, current limiting or load balancing policies are triggered to ensure stable server operation.

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

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

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

[0122] By dynamically adjusting the weight factor based on the lightweight success rate of the task and combining it with the remaining computing power to calculate the weighted remaining computing power, we can prioritize historically reliable servers. In this embodiment, the weight factor is determined by "Lightweight Success Rate > A?B1:B2", where A is the preset threshold and B1 and B2 are preset weight factors, which can be selected by the user. This embodiment introduces a dynamic weighting factor for lightweighting success rate adjustment. The weighting factor is determined according to the formula "Weighting factor = Lightweighting success rate > 95% × 1.1:1.0," where "95%" is the preset threshold selected for this embodiment, "1.1" and "1.0" are the preset weighting factors selected for this embodiment, and "Lightweighting success rate" is the server's lightweighting success rate for tasks within the past hour, with "1 hour" being the predetermined time period selected for this embodiment. This rule assigns a weighting factor of 1.1 to servers with a lightweighting success rate of 95% or higher in the past hour, and uses the default value of 1.0 otherwise. The server's real-time available resources are then calculated using the formula "Weighted remaining computing power = Weighting factor × remaining computing power." This combines the server's real-time memory resources with its historical performance to form a comprehensive scheduling indicator.

[0123] For example: If the success rate of model lightweighting of a certain server obtained from step S303 in the recent 1 hour is 50%, since it does not meet the condition of ">95%", the weight factor is determined to be 1.0; if the remaining computing power calculated in step S403 is 11.00GB, then the weighted remaining computing power = 1.0×11.00GB = 11.00GB. If the success rate of model lightweighting of another server in the recent 1 hour is 98%, which meets the threshold condition, 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 preferentially select the server with higher weighted remaining computing power, taking into account both the current memory resources and reflecting the resource tilt towards the servers that have been running stably historically.

[0124] It should be noted that the above weight factor rules are just an example. In actual applications, other rules can be selected or customized according to business requirements, such as: 1) Determining the weight factor by the linear gradient weighting method: Determine the weight factor with the formula "B + (success rate of lightweighting - A) × C", where A is the preset threshold, B is the preset basic weight, and C is the preset fitting coefficient, which can be actually selected according to the user.

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

[0126] 2) Determining the weight factor by the piecewise step weighting method: Divide the gradient intervals according to the success rate and set different weights. When the success rate of lightweighting >= A1, the weight factor is B1; when the success rate of lightweighting >= A2 but < A1, the weight factor is B2; when the success rate of lightweighting < A2, the weight factor is B3. Where A1 and A2 are the preset thresholds, and B1, B2, and B3 are the preset weight factors, and A1 > A2, which can be actually selected according to the user.

[0127] 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 success rate of lightweighting is 90%, the weight factor is determined to be 1.0; when the success rate of lightweighting is 95%, the weight factor is determined to be 1.1; when the success rate of lightweighting is 98%, the weight factor is determined to be 1.2.

[0128] 3) Determining the weight factor by the dynamic floating weighting method: The weight factor is determined using the formula "Lightweight success rate > A × F + D1:F - D2", and upper and lower limits are set for the weight factor, where A is the preset threshold, F is the current baseline weight, D1 is the preset upward adjustment factor, and D2 is the preset downward adjustment factor. The actual adjustment can be made by the user. For example, if the preset threshold is 95%, the baseline weight is 1.1, the upward adjustment factor is 0.05, the downward adjustment factor is 0.1, and the lower limit of the weight factor is no less than 1.0 and the upper limit is no more than 1.5. If the lightweighting success rate is 96%, the weight factor is 1.15 according to the formula "Lightweighting success rate > 95% × 1.1 + 0.05: 1.1 - 0.1." If the lightweighting success rate is 94%, the weight factor is 1.0 according to the formula "Lightweighting success rate > 95% × 1.1 + 0.05: 1.1 - 0.1."

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

[0130] In this embodiment, the scheduling module first filters out servers below the threshold based on memory occupancy and preset thresholds, then selects the server 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.

[0131] This step, as the server intelligent scheduling link, determines the optimal server based on the memory usage and weighted remaining computing power calculated in step S4 through the dual strategy of "first screening the load, then optimizing the performance", thus realizing the implementation from data indicators to scheduling decisions.

[0132] In this embodiment, the scheduling module implements intelligent server scheduling through a three-step process: First, servers with memory usage below the preset threshold are filtered and included in the candidate pool, excluding high-load devices; 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; 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, forming a complete closed loop of "scheduling decision-execution feedback".

[0133] It's important to note that the system loops through the above process for each task. That is, each time a task enters the scheduling phase, the scheduling module independently executes the complete three-step process. Through this loop-based scheduling mechanism for single tasks, each task receives its own dedicated "screening-sorting-allocation-feedback" process. This ensures that, in multi-task concurrent scenarios, each scheduling decision is based on the optimal match between the server's real-time load and historical performance. This creates a closed-loop management system from task entry to resource allocation, guaranteeing the efficiency, accuracy, and traceability of intelligent server scheduling.

[0134] The complete triple process includes the following steps: S501: Filter target servers based on memory usage using a preset threshold.

[0135] 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 filtered using whether the memory utilization is below the threshold as a screening criterion. Servers with utilization rates below the threshold are added to the candidate pool, while servers with utilization rates above or equal to the threshold are excluded from task allocation. This strategy ensures that tasks are only assigned to servers that are not near resource bottlenecks, preventing task failures or system stability degradation due to overload.

[0136] In this example, assuming the memory usage threshold is 95%, step S402 calculates that the memory usage of the server pointed to by server 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 usage of the server pointed to by server key 102 is 96%, it is automatically excluded because it exceeds the threshold. Through this screening mechanism, the system can dynamically filter out high-load devices, providing a safe and reliable server list for subsequent task allocation.

[0137] S502: Determine the optimal server based on the weighted remaining computing power according to the selected target servers.

[0138] In this embodiment, the list of candidate servers screened in step S501 is sorted in descending order by weighted remaining computing power to determine the optimal server. Specifically, the CollUtil.sort tool is used to sort the candidate servers from high to low based on the weighted remaining computing power calculated in step S404, ultimately selecting the server with the highest weighted remaining computing power as the target for task allocation. This strategy combines the server's real-time remaining memory with the lightweight success rate, prioritizing devices with sufficient resources and stable performance to achieve optimal task allocation decisions.

[0139] 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 servers with better overall performance have a differentiated advantage in terms of numerical value.

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

[0141] This dynamic calculation mechanism, embedded in each task cycle, ensures that even if multiple servers have similar raw remaining computing power, servers with better historical performance will receive priority in assignments due to the tilted weighting factors. For example, if a server has a 98% lightweight success rate, but triggers a weighting factor of 1.1, its weighted remaining computing power will be higher due to the tilted weighting, even if its remaining computing power is similar to that of other servers, thus receiving priority in task assignments. Through this dynamic calculation, sorting, and selection mechanism within each task cycle, the system can accurately locate the target server with the best overall performance, ensuring the rationality and efficiency of task assignments.

[0142] S503: Based on the optimal server, the BIM model lightweight task is distributed to the target server, and the task status in the task information table is updated synchronously.

[0143] 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 lightweight task is dispatched to the target server via HTTP, and the task status in the task information table is simultaneously updated. Specifically, an HTTP request (e.g., 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," triggering the lightweight processing flow. Simultaneously, the status field of the corresponding record in the task information table is updated to "Processing," and the dispatch time and server ID 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, the scheduling request path is: http: / / 192.168.1.100:8080 / api / lightweight. The request parameters include the model file binary stream and metadata such as the task primary key and file extension (e.g., in JSON format).

[0144] After the task is distributed, the system immediately updates the task information table: Figure 8 As shown in the figure, the status of the record with the task primary key 207 is changed from "Queued" to "Processing," and the server primary key is filled in with 101, forming a complete closed loop of "scheduling decision-task execution-status synchronization." This operation not only ensures correct task execution on the server, but also provides accurate status information for subsequent monitoring and log analysis.

[0145] Example 2

[0146] This embodiment also provides a lightweight server intelligent scheduling system for heterogeneous BIM models, which includes: 1) Data storage structure, including engine information table, server information table, task information table and cache structure for storing task information in progress; 2) The parsing module is used to receive model lightweighting requests, 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) A preprocessing module is used to start the data acquisition process based on the engine identification code, obtain 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 progress from the cache structure; 4) The calculation module is used to calculate memory usage, memory occupancy, and remaining computing power based on the unit task memory consumption, server memory configuration, lightweight success rate, and the number of tasks being processed. The weight factor is determined according to the lightweight success rate to obtain the weighted remaining computing power. 5) Server scheduling module, which is used to implement server scheduling based on the calculated memory usage and weighted remaining computing power.

[0147] The calculation module includes: 1) The unit task memory consumption acquisition submodule is used to obtain the unit task memory consumption of the corresponding engine by querying the engine information table based on the obtained engine identification code; 2) The server memory configuration information acquisition submodule is used to obtain the server primary key and server memory configuration information that supports the engine by querying the server information table based on the obtained engine identification code; 3) The task processing success rate acquisition submodule is used to obtain the lightweight success rate of each server model by searching the task information table based on the obtained server primary key; 4) The submodule for obtaining the number of tasks being processed is used to obtain the number of tasks currently being processed by the server by retrieving the cache structure based on the obtained engine identification code and server primary key.

[0148] Example 3

[0149] This embodiment provides an electronic device, including: Memory for storing computer programs; The processor is used to execute the program stored in the memory to implement the steps of the above embodiment of the intelligent scheduling method for lightweight servers of heterogeneous BIM models.

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

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

[0152] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, and discrete hardware components.

[0153] Example 4

[0154] The present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements each step of the aforementioned method for intelligent scheduling of lightweight servers for heterogeneous BIM models. The specific implementation of each step of the method and related explanations can be found in the aforementioned method for intelligent scheduling of lightweight servers for heterogeneous BIM models, and are not further described here.

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

[0156] In particular, for the embodiments of the device, electronic device, and computer-readable storage medium, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments.

[0157] The foregoing is merely an embodiment of the present invention and is not intended to limit the present invention. It will be apparent to those skilled in the art that various modifications and variations of the present invention are possible. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention are intended to 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 by It includes the following aspects: 1) building a data storage structure, designing the engine information table, server information table, task information table and the cache structure for storing the task information being processed, and initializing the engine information table and server information table; 2) Receive the model lightweight request, extract the model file and parse it, 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 progress from the cache structure; 4) Based on the unit task memory consumption, server memory configuration, lightweight success rate and the number of tasks being processed, calculate the memory usage, memory occupancy rate and remaining computing power. Determine the weight factor based on the lightweight success rate to obtain the weighted remaining computing power. 5) Implement server scheduling based on the calculated memory usage and weighted remaining computing power.

2. The intelligent scheduling method for lightweight servers of heterogeneous BIM models according to claim 1, characterized in that: The engine information table includes the model file suffix, engine identification code, and unit task memory consumption field; the server information table includes the server primary key, engine identification code, total memory, reserved memory space value, service IP address, and service port field; the task information table includes the server primary key, engine identification code, task status, and task generation time field.

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

4. The intelligent scheduling method for lightweight servers of heterogeneous BIM models according to claim 1, characterized in that: The weighted remaining 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 the number of tasks being processed by the server; 2) Based on the obtained total server memory and the calculated server memory usage, calculate the memory occupancy rate and the server's currently schedulable remaining computing power; 3) Based on the lightweight success rate weight factor and combined with the remaining computing power, the weighted remaining computing power is calculated.

5. The intelligent scheduling method for lightweight servers of heterogeneous BIM models according to claim 1, characterized in that: The server scheduling based on the calculated memory occupancy and weighted remaining computing power includes the following aspects: 1) Based on memory usage, select target servers using a preset threshold. 2) Based on the selected target servers, determine the optimal server based on the weighted remaining computing power; 3) Based on the optimal server, the BIM model lightweight task is distributed to the target server, and the task status in the task information table is updated synchronously.

6. A lightweight server intelligent scheduling system for heterogeneous BIM models, characterized by: include: 1) Data storage structure, including engine information table, server information table, task information table and cache structure for storing task information in progress; 2) The parsing module is used to receive model lightweighting requests, 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) A preprocessing module is used to start the data acquisition process based on the engine identification code, obtain 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 progress from the cache structure; 4) The calculation module is used to calculate memory usage, memory occupancy, and remaining computing power based on the unit task memory consumption, server memory configuration, lightweight success rate, and the number of tasks being processed. The weight factor is determined according to the lightweight success rate to obtain the weighted remaining computing power. 5) Server scheduling module, which is used to implement server scheduling based on the calculated memory usage and weighted remaining computing power.

7. The intelligent scheduling system for lightweight servers of heterogeneous BIM models according to claim 6, characterized in that: The engine information table includes the model file suffix, engine identification code, and unit task memory consumption field; the server information table includes the server primary key, engine identification code, total memory, reserved memory space value, service IP address, and service port field; the task information table includes the server primary key, engine identification code, task status, and task generation time field.

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

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

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

Images