Does Looping API Calls Affect System Performance?

I am working on a process model where I use an integration to call an API. The API contains about 82,000 records, but it returns only 100 records per request. To retrieve all the data, I use a loop. After each API call, I save the 100 records using a record type. Does this slow down the environment if I delete the instance after every successful run?

  Discussion posts and replies are publicly visible

  • 0
    Certified Lead Developer

    I do not consider this to be a platform performance risk, but it might still be a good idea to run this in non-office hours.

  • Our server's CPU is at 100% usage. When we raised a ticket with Appian, they pointed out that one record type is taking too long to load, which is slowing down the UI. The UI uses a read-only grid, and the performance of the record type is causing delays. Could you please suggest ways to optimize performance and reduce CPU usage?

  • 0
    Certified Lead Developer
    in reply to rajeshp7374

    Is your question about UI, or your syncing process?

    Do you have a specific reason to implement your own syncing logic instead of using the standard?

    This might be a starting point: https://community.appian.com/success/w/article/3402/analyzing-performance-issues

  • My question is regarding the record type. When I tried to load data with over 80k records, the UI and the entire environment became unresponsive due to high CPU usage. However, after cleaning the data, I tested it with more than 1k records, and now the environment and UI are responding as expected. Could loading 80K data with Syc enabled record be a reason for high CPU usages?

  • 0
    Certified Lead Developer
    in reply to rajeshp7374

    Sure, that "could" be the problem. But to be sure about this, you will have to dive into a real detailed performance analysis.

  • Slow Request Performance Analysis This section highlights slow-performing URIs (pages or API calls). Key Observations

    • Major performance issue:
    • /suite/sites/AppName/site
    • 41 requests
    • Total execution time: 473,079.92 seconds (~131 hours)
    • Avg response time: 11,538.53 seconds (~3.2 hours)
    • Max time: 18,500.22 seconds (~5.1 hours)

    → Severe performance issue, possibly a stuck process or heavy computation.

    • Other slow pages:
    • /suite/sites/AppName/pages/AppName/interface
    • 28 requests
    • Avg response time: 3,114.71 seconds (~52 minutes)
    • Max time: 17,471.77 seconds (~4.8 hours)
    • /suite/design/... (Various design-related pages)
    • Avg response time: ~4,343 seconds (~1.2 hours)

    Implications

    • The /AppName/site page is causing massive delays, leading to system overload.
    • Long response times likely contributed to high CPU load.
    • This may indicate inefficient database queries, heavy background processing, or session-related issues.


    [2] Slow Request performance statistics

    uri count sum % avg (s) max (s)
    /suite/sites/AppName/site 41 473079.92 79.56 11538.53 18500.22
    /suite/sites/AppName/pages/AppName/interface 28 87212.01 14.67 3114.71 17471.77
    /suite/design/lUBxqdIsJW2hDEvprwM-zMzRNUU4-zm0unQGy4e1n4FB5b5YDdAYj5wikPlvydk7ltens1lCG9DN7UH28unsNfxD-yWf3E1T2MQtk2oDbd62uhtouU_ 4 17375.13 2.92 4343.78 4666.30
    /suite/design/lUBxqdIsJW2hDEvprwM-zMzRNUU4-zhhLrQM94pHpbtpTkjZvScvuvI-QYwT0NGIutSUHnWUXjvqQglJqifgKRFCO2FeHHv4GLNcBhxqmIXmvBZdTEv 82 3080.35 0.52 37.57 249.43