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

we should opportunistically compress responses #58

Open
iliana opened this issue Jun 11, 2024 · 3 comments
Open

we should opportunistically compress responses #58

iliana opened this issue Jun 11, 2024 · 3 comments

Comments

@iliana
Copy link

iliana commented Jun 11, 2024

Check run pages (e.g. https://buildomat.eng.oxide.computer/wg/0/details/01J04QGAYSFEA32EPBNB1NN9FA/rO6E1KLuz95lg5PhVtAw9IPDufYTSB5Uq4cxNubZy3ZUZVrG/01J04QHG82RKM5TEJTW822P8FP) can get quite large; this one is 3.56 MiB, but gzips to 275.51 KiB. Either Buildomat or Nginx could compress the response per the client's accept-encoding header.

@jclulow
Copy link
Collaborator

jclulow commented Jun 12, 2024

Yes that is not a bad idea!

Something else I've been considering is paginating the output somehow, given that sometimes it can be more than ten times even that size.

@iliana
Copy link
Author

iliana commented Jun 12, 2024

Pagination might not immediately work well for me, since I tend to use my browser's find-in-page feature to look for the particular line I need for a given job failure. But there might be other ways of performing that functionality.

@jclulow
Copy link
Collaborator

jclulow commented Jun 12, 2024

That is indeed the main thing that has kept me from doing it haha. I'll look at the compression!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants