Subject: [pgAdmin4][RM3941] Dashboard graphs needs optimizations

From: Aditya Toshniwal <[email-masked]>
Date: Fri, 1 Feb 2019 19:03:47 +0530

Hi Hackers,

Attached is the patch to optimise the dashboard. Changes include:
1) One ajax request for the all the charts instead of separate for every
chart. The next request will not hit until the previous is completed.
2) The code will check for intervals which is greatest common divisor of
all the refresh rates. Chart names which will be eligible for refresh will
be sent with the ajax. If none are eligible, no ajax will be fired.
3) In the backend, query is generated in such a way that data for all the
requested chart names will be fetched in one hit to the database.
4) Test cases for charts rest api and javascript added.

-- 
Thanks and Regards,
Aditya Toshniwal
Software Engineer | EnterpriseDB Software Solutions | Pune
"Don't Complain about Heat, Plant a tree"

---

From: Akshay Joshi <[email-masked]>
Date: Mon, 4 Feb 2019 10:45:36 +0530

Hi Khushboo

Can you please review it.

-- 
*Akshay Joshi*

*Sr. Software Architect *

*Phone: +91 20-3058-9517Mobile: +91 976-788-8246*

---

From: Khushboo Vashi <[email-masked]>
Date: Mon, 4 Feb 2019 14:32:35 +0530

Hi Aditya,

I have reviewed the patch and it looks good to me except the logic to wait
until we get the response from the AJAX request.
So, in this case at a time only one request is being sent to the server.

@ Dave/Ashesh, if you think this is okay then we can commit the patch.

Thanks,
Khushboo

---

From: Dave Page <[email-masked]>
Date: Mon, 4 Feb 2019 09:42:02 +0000

I can't get to this right now, but Akshay, can we get it in before the
release?

I don't think the problem Khushboo notes is really a problem. Waiting for a
response before issuing another one seems sensible... as long as there's a
timeout so things don't get stuck if a response gets lost somehow. Maybe
the timeout should be something like 3x the normal interval?

On Mon, Feb 4, 2019 at 9:02 AM Khushboo Vashi <
[email-masked]> wrote:

> On Mon, Feb 4, 2019 at 10:45 AM Akshay Joshi <
> [email-masked]> wrote:
>
>> Hi Khushboo
>>
>>> 3) In the backend, query is generated in such a way that data for all
>>> the requested chart names will be fetched in one hit to the database.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

---

From: Aditya Toshniwal <[email-masked]>
Date: Mon, 4 Feb 2019 15:27:06 +0530

Hi Hackers,

Attached is the updated patch. The poller will wait 3 times the normal
interval before sending new request if the previous request is pending.
After that, it will send the ajax.

Kindly review.

On Mon, Feb 4, 2019 at 3:12 PM Dave Page <[email-masked]> wrote:

> I don't think the problem Khushboo notes is really a problem. Waiting for
> a response before issuing another one seems sensible... as long as there's
> a timeout so things don't get stuck if a response gets lost somehow. Maybe
>> I have reviewed the patch and it looks good to me except the logic to
>> wait until we get the response from the AJAX request.
>>>> 1) One ajax request for the all the charts instead of separate for
>>>> every chart. The next request will not hit until the previous is completed.
>>>> 2) The code will check for intervals which is greatest common divisor
>>>> of all the refresh rates. Chart names which will be eligible for refresh
>>>> will be sent with the ajax. If none are eligible, no ajax will be fired.

---

From: Dave Page <[email-masked]>
Date: Mon, 4 Feb 2019 10:06:36 +0000

Hi

Do we also give up waiting for the original response?

---

From: Aditya Toshniwal <[email-masked]>
Date: Mon, 4 Feb 2019 15:39:52 +0530

Hi Dave,

> Do we also give up waiting for the original response?
No, that will wait until AJAX request timeout. We do not cancel it
explicitly. If response is received, it will be reflected.

>>> I don't think the problem Khushboo notes is really a problem. Waiting
>>> for a response before issuing another one seems sensible... as long as
>>> there's a timeout so things don't get stuck if a response gets lost
>>> somehow. Maybe the timeout should be something like 3x the normal interval?
>>>

---

From: Dave Page <[email-masked]>
Date: Mon, 4 Feb 2019 10:12:07 +0000

> explicitly. If response is received, it will be reflected.

OK, so it won't hang around forever. Thats fine.

---

From: Akshay Joshi <[email-masked]>
Date: Mon, 4 Feb 2019 15:43:01 +0530

Thanks patch applied.

-- 
*Akshay Joshi*

---

From: Aditya Toshniwal <[email-masked]>
Date: Mon, 4 Feb 2019 16:17:06 +0530

Hi Hackers,

Attached is the patch to change the dashboard test cases to fetch server_id
similar to how it is done in other test cases.

Kindly review.

---

From: Aditya Toshniwal <[email-masked]>
Date: Mon, 4 Feb 2019 17:36:31 +0530

Hi Hackers,

Attached is the patch to fix jasmine test cases. Didn't realise the
timezones could create issues :(
Kindly review.

On Mon, Feb 4, 2019 at 4:17 PM Aditya Toshniwal <
[email-masked]> wrote:

> Hi Hackers,
>
> Attached is the patch to change the dashboard test cases to fetch
> server_id similar to how it is done in other test cases.
>
> Kindly review.
>
>>>>>>> 2) The code will check for intervals which is greatest common
>>>>>>> divisor of all the refresh rates. Chart names which will be eligible for
>>>>>>> refresh will be sent with the ajax. If none are eligible, no ajax will be
>>>>>>> fired.
>>>>>>> 3) In the backend, query is generated in such a way that data for
>>>>>>> all the requested chart names will be fetched in one hit to the database.

---

From: Akshay Joshi <[email-masked]>
Date: Mon, 4 Feb 2019 17:45:20 +0530

Thanks patch applied.

On Mon, Feb 4, 2019 at 5:36 PM Aditya Toshniwal <
[email-masked]> wrote:

>> On Mon, Feb 4, 2019 at 3:43 PM Akshay Joshi <

-- 
*Akshay Joshi*