-
Notifications
You must be signed in to change notification settings - Fork 4
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
Improve the performance of data-driven onboarding queries #2042
Comments
Ooh, this does sound useful! Great opportunity to use |
My timing of the same query:
|
Here's the full
|
The biggest candidates I can see for refactoring are |
Nice detective work, thanks @samaratrilling! Here's some thoughts:
|
Added an index on bbl on the hpd_complaints table over on the |
To do: add the new stats on here before closing the issue. |
It looks like users have to wait a good 2-3 seconds after typing in their address to get DDO suggestions, which is much slower than say, Who Owns What, where users are shown the results of their query in about 300-500 ms.
I'm not sure how much this affects our day-to-day users, but given that this is the very first step in our funnel, and the fact that speed matters, I suspect it contributes at least a little to drop-offs. I know I've been avoiding using DDO during development because of its lengthy query time, opting instead to just type in URLs manually whenever I want to go to a particular part of the site. In fact, I was so annoyed by its performance while developing DDO that I implemented very basic caching in #781, but that doesn't help with a cold cache, and most users will never see its benefit.
Note that one distinction between the DDO query and the WoW query is that on DDO, geocoding is done on the server-side to support progressive enhancement, whereas in WoW the geocoding is done on the client-side, so it's likely that DDO will never be quite as fast unless we do more than just optimize the DDO SQL query.
That said, it looks like the majority of time is still spent in the SQL query. The following command runs the SQL query on 654 Park Place and prints the amount of time spent on it:
From my end, the first run of this takes almost 3 seconds, and subsequent runs take closer to 2 seconds, presumably because the database has done some sort of caching/optimization on its end.
The text was updated successfully, but these errors were encountered: