Have research and testing on Load Capacity for API

[kshitijrajsharma]

Tasks involved :

• Have research on proper handling of incoming request , make them hold until process is finished
• Parallel queries on api
• There is already existing services provided by FASTAPI , need to test performance of those with burger story explanation
• Local load testing to see performance of async and await functions

cc : @ramyaragupathy

[kshitijrajsharma]

Tested await and async process in fast api , didn't work out well with the workflow we have also tested with and without those function to evaluate performance Here . Decided to run API without async and await because they didn't work out very well than the previous workflow , It was holding the request and processing one at a time. Load testing is done for Geojson format Rawdata current snapshot endpoint, Code can be found Here . Currently export tool has 3 active workers launched by Dramatiq for a 4 core machine there will be 4 request coming per second maximum , other request will be put on que on export tool

Loading Testing Parameters : First I analyzed Last 90 Days exports of export tool until july 4 Average export is of 90.3 MB , Full sheet is available here

I have selected capital Nepal with all data in it , file size was 146 MB ( Taken in to consideration by looking in to average size of export )

• Hence first load testing was done with 4 constant users hitting API

100 % API response rate when analyzed for almost half an hour , with export tool current requirement i.e. 4 users Returned in acceptable average response of 19 sec

Report is attached here 4users.pdf

• Second test was done with increasing user number of 6 constantly hitting API all the time

Usually request( Kathmandu area which produces 146 MB of file ) takes ~20 sec when single request is passed , since we are passing same request postgresql cache comes to action even though , it stressed the CPU CPU usage went up to 91 us (us: Time spent in running user space processes. This reflects the CPU consumption by your application.) Request returned with the average of 30 sec which is good also without failing one when passed more than 450 request ( analyzed for more than half an hour ) Report attached Here : 6Users.pdf

From this test what I can conclude is : Request coming from Export tool will be no problem for API , even in hypothetical situation of 6 users constantly hitting API , API will perform fine with reasonable speed for GeoJSON format , Load testing for ogr2ogr will be done separately here

Tested on following spec :

Instance type : Kshitij Underpass Playbox : t3.small ( AWS ) - 2 GiB of Memory, 2 vCPUs RDS Used : Current underpass Development RDS (db.t4g.large - 2vCPU , 8 GB of Memory)

cc : @ramyaragupathy , @eternaltyro

[kshitijrajsharma]

Load test for shapefile export along with GEOJSON : Multiple calls with same request Testing Parameters :

1. Produces 146 MB file ~ expected single request Response time : 20 Sec : GeoJSON - Uses Galaxy self Binding logic

           'geometry': {
       "type": "Polygon",
       "coordinates": [
         [
           [
             85.21270751953125,
             27.646431146293423
           ],
           [
             85.49629211425781,
             27.646431146293423
           ],
           [
             85.49629211425781,
             27.762545086827302
           ],
           [
             85.21270751953125,
             27.762545086827302
           ],
           [
             85.21270751953125,
             27.646431146293423
           ]
         ]
       ]
     }
       }

2. Produces 340 MB of file. expected single request Response time : 45 Sec . Uses ogr2ogr : Shapefile

       "outputType": "shp",
       "geometry":{
             "type": "Polygon",
             "coordinates": [
               [
                 [
                   85.10009765625,
                   27.53993569880378
                 ],
                 [
                   85.65765380859375,
                   27.53993569880378
                 ],
                 [
                   85.65765380859375,
                   27.848790459862073
                 ],
                 [
                   85.10009765625,
                   27.848790459862073
                 ],
                 [
                   85.10009765625,
                   27.53993569880378
                 ]
               ]
             ]
           }
       }

3. 4 Users hitting at same time , 4*2= 8 Request at same time ( That's the optimal uses of export tool that can be called from frontend )

Results : On single request Ideal Response Time : 20 sec + 45 Sec = 65sec

Ran > 100 Request for the testing 100 % Success : API Response while maintaining reasonable response time

Download full report here 100request_shp_geojson.pdf Summary : Passed ! Works well