Skip to content

Commit 26c7a90

Browse files
committed
Increase timeouts to new max
1 parent fca9aed commit 26c7a90

File tree

3 files changed

+19
-15
lines changed

3 files changed

+19
-15
lines changed

README.md

Lines changed: 9 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -2,9 +2,13 @@
22

33
# prerendercloud-lambda-edge
44

5-
Server-side rendering (prerendering) via Lambda@Edge for single-page apps hosted on CloudFront with an s3 origin.
5+
Server-side rendering (pre-rendering) via Lambda@Edge for single-page apps hosted on CloudFront with an s3 origin.
66

7-
This is a [serverless](https://github.com/serverless/serverless) project that deploys 2 functions to Lambda, and then associates them with your CloudFront distribution.
7+
This is a [serverless](https://github.com/serverless/serverless) project with a `make deploy` command that:
8+
9+
1. deploys 2 functions to Lambda
10+
2. associates them with your CloudFront distribution
11+
3. clears/invalidates your CloudFront cache
812

913
Read more:
1014

@@ -87,7 +91,7 @@ If you're not editing an IAM policy specifically, the UI/UX checkbox for this in
8791

8892
#### 10. You're done!
8993

90-
Visit a URL associated with your CloudFront distribution. It will take ~3s for the first request. If it times out at 3s, it will just return (and cache) the non-prerendered copy. This is a short-term issue with Lambda@Edge. Work around it, for now, by crawling your SPA with prerender.cloud with a long cache-duration (more detail in caveats section)
94+
Visit a URL associated with your CloudFront distribution. It will take a few seconds for the first request (because it is pre-rendered on the first request). If for some reason the pre-render request fails or times out, the non-pre-rendered request will be cached.
9195

9296
#### Viewing AWS Logs in CloudWatch
9397

@@ -116,10 +120,8 @@ You can also sign into AWS and go to CloudFormation and manually remove things.
116120

117121
## Caveats
118122

119-
1. This solution probably won't work unless you cache your URLs into prerender.cloud's cache first
120-
* This is because Lambda@Edge has a 3s timeout which is not enough time for the prerendering to complete
121-
* The best practice then, is: crawling before invalidating the CloudFront distrubtion - just hit all of the URLs with [service.prerender.cloud](https://www.prerender.cloud/docs/api) and configure a prerender-cache-duration of something very long - like 1 week.
122-
* alternatively you can set the CloudFront TTLs to 0s, so CloudFront will request from prerender.cloud servers on every request - so the first call would probably timeout, but the 2nd will not timeout and will come from prerender.cloud cache. This defeats the purpose of using CloudFront though, since you'll be hitting the "origin" (service.prerender.cloud) on every request.
123+
1. If you can't tolerate a slow first request (where subsequent requests are served from cache in CloudFront):
124+
* crawl before invalidating the CloudFront distrubtion - just hit all of the URLs with [service.prerender.cloud](https://www.prerender.cloud/docs/api) and configure a `prerender-cache-duration` of something longer than the default of 5 minutes (300) - like 1 week (604800).
123125
2. This solution will serve index.html in place of something like `/some-special-file.html` even if `/some-special-file.html` exists on your origin
124126
* We're waiting for the Lambda@Edge to add a feature to address this
125127
3. Redirects (301/302 status codes)

handler.js

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,6 @@
11
// http://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html
22
// http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-at-the-edge.html
3+
// http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-limits.html#limits-lambda-at-edge
34

45
"use strict";
56
const ViewerRequestInterface = require("./lib/ViewerRequestInterface");
@@ -9,12 +10,11 @@ const prerendercloud = require("prerendercloud");
910
const resetPrerenderCloud = () => {
1011
prerendercloud.resetOptions();
1112

12-
// if it takes longer than 2.5s, just bail out so we don't return an error
13-
// since Lambda@Edge max duration is 3s (and there seems to be ~300ms of overhead, sometimes more)
14-
prerendercloud.set("timeout", 2500);
15-
16-
// don't bother with retries since we only have 2.5s
17-
prerendercloud.set("retries", 0);
13+
// default prerender.cloud timeout is 10s
14+
// - so if it takes longer than 11s, either prerender.cloud is down or backed up
15+
// max Lambda@Edge timeout is 30s
16+
prerendercloud.set("retries", 1);
17+
prerendercloud.set("timeout", 11000);
1818

1919
// * CONFIGURATION *
2020

serverless.yml

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,6 @@
11

2+
# see limits on Lambda@Edge http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-limits.html#limits-lambda-at-edge
3+
24
service: Lambda-Edge-Prerendercloud
35

46
# You can pin your service to only deploy with a specific Serverless version
@@ -31,10 +33,10 @@ provider:
3133
functions:
3234
viewerRequest:
3335
handler: handler.viewerRequest
34-
timeout: 1
36+
timeout: 5
3537
originRequest:
3638
handler: handler.originRequest
37-
timeout: 3
39+
timeout: 30
3840

3941
# I created a Lambda@Edge function via the wizard in Lambda Console
4042
# and then copied the role and pasted it here

0 commit comments

Comments
 (0)