Rutger ter Borg
2016-11-02 16:29:51 UTC
Hey all,
I've been trying to figure out why the initial load of my Wt app takes
relatively long. To test this, I'm running my Wt app through the Network
analyzer of Chrome, which gives a consistent long time-to-first-byte for
the second request of a (re)load. The second request is initiated by the
first page served by Wt, in my case this is the GET
/?wtd=igHEo7N800u7XfIE&request=style&page=1 HTTP/1.1
(it is usually followed by a third request with request=script). The
response to the second request (with request=style) is a one-liner:
@import url("/css/app.css");
but this takes longer than any other part of an (re)load to finish,
sometimes well over 100 ms (identical behaviour for wthttp and fcgi).
I've been looking in Wt's code, but I have only figured out that if the
WebSession does not have an app_ yet, so it somehow postpones the reply
(around line 1537 of WebSession.C).
Would it be possible to decrease this latency? If so, what are the
relevant parts of Wt to look into?
Thanks,
Rutger
I've been trying to figure out why the initial load of my Wt app takes
relatively long. To test this, I'm running my Wt app through the Network
analyzer of Chrome, which gives a consistent long time-to-first-byte for
the second request of a (re)load. The second request is initiated by the
first page served by Wt, in my case this is the GET
/?wtd=igHEo7N800u7XfIE&request=style&page=1 HTTP/1.1
(it is usually followed by a third request with request=script). The
response to the second request (with request=style) is a one-liner:
@import url("/css/app.css");
but this takes longer than any other part of an (re)load to finish,
sometimes well over 100 ms (identical behaviour for wthttp and fcgi).
I've been looking in Wt's code, but I have only figured out that if the
WebSession does not have an app_ yet, so it somehow postpones the reply
(around line 1537 of WebSession.C).
Would it be possible to decrease this latency? If so, what are the
relevant parts of Wt to look into?
Thanks,
Rutger