Skip to content
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

Add Cache-Control headers on AP endpoints #180

Merged
merged 1 commit into from
Jan 31, 2020
Merged

Add Cache-Control headers on AP endpoints #180

merged 1 commit into from
Jan 31, 2020

Conversation

thebaer
Copy link
Member

@thebaer thebaer commented Sep 9, 2019

This enables future use of Varnish in front of WriteFreely (see T693 for details).

Includes:

  • ActivityPub Collection fetching via canonical URL
  • ActivityPub Collection fetching via API
  • ActivityPub Post fetching via canonical URL
  • ActivityPub Post fetching via API

(By "ActivityPub fetching" I mean requests with the header Accept: application/activity+json)

This closes T693.

Includes:

* AP Collection fetching via canonical URL
* AP Collection fetching via API
* AP Post fetching via canonical URL
* AP Post fetching via API

Ref T693
@thebaer thebaer added this to the 0.11 milestone Sep 9, 2019
@thebaer thebaer requested a review from a user September 9, 2019 20:10
@ghost
Copy link

ghost commented Sep 10, 2019

I'm not sure if you did any benchmarks but I did 😁 on the collection endpoint domain.com/collection

Without Varnish:

Transactions:		        1020 hits
Availability:		      100.00 %
Elapsed time:		        2.14 secs
Data transferred:	        0.71 MB
Response time:		        0.47 secs
Transaction rate:	      476.64 trans/sec
Throughput:		        0.33 MB/sec
Concurrency:		      222.43
Successful transactions:        1020
Failed transactions:	           0
Longest transaction:	        0.98
Shortest transaction:	        0.16

With Varnish:

Transactions:		        1533 hits
Availability:		      100.00 %
Elapsed time:		        3.36 secs
Data transferred:	        0.75 MB
Response time:		        0.41 secs
Transaction rate:	      456.25 trans/sec
Throughput:		        0.22 MB/sec
Concurrency:		      188.11
Successful transactions:        1533
Failed transactions:	           0
Longest transaction:	        0.71
Shortest transaction:	        0.15

And with Varnish in the middle but before the pages are cached the transaction times were:

Longest transaction:	        0.88
Shortest transaction:	        0.33

That's just with two iterations of 255 concurrent users.

Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Everything looks good and the cache control header is working as expected on the specified end points.

I also tested response times again using wrk, matt is still just Nginx and rob is with Varnish:

~/c/wrk (master|✔) $ ./wrk -t8 -c1000 -H "Accept: application/activity+json" https://matt.writefreely.dev
Running 10s test @ https://matt.writefreely.dev
  8 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   475.32ms  187.24ms   1.98s    81.42%
    Req/Sec   109.66     50.04   272.00     68.52%
  7587 requests in 10.08s, 10.51MB read
  Socket errors: connect 208, read 3752, write 0, timeout 21
Requests/sec:    752.60
Transfer/sec:      1.04MB
~/c/wrk (master|✔) $ ./wrk -t8 -c1000 -H "Accept: application/activity+json" https://rob.writefreely.dev/log
Running 10s test @ https://rob.writefreely.dev/log
  8 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   268.45ms  169.69ms   1.95s    90.81%
    Req/Sec   212.60     92.59   630.00     70.68%
  15536 requests in 10.09s, 3.40MB read
  Socket errors: connect 159, read 3170, write 0, timeout 66
Requests/sec:   1539.76
Transfer/sec:    345.50KB

This one supports more concurrent connections, set at 1000 here.

@thebaer
Copy link
Member Author

thebaer commented Sep 11, 2019

Nice! Thanks for the thorough testing / benchmarking -- I hadn't done that 😄. And to be sure, this only introduces caching on ActivityPub endpoints where we're doing GET requests?

@ghost
Copy link

ghost commented Sep 11, 2019

Yep, the other requests include the Via: Varnish header but no age or cache control. Try curl -IL rob.writefreely.dev to see a non cached page

@ghost
Copy link

ghost commented Sep 11, 2019

Actually good call @thebaer, it seems to be caching the post fetch endpoint even without the header for activity json.

@thebaer
Copy link
Member Author

thebaer commented Sep 11, 2019

Gotcha. So I think this might be a varnish thing, where we include the Accept header in the hash.

@ghost
Copy link

ghost commented Sep 11, 2019

Got it, I just added a case in the subroutine for receive sub vcl_recv. When the request does not contain the accept header for activity json it passes the request direct to the backend. With the header you process through caching. To see it in action, including the cached version aging with non cache requests between, alternate the following a few times:

curl -IL rob.writefreely.dev/log/hello-hubzilla -H "Accept: application/activity+json"

curl -IL rob.writefreely.dev/log/hello-hubzilla

@thebaer thebaer modified the milestones: 0.11, 0.12 Nov 11, 2019
@thebaer
Copy link
Member Author

thebaer commented Jan 31, 2020

Thanks, let's continue that discussion on writefreely/documentation#7 -- I think there are some other things we might want to tweak. For now, I'll merge this in.

@thebaer thebaer merged commit ff33c59 into develop Jan 31, 2020
@thebaer thebaer deleted the cache-control branch January 31, 2020 11:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

1 participant