Method and apparatus for rendering a document

Abstract

This disclosure provides a method and apparatus for rendering documents, relating to the field of large model technology, and particularly to the field of document rendering technology. The specific implementation scheme is as follows: in response to receiving a document rendering request, the complexity of the document is determined based on its content features; a target rendering engine is determined from a set of candidate rendering engines based on the complexity; and the document is rendered based on the target rendering engine.

Description

Technical Field

[0001] This disclosure relates to the field of large model technology, and more particularly to the field of document rendering technology, specifically a method and apparatus for rendering documents. Background Technology

[0002] There are various document formats online, and the rendering service needs to dynamically select the optimal rendering strategy (i.e., rendering engine) for different document formats. The existing system uses static routing (fixed allocation of rendering strategy), which cannot dynamically schedule according to the complexity of document content, resulting in the dual problems of rendering timeouts for high-complexity documents and wasting resources for low-complexity documents. Summary of the Invention

[0003] This disclosure provides a method, apparatus, device, storage medium, and computer program product for rendering documents.

[0004] According to a first aspect of this disclosure, a method for rendering a document is provided, comprising: in response to receiving a rendering request for a document, determining the complexity of the document based on the content features of the document; determining a target rendering engine from a set of candidate rendering engines based on the complexity; and rendering the document based on the target rendering engine.

[0005] According to a second aspect of this disclosure, an apparatus for rendering a document is provided, comprising: a computing unit configured to determine the complexity of a document based on content features of the document in response to receiving a rendering request for the document; a scheduling unit configured to determine a target rendering engine from a set of candidate rendering engines based on the complexity; and a rendering unit configured to render the document based on the target rendering engine.

[0006] According to a third aspect of this disclosure, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method described in any one of the first aspects.

[0007] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to perform the method described in any one of the first aspects.

[0008] According to a fifth aspect of this disclosure, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the method described in any one of the first aspects.

[0009] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0010] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 This is an exemplary system architecture diagram to which one embodiment of this disclosure can be applied; Figure 2 This is a flowchart of one embodiment of a method for rendering documents according to this disclosure; Figure 3 This is a schematic diagram illustrating an application scenario of the document rendering method according to this disclosure; Figure 4 This is a flowchart of yet another embodiment of the method for rendering documents according to this disclosure; Figure 5 This is a schematic diagram of a structure of an embodiment of a document rendering apparatus according to the present disclosure; Figure 6 This is a schematic diagram of the structure of a computer system suitable for implementing embodiments of the present disclosure. Detailed Implementation

[0011] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0012] Figure 1 An exemplary system architecture is shown, illustrating an embodiment of a method or apparatus for rendering documents to which the present disclosure may be applied.

[0013] like Figure 1 As shown, the system architecture may include terminal devices 101, 102 and 103, and server 104.

[0014] Terminal devices 101, 102, and 103 send rendering requests to server 104. These rendering requests may include document content, document name, document format, and terminal device information. Server 104 renders the document content into a document file of the specified document format according to the rendering requests and then returns it to terminal devices 101, 102, and 103.

[0015] Users can use terminal devices 101, 102, and 103 to interact with server 104 via the network to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as AI tools, 3D video players, web browser applications, shopping applications, search applications, instant messaging tools, email clients, social media platform software, etc.

[0016] Terminal devices 101, 102, and 103 can be either hardware or software. When terminal devices 101, 102, and 103 are hardware, they can be various electronic devices that support document processing, including but not limited to smartphones, tablets, e-book readers, MP3 players (Moving Picture Experts Group Audio Layer III), MP4 players (Moving Picture Experts Group Audio Layer IV), laptops, and desktop computers, etc. When terminal devices 101, 102, and 103 are software, they can be installed in the aforementioned electronic devices. They can be implemented as multiple software programs or software modules (e.g., to provide distributed services) or as a single software program or software module. No specific limitations are imposed here.

[0017] Server 104 can be a server that provides various services, such as a rendering server that provides rendering services for documents displayed on terminal devices 101, 102, and 103.

[0018] Server 104 comprises an access layer, a complexity modeling layer, a scheduling decision layer, and a rendering resource layer. Its specific functions are as follows: 1. Access Layer After receiving a document rendering request from a terminal device, the rendering request router checks its cache for the document's content characteristics. If found, the document can be used directly.

[0019] 2. Complexity Modeling Layer

[0020] If no content features of the document are found, the content features of the document are obtained through two-stage streaming parsing: number of text characters, number of images, table depth, formula density, and number of nested objects.

[0021] Then calculate the complexity based on the content characteristics of the document.

[0022] 3. Scheduling Decision-Making Level

[0023] The weights of different performance metrics are determined based on complexity. The performance metrics include at least one of the following: document format compatibility, load idleness, and historical rendering success rate.

[0024] For each candidate rendering engine, the performance of the candidate rendering engine is determined by the weighted sum of its various performance metrics. The candidate rendering engine with the highest performance is selected as the target rendering engine.

[0025] 4. Rendering resource layer

[0026] Select an available instance from the instance pool of the target rendering engine to render the document.

[0027] Optionally, the system may also include the following modules: 1. Front-end rendering version caching module The rendered document is stored in the browser's local database. The next time the same document is opened, the local cache is read first, without requesting the backend rendering service, resulting in instant opening, faster speed, and reduced backend pressure. The cache key is generated using SHA-256 hash encryption to ensure uniqueness and no conflicts. When the document content changes or the version is updated, the cache is automatically invalidated and cleared, and old content will not be displayed.

[0028] 2. Network quality perception feedback module

[0029] It monitors network latency and uplink / downlink bandwidth in real time and dynamically adjusts the weighting coefficients of performance metrics. It automatically switches to a lightweight rendering engine when the network is weak and to a high-performance rendering engine when the WiFi signal is strong.

[0030] 3. Content-aware skeleton screen module

[0031] Traditional skeleton screens use fixed, rigid rectangular frames, which are different from the layout of real documents; Now, the server analyzes the document structure in advance and generates dedicated descriptive data SkeletonMeta. Based on this data, the front-end creates a customized skeleton that matches the actual text, images, tables, and paragraph structures. CLS (Layout Offset) is significantly reduced, eliminating the jumpy problem of "first messing up the frames, then suddenly misaligning the layout".

[0032] 4. Slice Priority Rendering Queue Module

[0033] Break long documents down into numerous "content chunks" instead of rendering them all at once; Prioritize the slices based on viewport visibility, interactivity, and natural order.

[0034] Leveraging native browser capabilities rAF (frame animation) and rIC (idle callback), tasks are performed off-peak without blocking the page. When scrolling, priorities are reordered in real-time to ensure the content in front of you appears fastest. LCP (maximum content rendering) has been significantly optimized, resulting in faster rendering of images and text for core homepage content.

[0035] It should be noted that the document rendering method provided in the embodiments of this disclosure is generally executed by a server, and correspondingly, the document rendering apparatus is generally located in the server.

[0036] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0037] Continue to refer to Figure 2 The diagram illustrates a flow 200 of an embodiment of a method for rendering a document according to the present disclosure. The method for rendering a document includes the following steps: Step 201: In response to receiving a document rendering request, determine the document's complexity based on the document's content features.

[0038] In this embodiment, the execution body of the document rendering method (e.g.) Figure 1 The server shown can receive document rendering requests from terminal devices via wired or wireless connections.

[0039] You can retrieve the content features of previously parsed documents from the cache, or re-parse the content features of documents.

[0040] Document content features may include: text word count, number of images, table depth, formula density, and number of nested objects. These correspond to the content feature vector CC = [C_text, C_img, C_table, C_formula, C_embed].

[0041] Automatic extraction of document content features: C_text is achieved through token counting; C_img is achieved through the document's XML... <draw:image>Tag counting is implemented; C_table is implemented by parsing the nested table depth (BFS calculates the maximum depth); C_formula is implemented by calculating the tag density using MathML / LaTeX; C_embed is implemented by counting nested frame / iframe objects.

[0042] The complexity of a document can be considered as a weighted sum of its various content features: CCS = w1·C_text + w2·C_img + w3·C_table + w4·C_formula + w5·C_embed The weight vector W = [0.15, 0.25, 0.20, 0.25, 0.15] can be obtained by offline fitting of historical rendering time data. This is just an example and is not limited to this in practice.

[0043] Step 202: Determine the target rendering engine from the set of candidate rendering engines based on complexity.

[0044] In this embodiment, the rendering engines in the candidate rendering engine set can be renderers for large models, also known as rendering strategies. A high-performance rendering engine can be selected for highly complex documents, while a lightweight rendering engine can be selected for less complex documents.

[0045] Step 203: Render the document based on the target rendering engine.

[0046] In this embodiment, document data and rendering instructions are sent to the selected target rendering engine instance, and the engine performs rendering according to its own adaptation logic: The lightweight engine performs lightweight full rendering without enabling optimization logic such as fragmentation and caching, quickly completing the rendering of simple documents; The high-performance engine enables priority rendering of slices, content-aware skeleton screens, and front-end rendering version caching optimization strategies. It performs hierarchical rendering based on viewport visibility, synchronously records the success rate of this rendering, and updates the historical success rate.

[0047] After rendering is complete, the rendering result is returned to the requesting end. In weak network environments, the network quality perception feedback module is linked to automatically switch between lightweight or high-fidelity rendering modes.

[0048] The method provided in the above embodiments of this disclosure achieves dynamic optimization of the rendering engine by using content features to drive complexity determination. Compared with the traditional static routing scheme, it reduces the rendering timeout rate of heavy and complex documents, improves the resource utilization of lightweight documents, and is compatible with both new and old document formats, supporting smooth switching without anomalies.

[0049] In some optional implementations of this embodiment, determining the document's complexity based on its content features includes: querying the document's content features in a cache, wherein the lifespan of the document's content features in the cache is positively correlated with the number of times the document is accessed. In response to a query failure, the document's complexity is determined based on the content features parsed from the document, and the content features are stored in the cache.

[0050] Popular documents: A higher AHC (Accumulated Hit Count) means a longer TTL (Time To Live), thus allowing them to be cached for longer. For less frequently used documents (small AHC values), the TTL is short, so the cache should be cleared as soon as possible.

[0051] reason: Popular documents are accessed frequently, so the cache is effective for a long time and has a high hit rate.

[0052] Unpopular documents are rarely accessed, so there is no need to occupy cache space.

[0053] The linkage between TTL and AHC: TTL = TTL_base × (1 + λ × ln(1 + AHC)) = 300s × (1 + 0.5 × ln(1 + AHC)) Unpopular document (AHC = 1, almost no one reads it): TTL = 405 seconds ≈ 6.7 minutes Regular document (AHC = 10): TTL = 660 seconds ≈ 11 minutes Popular documents (AHC = 1000): TTL = 1338 seconds ≈ 22 minutes A cache hit means that the document's content features have already been calculated and saved, so they can be used directly this time, skipping the parsing step and resulting in near-zero scheduling latency. A cache miss is when a two-stage parsing process (a fast path of ≤5ms) is triggered. A higher hit rate results in better overall scheduling performance.

[0054] This embodiment first queries the document content features in the cache and sets the TTL of the content features in the cache to be positively correlated with the number of document accesses. The more frequently a document is accessed, the longer the validity period of the content feature cache is, which can continuously hit the cache and reduce repeated parsing calculations. When the cache query misses, the document content features are parsed and extracted in real time and the complexity is determined. At the same time, the content features are written back to the cache, thus building an efficient mechanism of prioritizing cache hits, real-time parsing when a cache miss occurs, and automatic backfilling.

[0055] In some optional implementations of this embodiment, determining the document complexity based on the content features parsed from the document includes: parsing local content of the document to obtain local content features of the document; determining the local complexity of the document based on the local content features; and using the local complexity as the document complexity in response to the local complexity being less than a first threshold or greater than a second threshold, wherein the first threshold is less than the second threshold.

[0056] To avoid scheduling delays caused by parsing the entire document, a two-stage parsing process is adopted: Phase 1 (Fast Path): Only parse a portion of the document content (e.g., the first 5% of the content, including file header metadata), and calculate the estimated local complexity CCS_pre; If CCS_pre [0.3, 0.7] (outside the fuzzy range), CCS_pre is used directly for policy routing. Here, 0.3 is an example first threshold and 0.7 is an example second threshold. The actual first and second thresholds can be dynamically adjusted.

[0057] If CCS_pre ∈ [0.3, 0.7] (fuzzy interval), proceed to stage two.

[0058] This solution parses local content of a document, extracts local content features, and calculates the corresponding local complexity. It uses a first threshold and a second threshold to determine the boundaries of local complexity. When the local complexity is lower than the first threshold or higher than the second threshold, it directly uses the local complexity as the basis for determining the complexity of the entire document.

[0059] This approach eliminates the need for complete parsing of the entire document, quickly determining complexity levels based on only partial content. This significantly reduces the computational load and time required for document parsing, improving complexity identification efficiency and scheduling response speed. Leveraging a content-feature-driven, refined complexity determination mechanism, it enables dynamic, optimal matching and scheduling by the rendering engine, abandoning the traditional, static routing model based solely on document format and version.

[0060] In some optional implementations of this embodiment, determining the complexity of a document based on the content features parsed from the document further includes: in response to a local complexity being greater than or equal to a first threshold and less than or equal to a second threshold, parsing the remaining content of the document to obtain the full content features of the document; and determining the full complexity as the document complexity based on the full content features.

[0061] Phase Two (Full Parsing): Asynchronously parse the entire document, calculate the exact full complexity CCS_full, and asynchronously update the scheduling decision.

[0062] When the local complexity of a document is in the middle range between the first and second thresholds, relying solely on local content cannot accurately represent the overall complexity of the document. In this case, the remaining content of the document is automatically supplemented and parsed to obtain the full content features. Then, the full complexity is calculated based on the full content features, and the full complexity is used as the basis for determining the final complexity of the document.

[0063] This method employs a hierarchical judgment logic of partial pre-judgment + full verification of intermediate intervals: low-complexity and extremely high-complexity documents only require partial parsing for quick classification, avoiding the waste of computing power caused by full parsing; only documents with complexity in the fuzzy range are fully parsed, balancing the accuracy of complexity judgment with the computational cost of parsing, and avoiding misjudgment bias caused by single partial judgment.

[0064] In some optional implementations of this embodiment, the method further includes: calculating the error between the total complexity and local complexity of different documents requested for rendering within a predetermined period; and adjusting the first threshold and the second threshold based on the distribution of the error.

[0065] Step 1: Periodically collect complexity comparison sample data

[0066] When the local complexity of a document falls within a preset fuzzy range and triggers the second stage of full content parsing, the system automatically generates and saves a complexity comparison record. Each record includes the document's unique identifier doc_id, local complexity CCS_pre, full complexity CCS_full, and complexity error value.

[0067] It is possible to collect all document comparison samples that triggered full parsing in a given week, forming a periodic dataset.

[0068] Step 2: Statistical analysis of error distribution and segmented analysis

[0069] Sort all error values ​​within the period according to their magnitude and calculate the sample proportion of different error ranges. For example: the sample proportion of accurate prediction with an error of less than 0.05, the sample proportion of general deviation with an error of 0.05 to 0.1, and the sample proportion of large deviation with an error of more than 0.1.

[0070] At the same time, the values ​​are divided into segments according to the CCS_pre range, and the average error in each range is calculated to locate the range with significantly high prediction deviation and identify the concentrated range of local prediction inaccuracies.

[0071] Step 3: Determine whether the threshold boundary needs adjustment based on the two types of error samples.

[0072] The current fuzzy interval threshold boundaries are set as follows: first threshold L = 0.3, second threshold H = 0.7. The optimization objective is to keep the overall error rate within 5%. Two typical judgment errors are identified: Missed judgment error: The local pre-evaluation of complexity has a large deviation, but the value is not within the fuzzy range. The complexity is directly judged according to the fast path and does not enter the full analysis stage, resulting in inaccurate complexity classification. Redundant calculation error: The local pre-evaluation complexity and accuracy meet the requirements and the error is minimal, but because the value falls within the fuzzy range, it is still forced to enter the full analysis process, causing unnecessary consumption of computing resources.

[0073] By statistically analyzing the sample proportions of the two types of errors, the rationality of the existing threshold boundary can be comprehensively judged.

[0074] Step 4: Adaptively adjust the threshold boundary based on the error distribution

[0075] Based on the error distribution characteristics, adaptive optimization of the threshold boundary of the fuzzy interval is performed in two scenarios: If the overall error of documents outside the threshold boundary is too large and there are too many missed samples, it indicates that the current fuzzy interval is too narrow. Lower the first threshold L and raise the second threshold H to expand the range of the fuzzy interval, so that more inaccurate samples can enter the full analysis stage and reduce the probability of missed judgment. If documents within the threshold boundary generally have small errors and a large number of redundant calculation samples, it indicates that the current fuzzy interval is too wide. Adjust the first threshold L and the second threshold H to narrow the fuzzy interval, reduce unnecessary full parsing, and save system computing resources.

[0076] The system periodically and automatically executes a closed-loop optimization process: Collect the comparison data of CCS_pre and CCS_full for the week each week → Statistically analyze the error distribution of each interval according to the CCS_pre value range → Inaccurate intervals with positioning errors exceeding 5% → Adaptively adjust the upper and lower boundaries L and H of the fuzzy intervals → Verify that the overall error rate outside the adjusted boundaries is less than 5% and the number of samples inside the boundaries is within a reasonable range → Write the updated thresholds into the system configuration and officially take effect in the scheduling logic of the following week.

[0077] This method achieves dynamic self-optimization of the fuzzy range of document complexity through weekly sample statistics, error distribution analysis, and adaptive iteration of threshold boundaries. This avoids complexity classification errors and rendering engine matching deviations caused by inaccurate local pre-assessment, while also reducing the computational waste caused by redundant full-data parsing. It achieves accurate complexity determination driven by content features, enabling dynamic optimal scheduling of the rendering engine.

[0078] In some optional implementations of this embodiment, the content features include multiple types. Determining the document complexity based on the document's content features includes: normalizing each type of content feature, wherein the content features include at least one of the following: text word count, number of images, table depth, formula density, and number of nested objects; determining the document complexity based on the weighted sum of each content feature, wherein the weight of each content feature is determined by the historical rendering time, and the longer the historical rendering time, the greater the weight of the corresponding feature.

[0079] Step 1: Extract multi-dimensional content features from the target document

[0080] The target document to be rendered is structured and parsed to extract at least one core content feature. In this embodiment, five types of features are selected: text word count, number of images, table depth, formula density, and number of nested objects, which comprehensively cover the core factors affecting the complexity of document content. Among them, table depth represents the number of nested levels of tables, formula density represents the number of formulas distributed within a unit page, and the number of nested objects represents the total number of non-text objects such as charts, attachments, and controls embedded in the document.

[0081] Step 2: Normalize the various content features

[0082] Each type of content feature extracted is normalized and quantized to eliminate calculation bias caused by differences in the dimensions of different features, and all feature values ​​are uniformly mapped to the [0,1] interval. The specific normalization rules are as follows: Text word count normalization: Based on the preset maximum text word count, divide the actual text word count of the target document by the benchmark value to obtain the normalized feature value; Image quantity normalization: Based on the preset maximum image capacity, the actual number of images is divided by the benchmark value to obtain the normalized feature value; Table depth normalization: Based on the preset maximum table nesting level, the actual nesting depth is divided by the benchmark value to obtain the normalized feature value; Formula density normalization: Based on the maximum number of formulas per unit page, the actual formula density is divided by the benchmark value to obtain the normalized feature value. Nested object number normalization: Based on the preset maximum number of nested objects, the actual number of nested objects is divided by the benchmark value to obtain the normalized feature value.

[0083] Step 3: Determine the dynamic weights of each content feature.

[0084] Based on historical rendering data, the system statistically analyzes the historical rendering time corresponding to various content features, and dynamically determines the weighting of each feature. The weighting rule is: the longer the historical rendering time, the greater the weight of the corresponding content feature. Specifically, the system collects rendering time data triggered individually for various features in existing documents in real time, performs weighted statistics on the time data, and generates weight coefficients for the corresponding features. This ensures that features that significantly affect rendering time have a higher weight in complexity calculations, aligning with actual rendering performance requirements.

[0085] Step 4: Calculate the final complexity of the document based on the weighted sum.

[0086] The normalized content features are multiplied by their corresponding dynamic weights and then summed to obtain the document's overall complexity score. The calculation formula is shown in step 201.

[0087] Step 5: Dynamically select the best rendering engine based on complexity

[0088] Based on the calculated overall document complexity score, complexity levels are divided. From the candidate rendering engine set, which includes both old and new versions of the engine, the appropriate target rendering engine is matched: high-complexity documents are matched with high-performance engines, medium-complexity documents are matched with balanced and compatible engines, and low-complexity documents are matched with lightweight engines to complete document rendering.

[0089] This embodiment normalizes multiple content features such as text word count, number of images, table depth, formula density, and number of nested objects one by one, completely eliminating the interference of numerical differences in features with different dimensions, and ensuring the fairness and accuracy of complexity calculation. By dynamically allocating feature weights through historical rendering time, a strong correlation between weights and actual rendering performance is achieved, which greatly improves the rationality and fit of complexity judgment and avoids judgment bias caused by fixed weights.

[0090] In some optional implementations of this embodiment, the rendering request includes document format and terminal device information; and determining the target rendering engine from the set of candidate rendering engines based on complexity includes: determining the weight of each performance metric of each candidate rendering engine based on complexity, wherein the performance metric includes at least one of the following: document format compatibility, load idle time, and historical rendering success rate; for each candidate rendering engine, determining the performance of the candidate rendering engine based on the weighted sum of the various performance metrics of the candidate rendering engine; and determining the candidate rendering engine with the highest performance as the target rendering engine.

[0091] For each engine in the candidate rendering engine set {k}, calculate a comprehensive score, i.e., a performance metric: PS_k = α_f · PF_k + α_l · PL_k + α_r · PR_k; PF_k: Engine k's adaptation score to the current document format (capability vector compatibility, pre-configured); PL_k: Engine k corresponds to the inverse of the current load of the rendering instance pool (load idleness; the lower the load, the higher the score). For example, if the total number of instances in the pool is 60, and 45 requests are being processed, the load rate is 45 / 60 = 0.75 (75% of the instances are busy).

[0092] PR_k: Historical rendering success rate of engine k; α_f = 0.5, α_l = 0.3, α_r = 0.2 (weights can be dynamically adjusted) Select the engine with the highest PS_k value to perform rendering.

[0093] Capability vectors are used to quantify the document format adaptation capability and complex document element processing capability of two types of rendering engines (strategy A and strategy B). The capability value range is [0,1]. The larger the value, the stronger the adaptation and rendering processing capability of the corresponding scene. The specific quantification results are shown in the table below:

[0094] For example, the current document is in zmix format, contains formulas, and contains nested tables: PF_A = (1.0 + 1.0 + 0.9) / 3 = 0.97 ← High adaptability PF_B = (0.3 + 0.5 + 0.6) / 3 = 0.47 ← Low adaptability This solution dynamically sets the weights of each candidate rendering engine's performance metrics, such as document format compatibility, workload availability, and historical rendering success rate, based on document complexity. A weighted sum of multiple performance metrics for each rendering engine yields a comprehensive performance result, and the engine with the best comprehensive performance is selected as the target rendering engine. Simultaneously, a capability vector quantization with values ​​ranging from [0,1] is used to characterize the differences in document format adaptation and complex element processing capabilities between the two types of renderers. Higher values ​​indicate stronger adaptation and rendering processing capabilities. This achieves refined quantitative evaluation and adaptive optimal matching of rendering engines, overcoming the limitations of traditional static binding of rendering engines based on document format. It ensures precise matching of rendering tasks with rendering engine capabilities, workload status, and historical stability, effectively improving document rendering matching accuracy, system resource utilization, and overall rendering service stability.

[0095] In some optional implementations of this embodiment, each candidate rendering engine corresponds to an instance pool for running the rendering service process, and each instance pool includes at least one instance; and rendering the document based on the target rendering engine includes: in response to the existence of an idle instance in the instance pool of the target rendering engine, determining the idle instance as the target instance; and rendering the document based on the target instance.

[0096] An instance refers to a service process or container running a rendering engine. Each instance typically handles only one or a limited number of rendering requests at a time. Multiple instances form an instance pool, collectively handling similar requests.

[0097] An "instance" is roughly equivalent to a unit of work that can independently receive and process document rendering requests.

[0098] This solution treats a service process or container running a rendering engine as an independent rendering instance. Multiple instances of the same type form an instance pool to uniformly handle similar rendering requests. Each instance is limited to processing a small number of rendering requests simultaneously to ensure processing quality. After selecting a target rendering engine, idle instances are preferentially selected from its corresponding instance pool as target instances to undertake rendering tasks. This can quickly schedule idle work units, reduce request queuing latency, and fully leverage the cluster scheduling capabilities of the instance pool. Combined with the renderer capability vector's quantitative evaluation of format compatibility and complex element processing capabilities, it can further achieve reasonable allocation of instance resources under the premise of matching the optimal rendering engine, avoid instance load imbalance and resource waste, and improve document rendering response speed, instance concurrent processing efficiency, and overall rendering service stability.

[0099] In some optional implementations of this embodiment, the method further includes: in response to the absence of a free instance in the instance pool of the target rendering engine, detecting a free instance from the instance pool of other candidate rendering engines as the target instance.

[0100] 1. Cross-rendering engine instance borrowing rules

[0101] When the idle rate of the instance pool corresponding to any rendering engine is greater than the borrowing threshold, such as 40%, other rendering engines are allowed to borrow idle instances in that instance pool. During the borrowing period, the instance is marked as temporarily borrowed and will be returned to the original rendering engine instance pool first after the original rendering engine's business traffic is restored.

[0102] 2. Cross-rendering engine instance borrowing trigger conditions

[0103] For instances to be borrowed across rendering engines, both of the following conditions must be met simultaneously; neither can be omitted: The idle rate of the rendering engine instance pool of the lending party is greater than the borrowing threshold, and there are a lot of idle instance resources; The borrower's rendering engine itself lacks sufficient instance resources, resulting in a backlog of rendering request queues and requests waiting in line.

[0104] Cross-rendering engine instance borrowing will not be triggered if only the lending instance is idle but the borrowing instance has no resource shortage, or if only the borrowing instance is short of resources but the lending instance has no idle instances. Instance borrowing scheduling will only be performed when the lending instance is idle and the borrowing instance has insufficient resources.

[0105] 3. Instance Priority Return Mechanism

[0106] 3.1 Definition of Business Traffic Recovery

[0107] Taking rendering engine A (Zmix high-performance renderer) and rendering engine B (Legacy lightweight renderer) as examples: During off-peak hours, rendering engine A experiences low traffic, resulting in a large amount of idle instance resources and an idle rate exceeding the borrowing threshold. Meanwhile, rendering engine B experiences high traffic, with its own instances fully loaded and requests queuing up. At this point, instance borrowing is triggered, with rendering engine A lending some idle instances to rendering engine B.

[0108] When business hours are at their peak, the number of document rendering requests for rendering engine A surges instantly, its original instance gradually approaches full load, and the depth of the request queue continues to increase, which indicates that the original rendering engine's traffic has recovered.

[0109] 3.2 Implementation Logic of Priority Return Mechanism

[0110] The instances held by the borrowing rendering engine are divided into owned instances and external instances marked as temporary borrowing.

[0111] When the lending rendering engine experiences traffic recovery but insufficient instance resources, it can immediately identify and reclaim the temporarily borrowed instances without waiting for the system's scheduled global rebalancing cycle, prioritizing their return to the original rendering engine's instance pool. This mechanism achieves instant instance resource migration by marking the status of borrowed instances, avoiding issues such as request queuing and increased rendering latency caused by excessive instance borrowing when business traffic rebounds.

[0112] Cross-strategy borrowing has an upper limit: a single borrowing cannot exceed a certain percentage of the target pool capacity, for example, 30%, to prevent the borrowed strategy from suffering a severe shortage of instances due to traffic rebound.

[0113] This borrowing mechanism, on the one hand, revitalizes idle resources in the instance pools of various rendering engines, avoiding the load imbalance problem of some rendering engine instances running idle for a long time and others experiencing request queuing and congestion, thereby improving the overall instance resource utilization and overall concurrent throughput. On the other hand, it relies on renderer capability vectors to achieve reasonable adaptation of borrowed instances, and through temporary status marking and traffic recovery priority return logic, it ensures that the original rendering engine can quickly recover resources when business traffic rebounds, and will not experience increased rendering latency or request backlog due to instance borrowing. It balances the flexibility of cross-rendering engine resource sharing scheduling with the stability and real-time response of each rendering engine's own rendering service.

[0114] In some optional implementations of this embodiment, each instance pool corresponds to a queue, which is used to store documents waiting to be rendered. The method further includes: periodically redistributing the number of instances in each instance pool according to the ratio of the queue length of each instance pool to the total queue length. The higher the ratio, the more instances are allocated. The queue length is the number of documents in a queue, and the total queue length is the sum of the queue lengths of all queues.

[0115] Resources are dynamically adjusted using the following formula: I_i = floor(I_total · QD_i / ΣQD_j) Where I_i represents the final number of instances allocated to rendering engine i; floor() indicates rounding down (only integer instances are allocated, decimals are discarded). I_total represents the maximum total number of rendering instances on the server, for example, 100. QD_i represents the current queue length of rendering engine i, that is, the number of requests waiting in the queue in the instance pool of rendering engine i; the longer the queue, the more instances are needed. ΣQD_j represents the sum of the queue lengths of all rendering engines, that is, the total number of queues globally.

[0116] Resources are dynamically allocated based on the principle of "whoever has a longer queue gets more instances." This solution periodically redistributes the number of instances in each instance pool according to the proportion of each instance pool's queue length to the total global queue length. The higher the queue length proportion, the more instance resources are allocated. It can adaptively and elastically adjust instance resources in response to real-time traffic distribution changes in various types of document rendering requests, achieving precise matching between resource supply and business request volume. This avoids issues such as queue congestion in some instance pools, increased request queuing latency, and idle resources in some instance pools, significantly improving the overall instance resource utilization and rendering request throughput of the cluster.

[0117] See also Figure 3 , Figure 3 This is a schematic diagram illustrating an application scenario of the document rendering method according to this embodiment. Figure 3 In the application scenario, the specific process is as follows: Step 1: The document rendering request reaches the scheduling layer: The rendering request carries {doc_id, format_version, terminal_type} to the scheduling layer.

[0118] Step 2: Quickly estimate complexity: The scheduling layer checks the content characteristics in the cache (Key: doc_id, TTL: adaptive based on popularity). If the cache is missed, a two-stage parsing process is initiated. The rendering engine scores the results immediately after the result of stage one is returned (≤5ms).

[0119] Step 3: Rendering Engine Scoring and Routing: Calculate PS_k for all candidate rendering engines, select the highest-scoring rendering engine, and route the request to the corresponding instance pool.

[0120] Step 4: Rendering Execution and Feedback: After rendering is complete, {time consumed, result status, actual resource consumption} is sent back to the scheduling layer for rolling updates of the historical success rate of PR_k (exponential moving average, decay coefficient 0.9).

[0121] Step 5: Popularity Update and Instance Shrinking: The AHC counter is updated every time a document is accessed, and an instance pool rebalancing is triggered every 60 seconds to redistribute instances according to the latest QD ratio.

[0122] Further reference Figure 4 This illustrates a flow 400 of another embodiment of a method for rendering a document. Flow 400 of this document rendering method includes the following steps: Step 401: A request to migrate from the target rendering engine to the new rendering engine is received.

[0123] In this embodiment, a request to migrate from the target rendering engine to the new rendering engine will be initiated in scenarios such as rendering engine version upgrade, new rendering engine launch, performance optimization replacement, and hardware resource adjustment.

[0124] Step 402: Select a predetermined proportion of target documents from the queue of documents in the target rendering engine.

[0125] In this embodiment, when it is necessary to migrate traffic from rendering engine A to rendering engine B, a progressive A / B split is adopted: 5% → 20% → 50% → 100%, with a stable observation window of ≥10 minutes for each stage. Automatic rollback is triggered when the error rate of any stage is >1%.

[0126] For example, out of every 100 requests, 5 are routed to rendering engine B (the new rendering engine) and 95 are routed to rendering engine A (the old rendering engine). This 5% is a fixed percentage. It is not "the first 5 are routed to B and the rest to A", but rather "out of every 100 requests, 5 are always routed to B".

[0127] Step 403: Render the target document based on the new rendering engine to obtain rendering performance metrics.

[0128] In this embodiment, rendering performance metrics may include error rate, rendering time, and user complaints. These metrics are used to evaluate the quality of the 5% of requests handled by B. A small traffic volume is used to verify the stability of B in a real-world environment. 5% traffic is sufficient to expose potential problems with B; for example, memory leaks, specific document format crashes, and performance degradation under high concurrency may appear within 10 minutes.

[0129] Step 404: In response to the rendering performance indicators meeting the predetermined conditions, the predetermined ratio is increased, and the process jumps to step 402.

[0130] In this embodiment, if the error rate of 5% of rendering requests is less than the first error threshold (e.g., 1%) after 10 minutes of operation, the error rate is proactively increased to 20%. If the error rate of 20% of the rendering requests is less than the first error threshold after 10 minutes, then the threshold will be proactively raised to 50%. If the error rate of 50% of the rendering requests is less than the first error threshold after 10 minutes, then the error rate will be actively increased to 100%.

[0131] Step 405: In response to the rendering performance indicators not meeting the predetermined conditions, the predetermined ratio is reduced, and the process jumps to step 402.

[0132] In this embodiment, the predetermined ratio is reduced to return to the previous stable phase.

[0133] For example: If the error rate is not less than the first error threshold at the current 50% stage, roll back to the previous stable stage (20%): 80 requests are routed to rendering engine A, and 20 requests are routed to rendering engine B. It does not directly return to 0% (completely abandoning B). Rollback to the 5% stage only occurs if the error rate also exceeds the first error threshold at the 20% stage. If the 5% stage is also unstable, roll back to 0% (completely disabling B and routing all requests to A).

[0134] When this solution receives a request to migrate from the target rendering engine to the new rendering engine, it adopts a gray-scale progressive migration strategy. First, it selects a predetermined proportion of target documents from the original target rendering engine queue and submits them to the new rendering engine for rendering, and collects the corresponding rendering performance indicators for verification. Based on whether the performance indicators meet the preset conditions, it adaptively and dynamically increases or decreases the migration proportion, and iteratively executes the gray-scale migration process.

[0135] Further reference Figure 5 As an implementation of the methods shown in the above figures, this disclosure provides an embodiment of a document rendering apparatus, which is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0136] like Figure 5 As shown, the document rendering apparatus 500 of this embodiment includes a calculation unit 501, a scheduling unit 502, and a rendering unit 503. The calculation unit 501 is configured to determine the complexity of a document based on its content features in response to receiving a document rendering request; the scheduling unit 502 is configured to determine a target rendering engine from a set of candidate rendering engines based on the complexity; and the rendering unit 503 is configured to render the document based on the target rendering engine.

[0137] In this embodiment, the specific processing of the computing unit 501, scheduling unit 502, and rendering unit 503 of the document rendering apparatus 500 can be referred to Figure 2 Steps 201, 202, and 203 in the corresponding embodiment.

[0138] In some optional implementations of this embodiment, the computing unit 501 is further configured to: query the content features of a document in a cache, wherein the lifespan of the document's content features in the cache is positively correlated with the number of times the document is accessed; in response to a query failure, determine the complexity of the document based on the content features parsed from the document, and store the content features in the cache.

[0139] In some optional implementations of this embodiment, the calculation unit 501 is further configured to: parse the local content of the document to obtain the local content features of the document; determine the local complexity of the document based on the local content features; and, in response to the local complexity being less than a first threshold or greater than a second threshold, use the local complexity as the complexity of the document, wherein the first threshold is less than the second threshold.

[0140] In some optional implementations of this embodiment, the computing unit 501 is further configured to: in response to a local complexity greater than or equal to a first threshold and less than or equal to a second threshold, parse the remaining content of the document to obtain the full content features of the document; and determine the full complexity as the document complexity based on the full content features.

[0141] In some optional implementations of this embodiment, the apparatus 500 further includes an adjustment unit configured to: statistically analyze the error between the total complexity and local complexity of different documents requested for rendering within a predetermined period; and adjust a first threshold and a second threshold based on the distribution of the error.

[0142] In some optional implementations of this embodiment, the content features include multiple types, and the calculation unit 501 is further configured to: normalize each type of content feature, wherein the content features include at least one of the following: text word count, number of images, table depth, formula density, number of nested objects; determine the complexity of the document based on the weighted sum of each content feature, wherein the weight of each content feature is determined by the historical rendering time, wherein the longer the historical rendering time, the greater the weight of the corresponding feature.

[0143] In some optional implementations of this embodiment, the rendering request includes document format and terminal device information; and the scheduling unit 502 is further configured to: determine the weight of each performance metric of each candidate rendering engine based on complexity, wherein the performance metric includes at least one of the following: document format compatibility, load idle time, and historical rendering success rate; for each candidate rendering engine, determine the performance of the candidate rendering engine based on the weighted sum of the performance metrics of the candidate rendering engine; and determine the candidate rendering engine with the highest performance as the target rendering engine.

[0144] In some optional implementations of this embodiment, each candidate rendering engine corresponds to an instance pool for running the rendering service process, and each instance pool includes at least one instance; and the rendering unit 503 is further configured to: determine the idle instance as the target instance in response to the existence of an idle instance in the instance pool of the target rendering engine; and render the document based on the target instance.

[0145] In some optional implementations of this embodiment, the scheduling unit 502 is further configured to: detect an idle instance from the instance pool of other candidate rendering engines as the target instance in response to the absence of an idle instance in the instance pool of the target rendering engine.

[0146] In some optional implementations of this embodiment, each instance pool corresponds to a queue, which is used to store documents waiting to be rendered. The scheduling unit 502 is further configured to: periodically redistribute the number of instances in each instance pool according to the ratio of the queue length of each instance pool to the total queue length. The higher the ratio, the more instances are allocated. The queue length is the number of documents in a queue, and the total queue length is the sum of the queue lengths of all queues.

[0147] In some optional implementations of this embodiment, each candidate rendering engine corresponds to an instance pool for running the rendering service process. Each instance pool includes at least one instance, and each instance pool corresponds to a queue for storing documents waiting to be rendered. The scheduling unit 502 is further configured to: in response to receiving a request to migrate from the target rendering engine to the new rendering engine, perform the following rendering steps: select a predetermined proportion of target documents from the documents in the queue of the target rendering engine, render the target documents based on the new rendering engine, and obtain rendering performance indicators; in response to the rendering performance indicators meeting predetermined conditions, increase the predetermined proportion and continue to execute the above rendering steps; in response to the rendering performance indicators not meeting predetermined conditions, decrease the predetermined proportion and continue to execute the above rendering steps.

[0148] The collection, storage, use, processing, transmission, provision, and disclosure of any type of information, such as user personal information, in this technical solution comply with relevant laws and regulations and do not violate public order and good morals.

[0149] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0150] An electronic device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method described in process 200.

[0151] A non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause the computer to perform the method described in process 200.

[0152] A computer program product includes a computer program that, when executed by a processor, implements the method described in process 200.

[0153] Figure 6 A schematic block diagram of an example electronic device 600 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0154] like Figure 6 As shown, device 600 includes a computing unit 601, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 602 or a computer program loaded into random access memory (RAM) 603 from storage unit 608. RAM 603 may also store various programs and data required for the operation of device 600. The computing unit 601, ROM 602, and RAM 603 are interconnected via bus 604. Input / output (I / O) interface 605 is also connected to bus 604.

[0155] Multiple components in device 600 are connected to I / O interface 605, including: input unit 606, such as keyboard, mouse, etc.; output unit 607, such as various types of monitors, speakers, etc.; storage unit 608, such as disk, optical disk, etc.; and communication unit 609, such as network card, modem, wireless transceiver, etc. Communication unit 609 allows device 600 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0156] The computing unit 601 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 performs the various methods and processes described above, such as the method of rendering a document. For example, in some embodiments, the method of rendering a document may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program may be loaded and / or installed on device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by the computing unit 601, one or more steps of the method of rendering a document described above may be performed. Alternatively, in other embodiments, the computing unit 601 may be configured to perform the method of rendering a document by any other suitable means (e.g., by means of firmware).

[0157] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0158] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0159] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0160] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0161] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0162] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0163] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0164] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.< / draw:image>

Claims

1. A method for rendering a document, comprising: In response to receiving a document rendering request, the complexity of the document is determined based on the content features of the document; The target rendering engine is determined from the set of candidate rendering engines based on the complexity. The document is rendered based on the target rendering engine.

2. The method according to claim 1, wherein, Determining the complexity of a document based on its content features includes: The content features of the document are queried in the cache, wherein the lifespan of the content features of the document in the cache is positively correlated with the number of times the document is accessed; In response to a query failure, the complexity of the document is determined based on the content features parsed from the document, and the content features are stored in the cache.

3. The method according to claim 2, wherein, The determination of the document's complexity based on content features parsed from the document includes: The local content of the document is parsed to obtain the local content features of the document; The local complexity of the document is determined based on the local content features. In response to the local complexity being less than a first threshold or greater than a second threshold, the local complexity is used as the complexity of the document, wherein the first threshold is less than the second threshold.

4. The method according to claim 3, wherein, The method of determining the complexity of a document based on content features parsed from the document further includes: In response to the local complexity being greater than or equal to the first threshold and less than or equal to the second threshold, the remaining content of the document is parsed to obtain the full content features of the document; The total complexity is determined based on the full content features and used as the complexity of the document.

5. The method according to claim 4, further comprising: The error between the total complexity and local complexity of different documents requested for rendering within a predetermined period is statistically analyzed. The first threshold and the second threshold are adjusted based on the distribution of the error.

6. The method according to claim 1, wherein, The content features include multiple types, and determining the complexity of the document based on its content features includes: Normalization is performed on each type of content feature, wherein the content features include at least one of the following: number of text characters, number of images, table depth, formula density, and number of nested objects; The complexity of the document is determined by a weighted sum of various content features, wherein the weight of each content feature is determined by the historical rendering time, and the longer the historical rendering time, the greater the weight of the corresponding feature.

7. The method according to claim 1, wherein, The rendering request includes document format and terminal device information; as well as The step of determining the target rendering engine from the candidate rendering engine set based on the complexity includes: The weights of various performance metrics for each candidate rendering engine are determined based on the complexity, wherein the performance metrics include at least one of the following: document format compatibility, load idleness, and historical rendering success rate. For each candidate rendering engine, the performance of the candidate rendering engine is determined by the weighted sum of its various performance metrics. The candidate rendering engine with the highest performance is selected as the target rendering engine.

8. The method according to claim 1, wherein, Each candidate rendering engine corresponds to an instance pool for running the rendering service process, and each instance pool includes at least one instance; as well as The rendering of the document based on the target rendering engine includes: In response to the existence of an idle instance in the instance pool of the target rendering engine, the idle instance is determined as the target instance; The document is rendered based on the target instance.

9. The method according to claim 8, further comprising: In response to the absence of a free instance in the instance pool of the target rendering engine, a free instance is detected from the instance pools of other candidate rendering engines and used as the target instance.

10. The method according to claim 8, wherein, Each instance pool corresponds to a queue, which is used to store documents waiting to be rendered. The method further includes: The number of instances in each instance pool is redistributed periodically according to the ratio of the queue length of each instance pool to the total queue length. The higher the ratio, the more instances are allocated. The queue length is the number of documents in a queue, and the total queue length is the sum of the queue lengths of all queues.

11. The method according to any one of claims 1-10, wherein, Each candidate rendering engine corresponds to an instance pool for running the rendering service process. Each instance pool includes at least one instance, and each instance pool corresponds to a queue for storing documents waiting to be rendered. The method further includes: In response to receiving a request to migrate from the target rendering engine to a new rendering engine, the following rendering steps are performed: a predetermined proportion of target documents are selected from the documents in the queue of the target rendering engine, the target documents are rendered based on the new rendering engine, and rendering performance metrics are obtained. In response to the rendering performance index meeting the predetermined conditions, the predetermined ratio is increased, and the above rendering steps are continued. In response to the rendering performance metric not meeting the predetermined conditions, the predetermined ratio is reduced, and the above rendering steps are continued.

12. An apparatus for rendering a document, comprising: The computing unit is configured to determine the complexity of the document based on the content features of the document in response to receiving a rendering request for the document. The scheduling unit is configured to determine the target rendering engine from the set of candidate rendering engines based on the complexity. The rendering unit is configured to render the document based on the target rendering engine.

13. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-11.

14. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-11.

15. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-11.

Images