Location point request uploading method and device, computer equipment and storage medium

Abstract

The invention relates to the technical field of computers, and discloses a location point request uploading method and device, computer equipment and a storage medium, applied to an upstream server side, the method comprises the following steps: receiving a plurality of location point requests uploaded by a user side; obtaining a pre-configured capacity parameter of a preset card slot, and carrying out merging processing on the position point requests based on the capacity parameter to obtain at least one target request set; and uploading the target request set to a downstream server side associated with the upstream server side. According to the method, the problems of low efficiency and unstable performance caused by incapability of adapting to real-time request change due to fixed merging size in the existing position point uploading merging technology are solved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically to a method, apparatus, computer device, and storage medium for requesting and uploading location points. Background Technology

[0002] In multi-tenant scenarios, such as driver location upload services, a large number of online users frequently need to upload location data to support downstream services such as route planning, navigation, and trajectory recording. To alleviate network bandwidth pressure and server load, existing technologies typically employ request merging methods, aggregating multiple location upload requests into a single batch request before sending it to the downstream server. Common merging strategies include static merging, time window merging, and rule-based merging. These methods can reduce the number of requests to some extent, but they all rely on pre-set fixed parameters and cannot adapt to dynamic changes in request volume in real time.

[0003] In existing request merging technologies, the merge size is typically determined based on statically configured capacity parameters, lacking adaptability to real-time request volumes. This can lead to situations where, in high-concurrency scenarios, merged requests may fail to handle a large influx of location point requests in a timely manner, causing request delays or collisions, and impacting the real-time nature of location point uploads and the stability of downstream services. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a method, apparatus, computer device, and storage medium for uploading location requests, in order to solve the problems of low efficiency and unstable performance caused by the inability to adapt to real-time changes in requests due to the fixed merging size in existing location upload merging technologies.

[0005] In a first aspect, embodiments of the present invention provide a location point request upload method, applied to an upstream server, the method comprising: Receive multiple location point requests uploaded by the user client; Obtain the pre-configured capacity parameters of the preset card slot, and merge the location point requests based on the capacity parameters to obtain at least one target request set; The target request set is uploaded to the downstream server associated with the upstream server.

[0006] Furthermore, obtaining the pre-configured capacity parameters of the preset card slot includes: Monitor the triggering frequency of location upload requests within a preset time period; Obtain the status information of the preset card slot, and adjust the initial number of the preset card slots to be enabled based on the trigger frequency and the status information to obtain the target number of enabled cards; Obtain the request processing efficiency and the number of aggregate uploads of the downstream server within a preset time period, and configure the target single-slot capacity of the preset card slot based on the trigger frequency, the request processing efficiency, and the number of aggregate uploads; Configure the target number of enabled cards and the target single-slot capacity as the capacity parameters of the preset card slot.

[0007] Furthermore, the triggering frequency of location point upload requests within the preset monitoring time period includes: Generate a sequence identifier for each location upload request based on the request time; Calculate the change in the number of the sequence identifier within the preset time period; The trigger frequency of location point upload requests within the preset time period is determined based on the change in the number.

[0008] Furthermore, the step of configuring and adjusting the initial number of activated cards in the preset card slot based on the trigger frequency and the status information to obtain the target number of activated cards includes: A first adjustment threshold is determined based on the triggering frequency and the first proportional coefficient; Extract the number of collisions from the status information and determine whether the number of collisions is greater than or equal to the first adjustment threshold; If the initial activation quantity is greater than or equal to the first adjustment threshold, the initial activation quantity is configured and adjusted using the capacity expansion adjustment strategy to obtain the target activation quantity; or, if the initial activation quantity is less than the first adjustment threshold, the idle quantity in the status information is extracted, and the initial activation quantity of the preset card slot is configured and adjusted according to the idle quantity to obtain the target activation quantity.

[0009] Furthermore, the step of configuring and adjusting the initial number of activated cards in the preset card slots based on the number of idle slots to obtain the target number of activated slots includes: A second adjustment threshold is determined based on the initial number of activated units and the second proportional coefficient, and it is determined whether the number of idle units is greater than or equal to the second adjustment threshold. If the initial number of enabled devices is greater than or equal to the second adjustment threshold, the initial number of enabled devices is configured and adjusted using a scaling-down adjustment strategy to obtain the target number of enabled devices. Alternatively, if the initial number of enabled devices is less than the second adjustment threshold, the initial number of enabled devices is determined to be the target number of enabled devices.

[0010] Furthermore, configuring the target single-slot capacity of the preset card slot based on the triggering frequency, the request processing efficiency, and the number of uploads to the set includes: Calculate the ratio between the triggering frequency and the request processing efficiency; Multiply the ratio by the number of uploads to the set to obtain a product value, and configure the product value as the target single-slot capacity of the preset card slot.

[0011] Furthermore, the merging of the location requests based on the capacity parameter to obtain at least one target request set includes: Based on the target number of cards to be activated in the capacity parameters, the effective card slots are determined in the preset card slots; The location point upload requests are allocated to the valid card slots according to their sequential identifiers, and the cumulative number of location point upload requests in each valid card slot is monitored. When the cumulative number in any of the valid card slots reaches the target single-slot capacity in the capacity parameter, the location point upload requests in the valid card slots are merged to obtain the target request set.

[0012] Secondly, embodiments of the present invention provide a location point request upload device, applied to an upstream server, the device comprising: The receiving module is used to receive multiple location point requests uploaded by the user client; The processing module is used to obtain the pre-configured capacity parameters of the preset card slot, and to merge the location point requests based on the capacity parameters to obtain at least one target request set. The upload module is used to upload the target request set to the downstream server associated with the upstream server.

[0013] Thirdly, embodiments of the present invention provide a computer device, including: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the method described in the first aspect or any corresponding embodiment thereof.

[0014] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing computer instructions that cause a computer to perform the method described in the first aspect or any of its corresponding embodiments.

[0015] The method provided in this application has the following beneficial effects: The method provided in this application effectively aggregates scattered location data inputs by receiving multiple location point requests uploaded by the user terminal, reducing frequent interactions between the upstream server and the user terminal and lowering the risk of network congestion. By obtaining the capacity parameters of a preset card slot and merging the location point requests based on these parameters, it achieves structured aggregation of requests. This avoids the rigidity of static merging strategies and dynamically adapts to fluctuations in request volume through a configurable capacity mechanism, improving resource utilization efficiency and system real-time response. By uploading the merged target request set to the downstream server, it reduces the number of requests sent downstream, lowers the processing pressure and network transmission overhead of the downstream server, and ensures the integrity and timing consistency of the location data batch processing, enhancing the overall system stability and scalability. Attached Figure Description

[0016] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating the location point request upload method according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating another location point request upload method according to an embodiment of the present invention. Figure 3 This is a flowchart illustrating another location point request upload method according to an embodiment of the present invention; Figure 4 This is a schematic diagram of a location request processing component according to an embodiment of the present invention; Figure 5 This is a structural block diagram of a location point request upload device according to an embodiment of the present invention; Figure 6 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. Detailed Implementation

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

[0019] According to embodiments of the present invention, a location point request upload method, apparatus, computer device, and storage medium are provided. It should be noted that the steps shown in the flowcharts in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0020] This embodiment provides a location point request upload method, applied to the upstream server side. Figure 1 This is a flowchart of a location point request upload method according to an embodiment of the present invention, such as... Figure 1 As shown, the process includes the following steps: Step S101: Receive multiple location point requests uploaded by the user.

[0021] In this embodiment, the upstream server (such as a location server) receives location requests from user terminals (such as driver mobile devices or applications running on vehicles) in real time via network interfaces (such as RESTful APIs, WebSockets, or TCP connections). Location requests typically include user identifiers, location data (such as latitude and longitude coordinates), timestamps, and other optional attributes (such as speed and direction) to support downstream services such as route planning, navigation, or trajectory recording. During reception, the upstream server performs preliminary verification and parsing of the requests, such as checking the integrity of the data format or user permissions, but has not yet performed merging processing. Due to the large number of user terminals and dynamically changing request frequency in multi-tenant scenarios, an asynchronous listening mechanism efficiently receives high-concurrency requests, providing the raw data foundation for subsequent merging processing. Furthermore, received requests can be temporarily stored in a memory buffer or message queue (such as Kafka or Redis) to handle traffic peaks, ensuring that requests are not lost and their order is controllable.

[0022] Step S102: Obtain the pre-configured capacity parameters of the preset card slot, and merge the location point requests based on the capacity parameters to obtain at least one target request set.

[0023] In this embodiment, the upstream server first obtains dynamically calculated capacity parameters from the monitoring process. These parameters include the target number of active slots (i.e., the number of valid slots to be activated in the current period) and the target single-slot capacity (i.e., the number of requests that each valid slot can accommodate). Then, based on the target number of active slots, the server activates the corresponding number of valid slots from a preset slot pool. Next, the received location point requests are distributed to each valid slot according to their sequential identifier using a hash or modulo algorithm. Each valid slot continuously accumulates the number of requests. When the number of requests accumulated in any valid slot reaches the target single-slot capacity, the slot is locked, all request parameters are extracted and assembled into a structured target request set, and then the slot state is reset to restart request accumulation. In this way, a large number of scattered location point requests are merged in batches according to dynamically optimized capacity parameters, laying the foundation for efficient subsequent uploading.

[0024] As an example, suppose the target enabled quantity is set to 4 and the target single slot capacity is 15 based on the monitoring results: when 60 location point requests numbered 0-59 are received, the requests are allocated to 4 valid slots according to the rule of "sequence identifier % 4" (e.g., slot 0 receives numbers 0, 4, 8...). When each slot accumulates 15 requests, a merging is triggered, and finally 4 target request sets containing 15 request parameters are generated.

[0025] Step S103: Upload the target request set to the downstream server associated with the upstream server.

[0026] In this embodiment, when the cumulative number of location upload requests in any valid card slot reaches the target single-slot capacity and is merged to form a target request set, the upstream server actively pushes this target request set to the downstream server as a single network request through its built-in network transmission module (such as an HTTP client or RPC framework). The target request set is a structured data packet that encapsulates the core parameters of the originally scattered multiple location requests. The transmission protocol can be HTTP / 1.1 persistent connection, HTTP / 2, or a custom binary protocol to improve transmission efficiency. Before uploading, the upstream server serializes the target request set (e.g., converts it to JSON or Protocol Buffers format) and attaches necessary authentication tokens and batch metadata (e.g., set size, time range). After receiving the data, the downstream server returns an acknowledgment response, and the upstream server updates the sending status accordingly. If the transmission fails, it re-uploads the data according to a retry strategy (e.g., exponential backoff) while ensuring no data loss. By compressing multiple discrete requests into a batch request, the network connection overhead and request parsing pressure on the downstream server are reduced, while the timeliness and reliability of location data batch processing are ensured by the efficient transmission mechanism.

[0027] In this embodiment of the application, location point requests are merged based on capacity parameters to obtain at least one target request set, including: Step A1: Determine the valid card slots in the preset card slots based on the target number of enabled slots in the capacity parameters.

[0028] Specifically, the upstream server dynamically calculates capacity parameters (including the target number of slots to be activated and the target single-slot capacity) based on the monitoring process. From its pre-allocated pool of a fixed number of pre-defined slots, it sequentially selects slots equal to the target number of slots to be activated and marks them as valid slots for the current period. Pre-defined slots are logical space units pre-allocated in server memory for temporarily storing and merging requests; each slot has an independent queue structure and merging bucket. Valid slots refer to those activated within the current statistical period that can actually receive and process location point upload requests. The availability of all pre-defined slots is managed by maintaining a slot state mapping table (such as a bitmap or boolean array), and the set of valid slots is dynamically updated based on the target number of slots to be activated when the period changes. For example, if the target number of slots to be activated is 8, the first 8 slots from the pre-defined pool of 16 are activated as valid slots, while the remaining slots are temporarily put into a dormant state to save resources. After a valid slot is activated, its internal structure (such as the queue pointer and bucket counter) is initialized, ready to receive a new round of request allocation.

[0029] By dynamically selecting valid card slots, the number of parallel processing channels can be flexibly adjusted according to the real-time request volume. This avoids the collision bottleneck caused by a fixed number of card slots under high concurrency and also prevents resource idleness under low load, laying an adaptive foundation for the balanced distribution and efficient merging of subsequent requests.

[0030] Step A2: Assign location upload requests to valid card slots according to their sequential identifiers, and monitor the cumulative number of location upload requests in each valid card slot.

[0031] Specifically, the upstream server's request numberer generates a globally incrementing sequence identifier (usually a monotonically increasing integer) for each successfully received location upload request. Then, based on a pre-defined allocation algorithm (e.g., using the sequence identifier modulo the number of valid slots), each request is routed to a specific valid slot. Each valid slot maintains a request queue and a merge bucket. After a request enters a slot, it is temporarily stored according to a pre-defined strategy (e.g., in a fair strategy, it enters the queue at the end; in an unfair strategy, it attempts to be placed directly into the merge bucket, and if that fails, it enters the queue). Simultaneously, a cumulative count counter is maintained for each valid slot. This counter continuously counts the total number of location upload requests in that slot, including those already in the merge bucket and those waiting in the queue. The accuracy of this counter can be guaranteed under high concurrency scenarios through atomic operations. The monitoring process continuously polls or reads the cumulative count of all valid slots through event triggering and compares it with the target single-slot capacity in the capacity parameters, providing a basis for merge triggering decisions.

[0032] Sequence identifiers ensure local ordering and load balancing in request allocation. Meanwhile, accurate and real-time monitoring of accumulated quantities provides crucial data support for triggering batch merging at the appropriate time, making it a core element for achieving efficient and controllable request merging.

[0033] Step A3: When the cumulative number in any valid card slot reaches the target single-slot capacity in the capacity parameter, the location point upload requests in the valid card slots are merged to obtain the target request set.

[0034] Specifically, by monitoring the cumulative count counter of each valid slot in real time, when the cumulative count in a valid slot (including the total number of requests already entered into the merge bucket and queue) reaches the preset target single-slot capacity threshold, the merge processing flow for that slot is triggered. At this time, the valid slot is locked to prevent new requests from entering. Then, according to the order in which the requests entered (based on the sequence identifier), the corresponding number of location point upload requests are extracted from the merge bucket and queue of the slot. The core parameters of these requests (such as location coordinates, timestamps, etc.) are assembled into a complete target request set according to a predefined data structure. This set is essentially a structured data batch, containing the original request parameters of the target single-slot capacity number, and appending batch metadata (such as the starting sequence identifier, time range, etc.). After the assembly is completed, the cumulative count counter of the valid slot is reset and the slot lock is released, allowing it to start receiving new requests again. The generated target request set is then sent to the transmission buffer to wait for uploading to the downstream server.

[0035] Through precise capacity triggering mechanisms and atomic merging operations, the timeliness of batch processing is ensured, which not only avoids the impact of request backlog on real-time performance of a single card slot, but also effectively improves the processing efficiency of downstream servers through structured merging.

[0036] It should be noted that, Figure 2 The diagram shown is a flowchart illustrating the location point request upload method provided in an embodiment of this application. Figure 2 As shown, the process includes: the initial operation of the user initiating an upload location request; the upstream server sequentially executing key processing steps such as obtaining capacity parameters and merging multiple requests into a target request set; and finally, transmitting the batch data to the downstream server by uploading the target request set. The entire process demonstrates a technical solution that effectively reduces the processing pressure on the downstream server and optimizes network transmission efficiency through dynamically obtaining merging parameters, intelligently aggregating requests, and batch transmitting data.

[0037] In the embodiments of this application, such as Figure 3 As shown, the pre-configured capacity parameters of the preset card slot are obtained, including: Step S201: Monitor the triggering frequency of location upload requests within a preset time period.

[0038] In this embodiment, the monitoring process quantifies the request load by continuously tracking changes in the sequence identifier generated by the request numberer. First, a periodic timer and a sequence identifier sampler are maintained in memory. When a new preset time period begins, the initial sequence identifier value is recorded, and the final sequence identifier value is recorded at the end of the period. The total number of requests received within that period is obtained by calculating the identifier difference. Finally, the trigger frequency is obtained by dividing the identifier difference by the period duration. The calculation method based on sequential identifier differences avoids duplicate counting and can reflect the true request pressure per unit time. The monitoring process can use a circular buffer to store RPS data for multiple consecutive periods, providing historical trend references for subsequent capacity parameter adjustments.

[0039] Step S202: Obtain the status information of the preset card slot, and adjust the initial number of enabled cards in the preset card slot based on the trigger frequency and status information to obtain the target number of enabled cards.

[0040] In this embodiment, the monitoring process first obtains status information including the number of collisions and the average number of idle slots from the performance monitoring module. Then, it multiplies the real-time trigger frequency by a first proportional coefficient to obtain a first adjustment threshold. It first determines whether the number of collisions has reached the first adjustment threshold. If it has, a scaling-up strategy is used to double the initial number of active slots. If not, it further determines whether the average number of idle slots has reached a second adjustment threshold (the product of the initial number of active slots and the second proportional coefficient). If the condition is met, a scaling-down strategy is used to halve the initial number of active slots; otherwise, the original value is maintained. Finally, the adjusted value is determined as the target number of active slots. This two-level judgment mechanism enables elastic scaling of slot resources, ensuring reduced collisions during high concurrency and avoiding resource waste during low load.

[0041] As an example, assuming the initial number of enabled devices is 8, the detected trigger frequency is 200 RPS, and the first scaling factor is 0.25: First, the first adjustment threshold is calculated to be 50. If the number of collisions detected is 60 (greater than 50), then expansion is initiated to set the target number of enabled devices to 16. If the number of collisions is 40 (less than 50) and the average number of idle devices detected is 5, the second adjustment threshold is calculated to be 4 (8 × 0.5). Since 5 > 4, shrinkage is initiated to set the target number of enabled devices to 4. If none of the above conditions are met, then the target number of enabled devices remains at 8.

[0042] Step S203: Obtain the request processing efficiency and the number of aggregate uploads of the downstream server within a preset time period, and configure the target single-slot capacity of the preset card slot based on the trigger frequency, request processing efficiency and the number of aggregate uploads.

[0043] In this embodiment, the monitoring process first obtains the request processing efficiency (TPS, representing the maximum number of transactions processed per second by the downstream service) through the downstream service inspection interface. Simultaneously, it counts the number of times the local upload module successfully sends the target request set to the downstream within the same preset time period. Then, it divides the trigger frequency by the request processing efficiency to obtain a base ratio, multiplies this ratio by the number of times the request set is uploaded, and finally rounds the product to set the target single-slot capacity. This calculation process ensures that the single-slot capacity reflects both the matching relationship between upstream and downstream processing capabilities and the execution frequency of actual merging operations, ensuring that the merging scale always maintains optimal adaptation to the real-time system load. Furthermore, setting upper and lower capacity limits (e.g., minimum 10, maximum 100) can prevent extreme anomalies in the calculation results.

[0044] As an example, suppose the trigger frequency is monitored to be 300 RPS, the downstream request processing efficiency is 100 TPS, and the collection upload count is 5 times: First, calculate the ratio as 300 / 100=3, then calculate the target single slot capacity as 3×5=15, that is, dynamically adjust the combined capacity of each card slot to 15 requests.

[0045] Step S204: Configure the target number of enabled cards and the target single-slot capacity to the preset card slot capacity parameters.

[0046] In this embodiment, the monitoring process dynamically calculates the target number of enabled slots and the determined target single-slot capacity, and synchronously updates them to the global configuration management area of ​​the upstream server through atomic write operations, forming a set of capacity parameters that are officially effective within the current statistical period. A version number mechanism is used to ensure the atomicity and consistency of configuration updates: an incrementing version identifier is generated with each update, and all request processing threads automatically obtain the latest version of the capacity parameters at the period switching point. After the configuration takes effect, the target number of enabled slots will directly determine the number of valid slots that can process requests in parallel in the next period, while the target single-slot capacity serves as the threshold for the number of requests that trigger batch merging for each slot. Together, they constitute the core control parameters for adaptive adjustment.

[0047] As an example, when the monitoring process calculates that the target number of enabled slots is 8 and the target single slot capacity is 15, it updates this pair of values ​​to the configuration center as new capacity parameters. Thereafter, all new location point requests will be allocated to 8 valid slots, and each slot will automatically trigger a merge when it accumulates 15 requests, thereby achieving dynamic optimization of processing capacity based on real-time load.

[0048] It should be noted that, Figure 4 This is a schematic diagram of the location request processing component provided in an embodiment of this application, as shown below. Figure 4 As shown, this component comprises three core parts: a location point request representing the raw location data input from the user; a request numberer responsible for generating a global sequence identifier for each arriving request, ensuring the traceability and timing of requests; and a monitoring request / collision count / n, which collects and statistically analyzes key operational metrics in real time, including the total number of requests, the number of slot collisions, and the actual number of requests to downstream servers n. Real-time data, through dynamic calculations by the monitoring process, provides a basis for decision-making in adjusting the number of slots and batch size, ultimately achieving the technical effect of adaptively optimizing request processing efficiency based on system load.

[0049] In this embodiment of the application, monitoring the triggering frequency of location upload requests within a preset time period includes: Step B1: Generate the sequence identifier of each location's upload request according to the request time.

[0050] Specifically, after successfully receiving and verifying each upload request from a location point, the upstream server's request numberer generates a unique sequence identifier based on the time the request arrived at the server (usually a nanosecond-level timestamp from the server's system clock) and a globally atomic incrementing counter. This sequence identifier typically consists of a high-order timestamp and a low-order sequence number. The timestamp ensures that requests are ordered chronologically, while the sequence number (incremented atomically to ensure thread safety) distinguishes multiple requests within the same time point, thus forming a globally unique and monotonically increasing identifier. The sequence identifier not only records the absolute temporal relationship of requests but also provides crucial information for subsequent request allocation, slot routing, and merging order. The generation of the sequence identifier can also incorporate elements such as server instance identifiers to support uniqueness guarantees in a distributed environment, but the core principle is to ensure the temporal order and uniqueness of the identifier, providing the system with an accurate request sequence benchmark.

[0051] Step B2: Calculate the change in the sequence identifier's number within a preset time period.

[0052] Specifically, the monitoring process starts at the beginning of a preset time period (e.g., 1 second). Record the latest sequence identifier value as the starting identifier. At the end of the cycle Record the latest sequence identifier value as the end identifier. By calculating the difference between the end identifier and the start identifier (i.e. This yields the change in the serial number within the statistical period. The change directly represents the change in... The absolute number of location upload requests received within a time window is the core metric for quantifying request frequency. In implementation, atomic operations are used to read the current value of the sequence identifier to ensure data accuracy, while handling potential wraparounds in the sequence identifier counter (resetting it when it reaches its maximum value). This change in the sequence identifier serves as the basis for subsequent calculations of trigger frequencies (such as RPS - requests per second), providing accurate and real-time data on request volume changes for dynamically adjusting capacity parameters.

[0053] Step B3: Determine the trigger frequency of location point upload requests within a preset time period based on the change in the number.

[0054] Specifically, the monitoring process will calculate the change in the number. Divide by the duration of the preset time period (Unit: seconds) This yields the average request rate within that period, i.e., the trigger frequency (Requests Per Second, RPS). The calculation formula is as follows: The trigger frequency directly reflects the density of location point requests received within a statistical period, and is a key input indicator for subsequent dynamic adjustment of slot capacity parameters. Additionally, algorithms such as sliding window averaging or exponentially weighted moving average can be used to smooth the RPS over multiple consecutive periods to eliminate the impact of instantaneous fluctuations, thereby obtaining a more stable trigger frequency estimate and providing a more accurate and reliable representation of request load.

[0055] In this embodiment of the application, the initial number of enabled cards in a preset slot is configured and adjusted based on the trigger frequency and status information to obtain the target number of enabled cards, including: Step C1: Determine the first adjustment threshold based on the trigger frequency and the first proportional coefficient.

[0056] Specifically, the monitoring process multiplies the real-time trigger frequency (RPS, i.e., requests per second) with a predefined first proportional coefficient (set based on system tolerance and historical experience, e.g., 0.25) to obtain a first adjustment threshold. The calculation formula is: First Adjustment Threshold = Trigger Frequency × First Proportional Coefficient. This first adjustment threshold is a dynamically changing value, directly correlated with the current request load. It is used to subsequently determine whether frequent request collisions are due to insufficient card slot resources, thus providing a quantitative adaptation benchmark for card slot expansion decisions. Through this calculation, the abstract request frequency is transformed into a concrete critical value that can be used for logical judgment, achieving an effective connection between monitoring indicators and resource allocation decisions.

[0057] Step C2: Extract the number of collisions from the status information and determine whether the number of collisions is greater than or equal to the first adjustment threshold.

[0058] Specifically, the monitoring process reads the cumulative number of collisions (i.e., the number of conflicts recorded when a request is assigned to a valid slot that is being processed and cannot immediately receive new requests) within a preset time period from the maintained status information storage area (usually shared memory or performance counters). This value is then compared with a calculated first adjustment threshold. The status information is a set of performance metrics recorded at runtime, including the number of collisions and the number of free slots. The judgment result (yes or no) directly determines whether to trigger a subsequent adjustment of the number of slots: if the number of collisions is greater than or equal to the first adjustment threshold, it indicates that significant request conflicts have occurred under high concurrency, and the existing number of slots is insufficient to effectively distribute the request load; otherwise, it indicates that the conflicts are within an acceptable range. This judgment mechanism directly links real-time load with resource configuration through quantitative metrics, providing a precise decision-making basis for dynamic adjustments.

[0059] Step C3: If the number of cards is greater than or equal to the first adjustment threshold, the initial number of cards to be enabled is configured and adjusted using the capacity expansion adjustment strategy to obtain the target number of cards to be enabled; or, if the number of cards to be enabled is less than the first adjustment threshold, the number of idle cards in the status information is extracted and the initial number of cards to be enabled in the preset card slot is configured and adjusted according to the number of idle cards to obtain the target number of cards to be enabled.

[0060] In this embodiment of the application, the initial number of activated cards in a preset card slot is configured and adjusted based on the number of idle slots to obtain the target number of activated cards, including: Step C301: Determine the second adjustment threshold based on the initial number of activated units and the second proportional coefficient, and determine whether the number of idle units is greater than or equal to the second adjustment threshold.

[0061] Specifically, the monitoring process multiplies the current initial number of active slots (i.e., the number of effective slots before adjustment) by a predefined second proportional coefficient (e.g., 0.5) to calculate the second adjustment threshold (the formula is: Second Adjustment Threshold = Initial Number of Active Slots × Second Proportional Coefficient). Simultaneously, it extracts the average number of idle slots obtained through multiple instantaneous samplings within the statistical period from the status information (i.e., the arithmetic mean of the number of slots not assigned requests at all sampling times). This average is then compared with the second adjustment threshold to determine if it is greater than or equal to the threshold. This determination aims to identify whether the system is in a prolonged low-load state: if the average number of idle slots consistently reaches or exceeds the second adjustment threshold, it indicates that the number of currently active slots is excessive, resulting in idle resources, providing a quantitative basis for potential subsequent scaling-down adjustments.

[0062] In step C302, if the initial number of enabled devices is greater than or equal to the second adjustment threshold, the initial number of enabled devices is configured and adjusted using a scaling-down adjustment strategy to obtain the target number of enabled devices. Alternatively, if the initial number of enabled devices is less than the second adjustment threshold, the target number of enabled devices is determined to be the initial number of enabled devices.

[0063] Specifically, when the monitoring process determines that the average number of idle slots reaches or exceeds the second adjustment threshold, a scaling-down adjustment strategy is immediately triggered. This strategy halves the current initial number of active slots (e.g., from 8 slots to 4 slots) and uses the calculated result as the new target number of active slots. At the same time, it ensures that the target number of active slots is not lower than the preset minimum number of slots (e.g., 2 slots) to guarantee basic processing capacity. If the average number of idle slots is less than the second adjustment threshold, it means that the current slot resource utilization rate is within a reasonable range. The existing configuration is maintained, and the value of the initial number of active slots is directly assigned to the target number of active slots.

[0064] By using quantitative judgment and conditional triggering, the system can accurately reclaim card slot resources during low-load periods, effectively avoiding long-term idleness of computing resources. At the same time, by ensuring a minimum number of resources, the system can always have basic request processing capabilities.

[0065] In this embodiment of the application, the target single-slot capacity of the preset card slot is configured based on the triggering frequency, request processing efficiency, and the number of aggregate uploads, including: Step D1: Calculate the ratio between trigger frequency and request processing efficiency.

[0066] Specifically, the monitoring process divides the determined trigger frequency (RPS, representing the number of location point requests received per second by the upstream server) by the request processing efficiency (TPS, representing the maximum number of request transactions that the downstream server can process per second), obtaining the ratio between the two (the formula is: Ratio = Trigger Frequency / Request Processing Efficiency). This ratio quantitatively characterizes the proportional relationship between the upstream request influx rate and the downstream maximum service capacity, serving as a key indicator for assessing load pressure and bottlenecks. The calculation typically uses the real-time RPS value from the most recent statistical period and the preset or dynamically reported TPS benchmark value from the downstream service to ensure the timeliness and accuracy of the ratio. As a core input parameter, the ratio provides a theoretical basis for subsequently calculating a reasonable target single-slot capacity, enabling the merging strategy to adapt to the actual processing capacity of the downstream.

[0067] Step D2: Multiply the ratio by the number of uploads to obtain the product value, and configure the product value as the target single-slot capacity of the preset card slot.

[0068] Specifically, the monitoring process multiplies the calculated ratio (the quotient of trigger frequency RPS and downstream request processing efficiency TPS) with the number of aggregate uploads (i.e., the actual number of times the target request set was successfully sent to the downstream server within the same preset time period) to obtain a product value (the calculation formula is: target single-slot capacity = (RPS / TPS) * n, where n represents the number of aggregate uploads). This product value is then rounded down and set as the target single-slot capacity of the preset slot. The calculation process essentially couples the theoretically required merging scale (determined by the upstream and downstream processing capacity ratio) with the actual merging operation frequency, thereby dynamically determining the most reasonable request capacity for each slot. The capacity value obtained through this formula ensures that the merged batch requests do not exceed the downstream processing capacity (through TPS constraints) while fully utilizing the efficiency of the merged operations already performed (reflected by n), ultimately achieving an optimal balance between load pressure and real-time performance. The calculated target single-slot capacity is ensured to be between the preset minimum and maximum values ​​to guarantee system stability and reliability.

[0069] This embodiment also provides a location point request uploading device, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0070] This embodiment provides a location point request upload device, applied to the upstream server side, such as... Figure 5 As shown, it includes: The receiving module 51 is used to receive multiple location point requests uploaded by the user terminal; The processing module 52 is used to obtain the pre-configured capacity parameters of the preset card slot, and to merge the location point requests based on the capacity parameters to obtain at least one target request set. Upload module 53 is used to upload the target request set to the downstream server associated with the upstream server.

[0071] In this embodiment of the application, the apparatus further includes: The monitoring module is used to monitor the triggering frequency of location upload requests within a preset time period; The first determining module is used to obtain the status information of the preset card slot, and to adjust the initial number of enabled cards in the preset card slot based on the trigger frequency and status information to obtain the target number of enabled cards. The second determining module is used to obtain the request processing efficiency and the number of aggregate uploads of the downstream server within a preset time period, and to configure the target single-slot capacity of the preset card slot based on the trigger frequency, request processing efficiency and the number of aggregate uploads. The configuration module is used to configure the target number of enabled cards and the target single-slot capacity to the preset card slot capacity parameters.

[0072] In this embodiment, the monitoring module is specifically used to generate a sequence identifier for each location upload request according to the request time; calculate the number change of the sequence identifier within a preset time period; and determine the trigger frequency of the location upload request within the preset time period based on the number change.

[0073] In this embodiment of the application, the first determining module is specifically used to determine a first adjustment threshold based on the triggering frequency and a first proportional coefficient; extract the number of collisions from the status information and determine whether the number of collisions is greater than or equal to the first adjustment threshold; if it is greater than or equal to the first adjustment threshold, then the initial enabled quantity is configured and adjusted using the expansion adjustment strategy to obtain the target enabled quantity; or, if it is less than the first adjustment threshold, then the number of idle slots is extracted from the status information and the initial enabled quantity of the preset card slot is configured and adjusted according to the number of idle slots to obtain the target enabled quantity.

[0074] In this embodiment of the application, the first determining module is specifically used to determine a second adjustment threshold based on the initial activation quantity and a second proportional coefficient, and to determine whether the idle quantity is greater than or equal to the second adjustment threshold; if it is greater than or equal to the second adjustment threshold, the initial activation quantity is configured and adjusted using a scaling-down adjustment strategy to obtain the target activation quantity; or, if it is less than the second adjustment threshold, the initial activation quantity is determined to be the target activation quantity.

[0075] In this embodiment of the application, the second determining module is specifically used to calculate the ratio between the triggering frequency and the request processing efficiency; multiply the ratio by the number of uploads to obtain the product value; and configure the product value as the target single-slot capacity of the preset card slot.

[0076] In this embodiment of the application, the processing module 52 is specifically used to determine the effective card slots in the preset card slots based on the target number of enabled slots in the capacity parameters; to allocate the location point upload requests to the effective card slots according to the sequential identifiers, and to monitor the cumulative number of location point upload requests in each effective card slot; when the cumulative number in any effective card slot reaches the target single slot capacity in the capacity parameters, to merge the location point upload requests in the effective card slots to obtain the target request set.

[0077] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of a computer device provided in an optional embodiment of the present invention, such as... Figure 6 As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system).

[0078] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0079] The memory 20 stores instructions executable by at least one processor 10 to cause at least one processor 10 to perform the method shown in the above embodiments.

[0080] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device as shown by a landing page for an app. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, which can be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0081] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0082] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0083] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0084] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and all such modifications and variations fall within the scope defined by the appended claims.

Claims

1. A location point request uploading method, applied to an upstream server end, characterized in that, The method comprises: receiving a plurality of location point requests uploaded by a user terminal; obtaining a capacity parameter pre-configured for a preset card slot, and performing merging processing on the location point requests based on the capacity parameter to obtain at least one target request set; uploading the target request set to a downstream server associated with the upstream server.

2. The method of claim 1, wherein, The obtaining of the capacity parameter pre-configured for the preset card slot comprises: monitoring a triggering frequency of location point uploading requests within a preset time period; obtaining state information of the preset card slot, and performing configuration adjustment on an initial enabled number of the preset card slot based on the triggering frequency and the state information to obtain a target enabled number; obtaining a request processing efficiency and a set uploading frequency of the downstream server within a preset time period, and configuring a target single-slot capacity of the preset card slot based on the triggering frequency, the request processing efficiency and the set uploading frequency; configuring the target enabled number and the target single-slot capacity as the capacity parameter of the preset card slot.

3. The method of claim 2, wherein, The monitoring of the triggering frequency of location point uploading requests within a preset time period comprises: generating a sequence identifier of each location point uploading request according to a request time; calculating a number variation of the sequence identifier within the preset time period; determining the triggering frequency of location point uploading requests within the preset time period according to the number variation.

4. The method of claim 2, wherein, The configuration adjustment on the initial enabled number of the preset card slot based on the triggering frequency and the state information to obtain a target enabled number comprises: determining a first adjustment threshold based on the triggering frequency and a first proportion coefficient; extracting a collision frequency from the state information, and determining whether the collision frequency is greater than or equal to the first adjustment threshold; if the collision frequency is greater than or equal to the first adjustment threshold, performing configuration adjustment on the initial enabled number by using an expansion adjustment strategy to obtain a target enabled number; or if the collision frequency is less than the first adjustment threshold, extracting an idle number from the state information, and performing configuration adjustment on the initial enabled number of the preset card slot according to the idle number to obtain a target enabled number.

5. The method of claim 4, wherein, The configuration adjustment on the initial enabled number of the preset card slot according to the idle number to obtain a target enabled number comprises: determining a second adjustment threshold based on the initial enabled number and a second proportion coefficient, and determining whether the idle number is greater than or equal to the second adjustment threshold; if the idle number is greater than or equal to the second adjustment threshold, performing configuration adjustment on the initial enabled number by using a contraction adjustment strategy to obtain a target enabled number; or if the idle number is less than the second adjustment threshold, determining the initial enabled number as the target enabled number.

6. The method of claim 2, wherein, The configuration of the target single-slot capacity of the preset card slot based on the triggering frequency, the request processing efficiency and the set uploading frequency comprises: calculating a ratio between the triggering frequency and the request processing efficiency; multiplying the ratio and the set uploading frequency to obtain a product value, and configuring the product value as the target single-slot capacity of the preset card slot.

7. The method of claim 1, wherein, The merging processing of the position point requests based on the capacity parameters obtains at least one target request set, and the merging processing comprises: determining effective card slots in the preset card slots based on a target enabled number in the capacity parameters; allocating the position point upload requests to the effective card slots according to sequence identifiers and monitoring accumulated numbers of the position point upload requests in each of the effective card slots; when the accumulated number in any of the effective card slots reaches a target single-slot capacity in the capacity parameters, performing the merging processing on the position point upload requests in the effective card slot to obtain the target request set.

8. A location point request uploading apparatus, applied to an upstream server end, characterized in that, The device comprises: a receiving module configured to receive a plurality of position point requests uploaded by a user end; a processing module configured to obtain capacity parameters pre-configured for preset card slots and perform merging processing on the position point requests based on the capacity parameters to obtain at least one target request set; an uploading module configured to upload the target request set to a downstream server end associated with the upstream server end.

9. A computer device, comprising: comprise: a memory and a processor, which are in communication connection with each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the method in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer instructions, and the computer instructions are used to make the computer execute the method in any one of claims 1 to 7.

Images