-
Notifications
You must be signed in to change notification settings - Fork 8.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
[spacetime] Http/2 support #123748
[spacetime] Http/2 support #123748
Conversation
@@ -7,11 +7,12 @@ | |||
*/ | |||
|
|||
export function pick<T extends object, K extends keyof T>(obj: T, keys: readonly K[]): Pick<T, K> { | |||
return keys.reduce((acc, key) => { | |||
if (obj.hasOwnProperty(key)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in the case of http/2, headers
object is created via Object.create(null)
so it hasn't got hasOwnProperty
method
@@ -67,11 +66,11 @@ export interface ReqOptions { | |||
path: string; | |||
query?: Record<string, any>; | |||
method: 'GET' | 'POST' | 'PUT' | 'DELETE'; | |||
body?: any; | |||
body?: Record<string, any> | string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO: check whether we use string
anywhere
💔 Build FailedFailed CI Steps
Test Failures
Metrics [docs]Public APIs missing comments
Page load bundle
History
To update your PR or re-run it, just comment with: |
@mshustov, I was thinking about this and thought that maybe there is not much benefit in having bfetch layer with HTTP/2, so added a configuration to not use it for search: #122244 so we could test the difference in cloud. I thought that would be a good experiment because I saw TIL that's a lot more complicated |
Closing as stale PR |
Summary
parent issue #7104
This PR attempts to estimate the effort of adding HTTP/2 support to the Kibana web server.
Note that the change won't improve load time on Cloud. Kibana browser app already connects to the Cloud proxy via
http2
. Cloud proxy converseshttp/2
intohttp/1
to communicate with the Kibana server though.Why
HTTP/2 protocol is multiplexed, so the browser will use a single connection for parallelism. Kibana, in the current implementation, reforms about 200 requests to the Kibana server on start. Web browsers limit the number of parallel connections to six per domain. Therefore, the requests are stuck in a queue, and Kibana has sub-optimal UX for a high number of parallel requests to the Kibana server. To work the problem around we use different techniques like long-term caching and request batching. Both have critical problems. Caching might be disabled or periodically cleared on a client. Request batching adds additional overhead. Using HTTP/2 makes these workarounds obsolete.
TODO
superagent
andsupertest
in the integration tests or they need to be updated to the latest versions with http/2 supportPerformance impact
on the loading time
Tested on
e2-standard-4
instance ongcp
ineurope-west2-a
zone via lighthouse, landing on/home
pagemain
branchPR
Known problems
The full list of incompatibilities between http/1 and http/2 in node nodejs/node#29829
Base path proxy
throws on proxying pseudo-headers https://github.com/nodejs/node/blob/master/lib/internal/http2/compat.js#L105-L109connection
header to error responses. I worked it around by disabling unsupported warnings in 03b7e52bfetch
can be refactored to support http/2. Maybe we don't need it at all and can fall back to the simple HTTP call? HTTP/2 doesn't suffer from the limitation of the number of parallel requests to a single domain. [Search] Benchmarkbfetch
impact in cloud with http2 #124538