Really long load time when UI first loads
Describe the bug We send a few API requests on first load
- websocket connect
- GET models
- GET agents
It takes a good 5-10s for any of these endpoints to respond. And it looks like we're double-requesting the GET requests.
All three should respond pretty quickly if things are working correctly.
Steps to Reproduce
- open the network tab in browser console
- load the UI
- see pending requests
Expected behavior Requests (at least the GETs) load quickly
Actual behavior Sits pending for > 5s
Additional context
Hopefully this isn't just my machine...
- Double-requesting the GET requests is not a bug,
useEffectrun twice in dev mode - Maybe https://github.com/OpenDevin/OpenDevin/pull/454 can fix this if you dose not set
VITE_WS_URLandVITE_API_URL
In development mode only, it requests twice. Removing React.StrictMode prevents the double request. This occurs because in development mode, useEffect is mounted, unmounted, and then mounted again, triggering the API call twice
@rbren If we skip waiting for the controller creation, the initialization process will be faster. What do you suggest?
or We can enhance the UI by including a greeting, but the send button should remain disabled until initialization
My real concern here is how long it takes for the GET requests to succeed. Since they're population UI options, it feels kinda broken (the options in the dropdowns suddenly change ~5s after loading)
What's causing the GETs to hang? Is it waiting for initialization?
The websocket is somehow blocking. If you remove the websocket handler, the GET request is nearly instantaneous.
Do some local test. Provide my personal opinion which slight different from above discussion.
- When launch the project at first time, it will be very quickly, finish in around 2 seconds.
- When refresh the website, it will need 10+s to initialization. And the probelm happend in it will try to kill the previous docker env. This process will cost around 10s, which is the key point result the slow initializaiton.
Add a PR to fix it #557.