Closed denismakogon closed 5 years ago
So, here's some things that sanic needs to adopt:
Hi Denis - thanks for your interest in Sanic. We're working through a list of open issues and PRs currently for out next release (19.03) but if you and your team would like to help contribute to refactoring things to make them faster, better, and easier to use we will certainly not turn down the assistance. Feel free to submit PRs that address your concerns. They will generally be debated if they make major changes to the codebase - you can review some of the current PRs under review for an idea of what that looks like but we are pretty good about accepting them in the end.
In general, I would say start up time is not a huge focus for the project. The main goal is the speed of the request/response cycle. Not to say start up time is unimportant, but it is sort of non-consequential for most web service applications.
Of course we welcome the PR for debate.
As far as things like websockets, while it is not a final decision, we are looking into the possibility of removing that dependency in the future.
Well, that’s true. Cold start was never a concern to most of py frameworks.
However, the area of my interest is a serverless applications where the cold start is the biggest problem. So far I wasn’t able to find any proper technology that really takes cold start issue seriously, maybe because nobody ever talked about that.
@denismakogon Look at: https://github.com/Miserlou/Zappa.
Maybe the question to ask is what kind of application do you want to build in serverless? API/Script?
Ive done an API in AWS Lambda before, but state/sessions/etc get tricky.
@c-goosen, I’m not using AWS, we’re building our own platform, so, thanks, but i’m not kind interested in that.
Take a look at https://github.com/fnproject/fn
@denismakogon thanks will take a look, have you seen: https://openwhisk.apache.org/
Hi! As I mentioned before I’m not interested in other FaaS solutions because I personally developing serverless platform: Fn Project.
As part of that I developed Python binding for an HTTP triggers. That’s why I am here. Because I’d like to improve sanic in order to make it work for my needs, for instance I don’t want to deal with hypercorn (despite that I developed pretty simple ASGI HTTP server with that: https://github.com/denismakogon/simple-asgi) because it takes a lot time to initialize. So, sanic still be a best option to use for now.
Why is it closed? Problem is still there.
per the discussion moving to https://community.sanicframework.org/t/cold-start-issue/182
we can come back here for tracking whenever having clear action items
Describe the bug
We’ve (me and my folks) been trying to solve the cold start issue of our pet project (https://github.com/fnproject/fdk-python). At this moment we use aiohttp as the base unix http server. However, when we started to do a solid performance testing, we’ve figured out that aiohttp takes almost 9 seconds to start within 128Mb RAM (this is our criteria: a server must start within 3 seconds, not longer). Then I decided to look around to see what else we can use and then i came across sanic. I was able to reduce the cold start time up to 6.5 seconds, however, this is still x2 of the required cold start time.
I figured out that sanic doesn’t have any importing rules and when i attempt to do things like "from sanic. import "tons of unnecessary imports being executed (for instance, if i don’t use blueprints - i don’t want the import to be loaded; if I don’t use websocket - i don’t want it to affect the cold start, etc.)
Code snippet Take whatever code sample that is available in this repo and package that into a docker container.
Desired behavior Run it with:
I expect to have server start within 3 seconds at maximum.
The problem is that sanic (similar to aiohttp) doesn't really care about imports, ordering as well as executing code in
__init__.py
.What sanic should do
First of all, import things only if they are needed.
For instance:
Similar to aiohttp, I'd like to see sanic to provide very low-level API to create a simple http server, without any sugar around.