-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Slim handler #548
Slim handler #548
Conversation
How long would the files stay in cache? |
I haven't done exhaustive testing on that. My assumption is that as long as the function is warm and that is what I saw on my limited testing.
… On Dec 18, 2016, at 9:25 AM, Brian Jinwright ***@***.***> wrote:
How long would the files stay in cache?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
… for verionsed project zip files to be removed from S3 as per zappa_settings., metching current functionality.
@bjinwright I've had keep warm events and been making requests while working on stuff. It has kept the project in /tmp for going on 30 minutes now and hasn't had to re-download from S3. I'll keep checking as it goes on. |
@Miserlou let me know if there is anything else needed for this. |
is the goal about keeping the size small ? or supporting large projects over 250mb ? for keeping the size small which i think is the more universal win, conceptually, this feels PR like the wrong solution and just adds complexity and cold start latency, the right solution imo, would focus on keeping the zappa handler size minimal and getting a better default exclude. the fixed overhead on zappa handler should only be 1mb uncompressed (werkzeug and requestlogger) ~ +310k on the zip |
The lambda max is 50mb, not 250. The goal of this PR was to support larger projects above 50mb.
A project with SciPy alone as a dependency is approaching 35mb.
This only adds to cold start for the initial launch. If you have the keep warm event it responds just as quickly on subsequent requests as the temp folder is cached and shared across lambada calls.
…Sent from my iPhone
On Jan 4, 2017, at 5:45 AM, Kapil Thangavelu ***@***.***> wrote:
is the goal about keeping the size small ? or supporting large projects over 250mb ?
for keeping the size small which i think is the more universal win, conceptually, this feels PR like the wrong solution and just adds complexity and cold start latency, the right solution imo, would focus on keeping the zappa handler size minimal and getting a better default exclude. the fixed overhead on zappa handler should only be 1mb uncompressed (werkzeug and requestlogger) ~ +310k on the zip
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Here are the actual limits because it's both 50 and 250 depending on what your exactly talking about. There should be checks for both limits. I think the ability to get around these limits is another aspect all together as reference in this bug. There should be a check for what's being copied to tmp because of the /tmp space limits
http://docs.aws.amazon.com/lambda/latest/dg/limits.html
|
so my thought is time spent reducing zappa's overhead from 10mb of the 50mb compressed zip max size to under 1mb, will give more headroom for all apps, and cut the bloat from zappa. the work associated to #556 was to enable that, the work already committed shaved about 7mb off the zip. for projects that really want bring in the kitchen sink/large bins though this approach is the only that will really work, though it would be nice to see a unit test. |
That sounds very good to me from that perspective
…On Mon, Jan 9, 2017 at 11:59 AM, Kapil Thangavelu ***@***.***> wrote:
so my thought is time spent reducing zappa's overhead from 10mb of the
50mb compressed zip max size to under 1mb, will give more headroom for all
apps, and cut the bloat from zappa. the work associated to #556
<#556> was to enable that, the
work already committed shaved about 7mb off the zip.
for projects that really want bring in the kitchen sink/large bins though
this approach is the only that will really work, though it would be nice to
see a unit test.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#548 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAHnL5GRrrJdZqSeXslItf_Nkrd5BXG2ks5rQpGbgaJpZM4LQC2_>
.
--
Steve Morin | Hacker, Entrepreneur, Startup Advisor
twitter.com/SteveMorin | stevemorin.com
*Live the dream start a startup. Make the world ... a better place.*
|
Thanks for this! Long term it might be handy to collect packages, measure size, and do this automatically if >50MB. 👍 |
I agree. I think for now it seems like something to opt into for a few reasons:
I looked into adding more tests, but I'm just not sure where. Any suggestions? |
# Conflicts: # README.md # tests/tests.py # zappa/cli.py
Description
Adds an option to zappa_settings.json for "slim_handler" which defaults to false. When set to true does the following:
Known Issues:
The project zip needs to remain in S3 so that the handler can download it as needed. There is not a way to remove old project zip files. They persist in S3.ResolvedGitHub Issues
#510