Async support

[yuriescl]

Does Polaris support async requests?
If not, what are the implications on the Django performance? Will the app be limited to the number of workers (in case of gunicorn, for example)?
This came into mind when I was thinking about doing an async Django deployment, but it wouldn't make sense if Polaris doesn't support it.

[JakeUrban]

Polaris' views are synchronous, although you could still run your server using the ASGI (vs. WSGI) standard, although Django does mention some performance considerations.

I don't think this would help make the API server more performant though since Polaris' views don't await anything and therefore wouldn't yield control of the event loop to allow other request tasks to run concurrently.

This relates to my other comments about keeping existing integrations synchronous. Its definitely tempting to change Polaris to be fully asynchronous but I think it increases the complexity and would break existing implementations.

Another option is that Polaris could support both. Its views could be made asynchronous and each integration function would have a synchronous and asynchronous variant, so the developer would chose which one to implement and Polaris would detect and call the implemented one. I'm not against this approach but I don't love it either. Curious on your thoughts.

[yuriescl]

Its definitely tempting to change Polaris to be fully asynchronous but I think it increases the complexity and would break existing implementations.

I agree, it's not worth changing Polaris to be fully asynchronous

My concern is how many requests the Anchor could handle per second. I'm using gunicorn with 3 workers, this means it can only handle 3 simultaneous requests, right?
I guess if I wanna be able to handle more, I'd have to use more CPU cores and increase the amount of workers. Or maybe increase the amount of threads per worker?
Async seems more cheap in this sense, one process, one thread and many async calls running, which are mostly IO-bound to database.
Polaris is probably fine in this sense, just wanted to know your thoughs about performance.

[JakeUrban]

I think you're correct, 3 synchronous workers means 3 simultaneous requests. Based on the Gunicorn docs it doesn't sound like you can use threads with synchronous workers.

Right now the main scaling bottleneck is deposit transaction submission, since the sequence numbers on distribution accounts have to be consumed serially and Polaris doesn't try to queue multiple deposits per ledger. But this concern doesn't have to do with the API server's ability to respond to requests.

The main scaling bottleneck for the API server is the IO to the database and Stellar Network, so if a Polaris anchor has concerns about the cost of the hardware needed to handle their traffic load, making Polaris fully asynchronous is probably the best way forward.

[yuriescl]

Yes, I do get concerned when I imagine a scenario of 100 users trying to create a transaction (which can easily happen if the token is popular). The Anchor will need too many CPUs to handle the requests, but it would be so much cheaper to have like 1 CPU and everything async, since 1 CPU can easily handle 100 async requests.
The python stellar sdk has support for both sync and async, maybe there could be a similar feature for Polaris, a sync and async version of each integration function or API call.
This way Polaris would take full advantage of the SDK async capabilities while lowering costs for Anchors.
I'm curious of what other Anchors think of this. Maybe the Anchors that use Polaris didn't face scaling issues yet.

[JakeUrban]

Async support in Polaris' views is definitely on the table, I think its just of matter of determining the priority and making sure its implemented when needed. We're working on a few other important adjustments at the moment but I think about this more and revisit it soon.