tah1 wrote:
Hi Martin,
Thanks so much for the reply. With respect to Part II of the question about performance degradation:
1. I was running the same query (Q1 from TPH-C) so nothing was wrong with it. 2. Single user - came back in a bit over 2 seconds 3. More than 1 user, from either JDBC or ODBC client, appears that the requests (all users running same Q1) were being processed serially. So for example, avg response times for: 1 user - 2.3 secs 3 users - 5.6 secs 5 users - 8.9 secs This it not unexpected. If you start N queries, then N query plans are taken into execution in parallel. Consider it like eating with N people from the same kettle. Standard computerscience analysis will show your this behavior.
I enabled our traces and saw we were just waiting for a response from MonetDB when we had more than 1 user. I looked in the MonetDB manuals to see MonetDB materializes the complete answer before returning to the user.
if I could debug it - not sure how to.
How can I see what MonetDB is doing when it receives conncurrent user requests? You can see what happens in the interpreter using the stethoscope. regards, Martin
Thanks
tah1 wrote:
Hi,
I read in the SQL Reference Manual that "The number of concurrent user threads is a configuration parameter.", but no information on the name or location or how to change it. Nor is there any info on what the default might be. I tried running multiple users and noticed that the performance degradation increased dramatically as the load increased. I looked at the Server and SQL manuals without luck.
Thanks, Tah
------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev
_______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users