Pith. sign in

REVIEW 3 major objections 6 minor 22 references

SealOS+: A Sealos-based Approach for Adaptive Resource Optimization Under Dynamic Workloads for Securities Trading System

T0 review · 3 major / 6 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read SealOS+ claims a securities trading platform can hit 78% CPU utilization, 105ms response, and 15,000 TPS through adaptive scheduling, three-level caching, and LSTM load prediction.

desk verdict The paper's own numbers contradict its headline claim, so the empirical core cannot be trusted. read the letter →

arxiv 2505.23258 v1 pith:VBZPQV4F submitted 2025-05-29 cs.DC

Haojie Jia , Zhenhao Li , Gen Li , Minxian Xu , Kejiang Ye This is my paper
classification cs.DC
keywords SealosKubernetesdeepreinforcementlearningLSTMloadpredictionthree-levelcachesecuritiestradingadaptiveresourcescheduling
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper tries to show that a commodity container orchestration platform, Sealos enhanced into SealOS+, can be made fast enough for securities trading by adding three components: a deep-reinforcement-learning scheduler, a three-level cache, and an LSTM load forecaster. The reported result is an average CPU utilization of 78%, a transaction response time of 105ms, and a peak throughput of 15,000 transactions per second in a securities-exchange deployment, with trading-chain processing dropping from 150ms to 40ms against a 50ms requirement. A sympathetic reader would take the paper's core claim to be that software-level scheduling and caching changes, not custom hardware, are what unlock low-latency trading on container platforms.

What carries the argument

The load-bearing machinery is a Markov Decision Process formulation of resource scheduling, where the state vector packs load, resource utilization, queue length, history, and performance metrics, and a hybrid genetic-algorithm/DRL policy—using Dueling DQN with PPO updates—chooses instance counts, migrations, priorities, and resource quotas. Around that scheduler sit two supporting mechanisms: a three-level cache (LRU local memory, Redis with consistent hashing, persistent storage) coordinated by MVCC, and an LSTM network with 18 input features that predicts trading volume so the scheduler can scale ahead of surges.

What would settle it

Re-create the described test on 20 Xeon Gold 6248R servers: run the 8-module trading workload under a Poisson-distributed JMeter load rising to 10,000 concurrent users, and check whether average response time stays at or below 105ms while peak throughput reaches 15,000 TPS; if the trading-chain processing time does not fall from 150ms to 40ms, the central claim fails.

Watch

Extended reading notes

Core claim

The central discovery is that the interaction of an adaptive DRL scheduler, a three-level cache hierarchy, and LSTM-based load prediction moves a Sealos cluster's performance into exchange-compliant territory. In the authors' measurements, the optimized system cut trading-chain processing time from 150ms to 40ms, raised node CPU utilization from 45% to 78%, lowered average transaction response time from 180ms to 105ms, and increased peak capacity from 8,000 TPS to roughly 15,000 TPS, while keeping service availability at 99.99%.

Load-bearing premise

The reported numbers all rest on the assumption that the production deployment at an unnamed securities company happened as described and that the comparisons against VMs, native Kubernetes, and plain Sealos ran under equivalent workloads.

Editorial extensions

If this is right

  • Trading exchanges can meet a 50ms end-to-end SLA using software-only container-platform tuning, without bespoke hardware.
  • The same three mechanisms can be ported to futures and fund trading systems, which the paper names as future work and which share the same bursty load profile.
  • Proactive LSTM-based scaling should cut over-provisioning during tidal market loads, since resources are adjusted before the surge rather than after.
  • The three-level cache's 80% read-from-memory hit rate implies database access frequency can drop by 90%, reducing a common bottleneck in clearing and risk control.
  • With 78% average CPU utilization, the platform demonstrates that container scheduling overhead need not force low utilization targets in production.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the LSTM predictor's 92% accuracy transfers to other exchanges, the largest operational gain may come from pre-scaling at market open rather than from the DRL policy itself; an ablation study separating the two would clarify which component carries the improvement.
  • The reported 99.99% availability and 99.95% deployment success suggest the platform could also host other latency-sensitive financial services, such as real-time risk monitoring, where the same cache and scheduling structure applies.
  • A testable extension is to replace the fixed reward weights w1, w2, w3 with an online-adaptive weighting scheme, since fixed weights may over-prioritize response time when load is low.
  • The 92% load prediction accuracy was measured on one dataset; its generalizability to other market regimes, such as circuit-breaker events, remains an open question.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

Summary. The paper proposes SealOS+, a container orchestration optimization for securities trading built on Sealos, combining deep reinforcement learning (DRL)-based adaptive resource scheduling, a three-level caching mechanism, and an LSTM-based load prediction model. The central claim is that a real-world deployment at a securities exchange achieves an average CPU utilization of 78%, reduces transaction response time to 105ms, reaches a peak processing capacity of 15,000 transactions per second, and thereby meets the exchange's 50ms response-time requirement. The evaluation compares SealOS+ against VM, native Kubernetes, and default SealOS deployments using response time, resource utilization, throughput, and other indicators.

Significance. The application domain is relevant and the performance target is concrete and falsifiable: a per-transaction average processing time of no more than 50ms at 5,000 TPS normal and 15,000 TPS peak. If substantiated, the system would be a useful case study for low-latency container orchestration in financial trading. The paper also describes a realistic combination of techniques (DRL scheduling, caching, load prediction) and reports a deployment at a securities company. However, no code, raw data, or test scripts are provided, and the headline numbers are internally inconsistent. The design choices are plausible, but the central empirical claim is contradicted by the manuscript's own reported measurements, so the contribution as written cannot be accepted.

major comments (3)
  1. [§V.A.2, §V.C.1, §V.B.3, §VI] The paper's stated SLA contradicts the reported results. Section V.A.2 defines the requirement as an average processing time of no more than 50ms per transaction at 5,000 TPS under normal conditions and 15,000 TPS during peaks. Section V.C.1 reports an average end-to-end latency of 85ms at 5,000 TPS, with 95% of requests within 120ms. Section V.B.3 reports a production average response time of 105ms during the opening collective bidding phase. Table IV reports average response times from 95ms at 2,000 concurrent users to 285ms at 10,000 users. None of these measurements satisfy the 50ms SLA. The conclusion in Section VI instead cites "trading chain processing time" reduced from 150ms to 40ms and claims this meets the 50ms requirement, but this metric is not defined or measured earlier in the paper and cannot be equated with the per-transaction response time specified in Section V.A.2. The central claim that the system meets the exchange's 50ms requirement is therefore contradicted by the paper's own data.
  2. [§V.B, Abstract, Table III] The headline performance numbers are internally inconsistent, making the quantitative evaluation impossible to interpret as reported. CPU utilization is given as 72% in Section V.B.1, 78% in Sections V.B.2 and V.B.3, 65% in Section V.D.1, and 68% in Table V. Peak processing capacity is reported as 15,000 TPS in the Abstract, 14,800 TPS in Section V.B.3, and 25,000 TPS in Table III, where the "85% improvement" column also does not match the stated baseline values. Because these figures constitute the primary evidence for the paper's contribution, the contradictions undermine the credibility of the evaluation.
  3. [§V.A] The baseline comparisons are not reproducible and their comparability is not established. Section V.A describes the hardware configuration and a JMeter pressure test model, but no raw measurements, test scripts, workload definitions, or deployment artifacts are provided. It is unclear whether the VM, native Kubernetes, and default SealOS baselines were run on the same 20-node cluster with identical microservice versions, identical workloads, and identical measurement intervals. Without this information, the claimed percentage improvements (for example, 23% CPU, 35% memory, and 52% disk I/O in Section V.B.1) are unverifiable, and the causal attribution of these gains to SealOS+ is not supported.
minor comments (6)
  1. [§IV.A, Eq. (1), Eq. (2)] The notation is confusing: the state vector in Eq. (1) includes p as a performance metric, while the action vector in Eq. (2) uses p for service processing priority. Use distinct symbols for these quantities.
  2. [§VI] The term "trading chain processing time" is introduced in the conclusion without a definition or a citation to a measurement in Section V. Either define this metric and present its measurements, or remove it.
  3. [§II.C, §VI] The LSTM model is said to predict trading volume with "92% accuracy," but no training/test split, error metric, baseline comparison, or confidence interval is reported. State how accuracy is computed and how the prediction contributes to the end-to-end results.
  4. [§V.B.3, Table III] Several percentage improvements in Table III are inconsistent with the raw numbers: 45ms to 19ms is a 58% reduction, not 60%, and 90s to 35s is approximately 61%, not 60%. Recalculate and unify the reported percentages.
  5. [§IV.B, Eq. (6), Eq. (7)] The algorithm description mixes a Dueling DQN value decomposition (Eq. 6) with a PPO policy objective (Eq. 7). Clarify which reinforcement learning method is actually implemented and how the genetic algorithm, Dueling DQN, and PPO components interact in Algorithm 1.
  6. [§III.B.2] The improvement scheme mentions a "65-second system startup time," "99.95% deployment success rate," and "20,000 API requests per second" that are not revisited in the experimental evaluation. Present these as design targets or provide measurements in Section V.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the reported performance metrics are experimental outcomes, not quantities derived by construction from the paper's equations or self-citations.

full rationale

The paper's central claim is an empirical deployment result (78% CPU utilization, 105ms response time, roughly 15,000 TPS), supported by pressure tests, monitoring, and comparison experiments in Section V. The reward functions in Eq. 3 and Eq. 11 and the fitness function in Eq. 8 do encode response time, resource utilization, and load balance as optimization objectives, and the reported metrics overlap with those objectives; however, the experimental values are measured outcomes of a deployed system rather than algebraic consequences of the equations. The reward design does not force any particular measured latency or utilization, and the reported latencies (85ms, 105ms, up to 285ms) actually fail the paper's own 50ms requirement, which shows the results are not tautologically derived from the objective. The self-citations (e.g., [2], [14], [15]) appear only in related-work discussion and are not used as load-bearing evidence for the deployment claims. No fitted parameter is renamed as a prediction, no uniqueness theorem is imported from the authors, and no ansatz is smuggled in via citation. The paper's internal metric contradictions and lack of raw data are validity concerns, not circularity.

Assumptions & free parameters 5 free parameters · 4 assumptions · 0 invented entities

The central claims rest on unverified deployment data, hand-chosen hyperparameters, and generic MDP/DRL formalizations. No independent evidence of the measured improvements is provided, and the reported metrics are internally inconsistent.

free parameters (5)
  • Reward weights in Eq. 8 = w1=0.4, w2=0.35, w3=0.25
    Chosen by hand to balance response time, resource utilization, and load balance; no sensitivity analysis is provided.
  • Reward weights in Eq. 11 = not reported
    The coefficients α, β, and γ are never specified, making the RL reward function impossible to reproduce.
  • LSTM architecture hyperparameters = 3 layers, 128 neurons, dropout 0.3
    Ad hoc choices with no ablation or justification.
  • Cache expiration times = L1=10s, L2=60s, L3=permanent
    Hand-picked values with no sensitivity analysis.
  • DRL discount factor and PPO clip parameter = not reported
    These parameters are required to reproduce Eq. 4 and Eq. 7 but are omitted.
assumptions (4)
  • domain assumption Trading workloads can be modeled as a Markov Decision Process with state s={l,r,q,h,p} and transition f(s,a)+epsilon.
    Section IV.A defines this without validation. If the system dynamics do not satisfy the MDP assumptions, the DRL formulation is not meaningful.
  • domain assumption The reported bottleneck analysis numbers (45% network overhead, 280ms cross-node latency, 85% scheduling CPU, 15,000 random writes per second) come from real runtime data.
    Section III.B.1 asserts these figures without providing the source dataset or collection protocol.
  • ad hoc to paper Optimizing the reward function that includes response time, resource utilization, and cost directly leads to meeting the exchange's 50ms SLA.
    No mapping between the reward components and the SLA is shown, and the reported 105ms response time contradicts the SLA.
  • domain assumption LSTM predictions with 92% accuracy enable proactive scheduling benefits.
    The paper reports an accuracy number but provides no causal evaluation linking prediction quality to resource allocation improvements.

how reviews work

0 comments
Cite this review

Pith. "Pith review of SealOS+: A Sealos-based Approach for Adaptive Resource Optimization Under Dynamic Workloads for Securities Trading System." pith.science (2026). https://pith.science/paper/VBZPQV4F

@misc{pith2026250523258,
  author       = {Pith},
  title        = {Pith review of: SealOS+: A Sealos-based Approach for Adaptive Resource Optimization Under Dynamic Workloads for Securities Trading System},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/VBZPQV4F}},
  note         = {Machine review of arXiv:2505.23258}
}
read the original abstract

As securities trading systems transition to a microservices architecture, optimizing system performance presents challenges such as inefficient resource scheduling and high service response delays. Existing container orchestration platforms lack tailored performance optimization mechanisms for trading scenarios, making it difficult to meet the stringent 50ms response time requirement imposed by exchanges. This paper introduces SealOS+, a Sealos-based performance optimization approach for securities trading, incorporating an adaptive resource scheduling algorithm leveraging deep reinforcement learning, a three-level caching mechanism for trading operations, and a Long Short-Term Memory (LSTM) based load prediction model. Real-world deployment at a securities exchange demonstrates that the optimized system achieves an average CPU utilization of 78\%, reduces transaction response time to 105ms, and reaches a peak processing capacity of 15,000 transactions per second, effectively meeting the rigorous performance and reliability demands of securities trading.

Figures

Figures reproduced from arXiv: 2505.23258 by the authors.

Figure 1
Figure 1. SealOS+ System Architecture Diagram. To this end, we formalize the resource scheduling problem as a Markov Decision Process (MDP). First, we define the state space, which contains key features of the system: A. System Model The state space of the system is defined as follows: s = {l, r, q, h, p}, (1) where l ∈ R dl represents the current load vector of each service, reflecting real-time request volume and processing… view at source ↗
Figure 2
Figure 2. Trading System Running Status (Response Time). [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗
Figure 3
Figure 3. Trading System Running Status (Transaction Volume). [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: SealOS+ performance compared with VM solution, Kubernetes and SealOS [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 5
Figure 5. Figure 5: End-to-End Response Time. 2) Latency Performance under Different Loads: A stepped load test evaluated the system’s latency performance across varying concurrency levels. As shown in Table IV, the average response latency increased from 95ms at 2000 concurrent users to …
Figure 6
Figure 6. Figure 6: Resource Utilization Over Time. 2) System Load: An in-depth analysis was performed on the system load, collecting key indicators such as average load, process count, and context switch count. As shown in Table V, under normal operating conditions, the system’s 1-minute…

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

22 extracted references · 20 canonical work pages

  1. [1]

    Domain-driven design for microser- vices: An evidence-based investigation.IEEE Transactions on Software Engineering, 2024

    Chenxing Zhong, Shanshan Li, Huang Huang, Xiaodong Liu, Zhikun Chen, Yi Zhang, and He Zhang. Domain-driven design for microser- vices: An evidence-based investigation.IEEE Transactions on Software Engineering, 2024

    work page 2024

  2. [2]

    Drpc: Distributed reinforcement learning approach for scalable resource provisioning in container-based clusters.IEEE Transactions on Services Computing, 2024

    Haoyu Bai, Minxian Xu, Kejiang Ye, Rajkumar Buyya, and Chengzhong Xu. Drpc: Distributed reinforcement learning approach for scalable resource provisioning in container-based clusters.IEEE Transactions on Services Computing, 2024

    work page 2024

  3. [3]

    Sealos: Develop, deploy, and scale in one seamless cloud platform

    Sealos. Sealos: Develop, deploy, and scale in one seamless cloud platform. https://sealos.io/, 2024. [Online; accessed 13-March-2025]

    work page 2024

  4. [4]

    Guangsheng Yu, Xu Wang, Wei Ni, and et al. Adaptive resource schedul- ing in permissionless sharded-blockchains: A decentralized multiagent deep reinforcement learning approach.IEEE Transactions on Systems, Man, and Cybernetics: Systems, 53(11):7256–7268, 2023

    work page 2023

  5. [5]

    Deep learning with long short-term memory networks for financial market predictions.European Journal of Operational Research, 270(2):654–669, 2018

    Thomas Fischer and Christopher Krauss. Deep learning with long short-term memory networks for financial market predictions.European Journal of Operational Research, 270(2):654–669, 2018

    2018

  6. [6]

    A review of recurrent neural networks: Lstm cells and network architectures.Neural computation, 31(7):1235–1270, 2019

    Yong Yu, Xiaosheng Si, Changhua Hu, and Jianxun Zhang. A review of recurrent neural networks: Lstm cells and network architectures.Neural computation, 31(7):1235–1270, 2019

    2019

  7. [7]

    Senthil G. A, K. Somasundaram, Arun M, N. Naga Saranya, R. Prabha, and D. Vijendra Babu. A novel hybrid gaaco algorithm for cloud computing using energy aware load balance scheduling. In2022 International Conference on Computer Communication and Informatics (ICCCI), pages 1–5, 2022

    work page 2022

  8. [8]

    Toward highly scalable load balancing in kubernetes clusters.IEEE Communications Magazine, 58(7):78–83, 2020

    Nguyen Nguyen and Taehong Kim. Toward highly scalable load balancing in kubernetes clusters.IEEE Communications Magazine, 58(7):78–83, 2020

    work page 2020

Show all 22 references
  1. [9]

    Arascaler: Adaptive resource autoscaling scheme using etimemixer for efficient cloud-native comput- ing.IEEE Transactions on Services Computing, PP:1–14, 01 2024

    Byeonghui Jeong and Young-Sik Jeong. Arascaler: Adaptive resource autoscaling scheme using etimemixer for efficient cloud-native comput- ing.IEEE Transactions on Services Computing, PP:1–14, 01 2024

    2024

  2. [10]

    Thangaraju

    Yeddula Sai Dhanush Reddy, Padumati Saikiran Reddy, Nithya Ganesan, and B. Thangaraju. Performance study of kubernetes cluster deployed on openstack,vms and baremetal. In2022 IEEE International Con- ference on Electronics, Computing and Communication Technologies (CONECCT), pa...

    2022

  3. [11]

    Angelo Marchese and Orazio Tomarchio.Network SLO-Aware Con- tainer Orchestration on Kubernetes Clusters, pages 96–104. 12 2024

    2024

  4. [12]

    Kubernetes scheduling: Taxonomy, ongoing issues and challenges.ACM Comput

    Carmen Carrión. Kubernetes scheduling: Taxonomy, ongoing issues and challenges.ACM Comput. Surv., 55(7), December 2022

    2022

  5. [13]

    Emiliano Casalicchio.Container Orchestration: A Survey, pages 221–

  6. [14]

    Brownout approach for adaptive management of resources and applications in cloud computing systems: A taxonomy and future directions.ACM Comput

    Minxian Xu and Rajkumar Buyya. Brownout approach for adaptive management of resources and applications in cloud computing systems: A taxonomy and future directions.ACM Comput. Surv., 52(1), January 2019

    2019

  7. [15]

    Machine learning-based orchestration of containers: A taxonomy and future directions.ACM Comput

    Zhiheng Zhong, Minxian Xu, Maria Alejandra Rodriguez, Chengzhong Xu, and Rajkumar Buyya. Machine learning-based orchestration of containers: A taxonomy and future directions.ACM Comput. Surv., 54(10s), September 2022

    2022

  8. [16]

    Drs: A deep reinforcement learning enhanced kubernetes scheduler for microservice-based system

    Zhaolong Jian, Xueshuo Xie, Yaozheng Fang, Yibing Jiang, Ye Lu, Ankan Dash, Tao Li, and Guiling Wang. Drs: A deep reinforcement learning enhanced kubernetes scheduler for microservice-based system. Software: Practice and Experience, 54(10):2102–2126, 2024

    2024

  9. [17]

    Noah: Reinforcement-learning-based rate limiter for microservices in large-scale e-commerce services.IEEE transactions on neural networks and learning systems, PP, 04 2023

    Zhao Li, Haifeng Sun, Zheng Xiong, Qun Huang, Zehong Hu, Ding Li, Shasha Ruan, Hai Hong, Jie Gui, Jintao He, Zebin Xu, and Yang Fang. Noah: Reinforcement-learning-based rate limiter for microservices in large-scale e-commerce services.IEEE transactions on neural networks and l...

    2023

  10. [18]

    Deep reinforcement learning for multiobjective optimization.IEEE Transactions on Cybernetics, 51(6):3103–3114, 2021

    Kaiwen Li, Tao Zhang, and Rui Wang. Deep reinforcement learning for multiobjective optimization.IEEE Transactions on Cybernetics, 51(6):3103–3114, 2021

    2021

  11. [19]

    Scaling container caching to larger networks with multi-agent reinforcement learning

    Austin Chen and Genya Ishigaki. Scaling container caching to larger networks with multi-agent reinforcement learning. In2024 33rd In- ternational Conference on Computer Communications and Networks (ICCCN), pages 1–5. IEEE, 2024

    2024

  12. [20]

    Proximal policy optimization with policy feedback.IEEE Transactions on Systems, Man, and Cybernetics: Systems, 52(7):4600–4610, 2021

    Yang Gu, Yuhu Cheng, CL Philip Chen, and Xuesong Wang. Proximal policy optimization with policy feedback.IEEE Transactions on Systems, Man, and Cybernetics: Systems, 52(7):4600–4610, 2021

    2021

  13. [21]

    In- cremental least-recently-used algorithm: Good, robust, and predictable performance.IEEE Transactions on Mobile Computing, 2025

    Jinbei Zhang, Chunpeng Chen, Kechao Cai, and John CS Lui. In- cremental least-recently-used algorithm: Good, robust, and predictable performance.IEEE Transactions on Mobile Computing, 2025

    2025

  14. [235]

    Springer International Publishing, Cham, 2019

    2019

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.