rasql takes a really log time to retrieve 1GB of 3D data in 1kB tiles

[George Merticariu]

./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).

[Dimitar Misev]

Retrieve means a query like this?

select c from test3d as c

[Alex Dumitru]

Yep, that query would reproduce the issues. It actually seems to act up if the result is of form [*:*,*:*,0].

[Peter Baumann]

did you try retrieving the tiling layout created?

[Dimitar Misev]

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.

[Alex Dumitru]

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?

[George Merticariu]

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.

[Dimitar Misev]

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

[Alex Dumitru]

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.

[Dimitar Misev]

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?

[Alex Dumitru]

I think the difference is that with rasnet there are two behaviors:

1. 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)
2. 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 actually support large n-d data.

[Dimitar Misev]

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.

[Peter Baumann]

+1

[Dimitar Misev]

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?

[Dimitar Misev]

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.

[Dimitar Misev]

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.