You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Following the geolocator issues experienced with postal code in OSDP-1816: geoView: Inconsistent results when postal code entered into Map Search, including journeys that hang
In Progress
, I thought to stick with city searches to see what the benchmark times were for those since performance had been an issue (i.e., searches for a postal code or even Ottawa just hanging).
I started with a fresh DEV GREEN Browser tab for each test, as I was beginning to wonder whether there were processes that needed to be woken up on first time that was causing the issue and difference in short vs very long or hung responses. What I just hit was unexpected.
First run to search for Ottawa took 16 seconds to find the result.
Next test for Ottawa was found in under 2 seconds
A re-test of K4A (from OSDP-1816) returned in under 2 seconds
Thinking maybe the above got cached, I tried a totally different Alberta T2W postal code prefix test and it found it in under 2 seconds
The change above happened at ~13:22 today, so what changed that improved the performance, and can this be put in place permanently so that the long searches are eliminated? e.g., is there a process or set of processes that we put to sleep before first use of the day and that otherwise has a long wake cycle until it finally comes up? I’ve been testing in this area of the application for over an hour, and this sudden change is noticeable and one we want to keep.
Update 13:41pm: Ottawa comes back in about 5 seconds now, but it hangs if I search for “Municipality of ottawa”, forcing me to kill the page or refresh it to start another search
Following the geolocator issues experienced with postal code in OSDP-1816: geoView: Inconsistent results when postal code entered into Map Search, including journeys that hang
In Progress
, I thought to stick with city searches to see what the benchmark times were for those since performance had been an issue (i.e., searches for a postal code or even Ottawa just hanging).
I started with a fresh DEV GREEN Browser tab for each test, as I was beginning to wonder whether there were processes that needed to be woken up on first time that was causing the issue and difference in short vs very long or hung responses. What I just hit was unexpected.
First run to search for Ottawa took 16 seconds to find the result.
Next test for Ottawa was found in under 2 seconds
A re-test of K4A (from OSDP-1816) returned in under 2 seconds
Thinking maybe the above got cached, I tried a totally different Alberta T2W postal code prefix test and it found it in under 2 seconds
The change above happened at ~13:22 today, so what changed that improved the performance, and can this be put in place permanently so that the long searches are eliminated? e.g., is there a process or set of processes that we put to sleep before first use of the day and that otherwise has a long wake cycle until it finally comes up? I’ve been testing in this area of the application for over an hour, and this sudden change is noticeable and one we want to keep.
Update 13:41pm: Ottawa comes back in about 5 seconds now, but it hangs if I search for “Municipality of ottawa”, forcing me to kill the page or refresh it to start another search
JIRA: https://fgp-pgf.atlassian.net/jira/software/projects/OSDP/issues/OSDP-1817
The text was updated successfully, but these errors were encountered: