-
Notifications
You must be signed in to change notification settings - Fork 29
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
stalls when in dev mode. see solution in comments. #110
Comments
It maybe that the SSE is not loading on the client ? simple:76 SSE error: Event {isTrusted: true, type: 'error', target: EventSource, currentTarget: EventSource, eventPhase: 2, …}
EventSource failed loading: GET "http://127.0.0.1:8080/--dev-reload".
<script type="text/javascript">
if (!window.EventSource) {
throw "Server-sent events not supported by this browser, live reloading disabled";
}
var source = new EventSource("/--dev-reload");
source.onmessage = e => {
console.log("message:", e.data);
}
source.addEventListener("reload", () => {
console.log("%c↑↑ Pushup server changed, reloading page ↑↑", "color: green");
location.reload(true);
}, false);
source.addEventListener("open", e => {
console.log("%c↑↑ Connection to Pushup server for dev mode reloading established ↑↑", "color: green");
}, false);
source.onerror = err => {
console.error("SSE error:", err);
};
</script></body></html> WIth the SSE error, the page in dev mode still loads but takes 7 seconds on my mac. |
http://127.0.0.1:8080/--dev-reload is working and in the browser echoing back the keepalive every half second |
I noticed now that on a page change there is a 6 to 7 second delay in the build. [PUSHUP] GET /about 200 208.396µs thats fast, but we have a long delay until that is logged. I think that problem is that the architecture as it stands is a monolithic, and builds it all each time. SO the larger the number of .up pages the slower it gets. I have not tested this assertion, but i suspect this is the problem for slow dev time UX. The solution is WASM and non monolithic. compile each Folder or Page to wasm, and let Runtime page router load the wasm. Then there is practically no limitation to the size of projects Pushup can be used for. Now there is also no Build phase. It's really just a matter of "embedding" the main golang runtime with the many wasm files that live in the folders. Just zipping the root might be enough. SO by using WASM we have solved 2 problems:
|
http://0.0.0.0:8080/dyn/world stalls for about 1 to 10 seconds when in dev mode.
The pattern seems to be that it will process quickly the first 4 times and then stall on the 5th or 6th time. It might vary on others machines.
Those times don't show the stall btw. The stall is happening before the timer starts on each request.
The text was updated successfully, but these errors were encountered: