Opened 9 years ago
Closed 6 years ago
#1247 closed defect (worksforme)
rasql takes a really log time to retrieve 1GB of 3D data in 1kB tiles
Reported by: | George Merticariu | Owned by: | Dimitar Misev |
---|---|---|---|
Priority: | major | Milestone: | 10.0 |
Component: | rasnet | Version: | development |
Keywords: | Cc: | Peter Baumann, Alex Dumitru | |
Complexity: | Hard |
Description
./rasql -q 'create collection test3d GreySet3' —user rasadmin —passwd rasadmin
./rasql -q 'insert into test3d values marray x in [0:32767, 0:32767, 0:0] values 123c TILING ALIGNED [0:5000, 0:2000, 0:*] TILE SIZE 41943040' —user rasadmin —passwd rasadmin
When retrieved with rasql it takes ~6min on my machine. When retrieved with java, it takes ~23sec.
rasql code needs to be investigated in order to see why it takes so much for retrieving 1GB, 3D data (the problem does not appear on 1GB 2D data).
Attachments (1)
Change History (20)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
Yep, that query would reproduce the issues. It actually seems to act up if the result is of form [*:*,*:*,0].
follow-up: 6 comment:4 by , 9 years ago
I think it's not relevant because it's fast enough with rasj.
I'm not able to test at the moment due to #1249.
You could easily run some checks with gdb: run gdb ./rasql, submit the query, and once the server finishes Ctrl-C to break, most of the time execution will stop wherever time is wasted most.
comment:5 by , 9 years ago
directql works as well as fast we would expect. It seems there might be something in rasodmg that creates the behaviour, George can you try with gdb as Dimitar suggested?
comment:6 by , 9 years ago
You can overcome the build issue really easy: "Change the code in src/compiler/csharp_generator.cc to use the new class name and it will compile at least."(from https://github.com/grpc/grpc/issues/4505)
Replying to dmisev:
I think it's not relevant because it's fast enough with rasj.
I'm not able to test at the moment due to #1249.
You could easily run some checks with gdb: run gdb ./rasql, submit the query, and once the server finishes Ctrl-C to break, most of the time execution will stop wherever time is wasted most.
comment:7 by , 9 years ago
I can't reproduce the issue. With the attachment:reproduce.sh I get this time:
$ ./reproduce.sh selecting 1GB data... real 0m8.645s user 0m1.528s sys 0m0.828s
by , 9 years ago
Attachment: | reproduce.sh added |
---|
comment:8 by , 9 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:9 by , 9 years ago
I saw this issue initially with wcst_import which produces queries like this:
./rasql -q 'create collection test3d GreySet3' --user rasadmin --passwd rasadmin ./rasql -q 'insert into test3d values marray x in [0:0,0:0,0:0] values 123c' --user rasadmin --passwd rasadmin ./rasql -q 'update test3d t set t assign marray x in [0:32767, 0:32767, 0:0] values 123c' --user rasadmin --passwd rasadmin
Maybe you can try like this, sorry, stuck with osgeo for the moment and can't try it myself.
comment:10 by , 9 years ago
Woah the tiles are 1024 bytes when not specifying the tiling.
But this seems like a separate thing, I don't see how this ticket is related if the select is fast from java, unless that was some false observation?
follow-up: 12 comment:11 by , 9 years ago
I think the difference is that with rasnet there are two behaviors:
- Java - requests data from server via executeHttpQuery() which on the server assembles all tiles into one big tile and then streams the result chunk by chunk (currently chunks are 15mb i think). The behavior of executeHttpQuery() was the same in rnp as well, except being streamed (improvement brought by rasnet)
- Rasodmg - requests data via getMddCore (or some similar name) which keeps the tiling from the server and sends tile by tile to the client (rasql). The client then has to compose them into some meaningful structure. If you check the execution times you will see most of the time is spent by rasql (assembling tiles) and not by rasserver.
That's why Java is faster than cpp in this case. For the moment we need to change this default tile size from 1k to a minimum of 4 mb in order to better support large n-d data that is not tiled properly by the user.
follow-up: 14 comment:12 by , 9 years ago
Replying to mdumitru:
For the moment we need to change this default tile size from 1k to a minimum of 4 mb in order to better support large n-d data that is not tiled properly by the user.
Yes I opened #1252 for this, I think it's an easy fix that I could get in today. I didn't even run your update version btw, just the original insert without a specific tiling clause.
comment:14 by , 9 years ago
Ok I submitted the patch for #1252, not sure what should we do for this ticket though.
Whether the tiles are assembled on server side as for java, or on client side, as for rasql, I'd expect it to take similar time. I'm guessing that the time to transport the small tiles over the network is much larger than the time it takes to assemble the tiles, and this is where rasql is wasting the time.
Maybe we should merge these two methods to a common efficient method?
comment:15 by , 9 years ago
Priority: | blocker → major |
---|
comment:16 by , 9 years ago
Component: | undecided → rasnet |
---|---|
Milestone: | 9.2 → 10.0 |
To summarize, we should aim to streamline the behavior of network transport of data for C++ and Java. As this ticket has shown, it's better to merge tiles on server-side and transfer them in regular chunks, than to just transfer them in whatever tiling they happen to be, which is detrimental when the tiling results in a lot of small tiles.
comment:17 by , 8 years ago
Owner: | changed from | to
---|
comment:18 by , 7 years ago
Summary: | rasql takes a really log time to retrieve 1GB of 3D data → rasql takes a really log time to retrieve 1GB of 3D data in 1kB tiles |
---|
comment:19 by , 6 years ago
Resolution: | → worksforme |
---|---|
Status: | assigned → closed |
The approach of merging tiles on the server side (as HttpServer does, is not particularly good in my opinion as it breaks tile streaming.
Exporting raw arrays is rarely done, mainly in custom clients like rview, and 1kB tiles are even rarer (it only happened here due to a bug in the default tiling).
So I'd close this ticket with no further action on this.
Retrieve means a query like this?