slow response time when using restAPI to get source summary from wattdepot server

raindarr / wattdepot

Automatically exported from code.google.com/p/wattdepot

0 stars 0 forks source link

slow response time when using restAPI to get source summary from wattdepot server #80

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago

What steps will reproduce the problem?

1.use a browser (chrome) to send the following request to get a source's summary
http://server.wattdepot.org:8182/wattdepot/sources/SIM_UH_ILIMA_FLOORS_3-4/summa
ry

What is the expected output? What do you see instead?

some time the server returns with result after a long time, more than 20 
seconds(?), in one  case, while sending other rest requests to the server in 
the same time, the server eventually error out with OutOfMemory Exception, in 
another case, the server does not respond without outofmemory exception.

after the the first result is returned, the subsequent request to the same 
source summary seems has good response.  but geting a new source's summary 
still take a long time.

Original issue reported on code.google.com by yongwen...@gmail.com on 29 Jan 2011 at 2:10

GoogleCodeExporter commented 8 years ago

This probably indicates a problem with either the SQL queries, or the database 
indices. The summary contains the timestamp of the first and last sensordata, 
and the number of sensordata objects. Both of these should be fast queries on a 
properly indexed database.

Original comment by rbre...@gmail.com on 7 Jan 2012 at 1:39

GoogleCodeExporter commented 8 years ago

Original comment by rbre...@gmail.com on 10 Jan 2012 at 8:35

Added labels: Priority-High
Removed labels: Priority-Medium

GoogleCodeExporter commented 8 years ago

Original comment by rbre...@gmail.com on 30 Mar 2012 at 12:33

Added labels: Milestone-AG, Priority-Medium
Removed labels: Priority-High

GoogleCodeExporter commented 8 years ago

Should be taken care of in revision 5f8539db7412. 

In the case of a virtual source, instead of doing three queries for each 
sub-source (one for min tstamp, one for max tstamp, and one for count), we now 
do one query total and let the database determine the min, max, and count for 
all sources we are interested in at once. This should make it faster, but it 
should be tested on a more realistic dataset.

Original comment by AndreaMC...@gmail.com on 2 Apr 2012 at 11:31

Changed state: Fixed