what's different between standalone mode and stardard mode(start by bin\startup.bat)?

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: 回复:open test server,please give some advices!

Adam Retter
Hi Xiaodong and Joe,

I think you have to test this outside of eXide, perhaps just use Curl
to request the queries.

On 17 April 2017 at 15:38, Joe Wicentowski <[hidden email]> wrote:

> Hi Xiaodong,
>
> I can confirm your results when running your two queries in eXide:
>
> 1. The first, non-index-based ("slow") query takes ~25s
> 2. The second, index-backed ("fast") query returns in ~.004s
> 3. Starting the "fast" query after having submitted the "slow" query
> (in eXide) causes the results of the "fast" to be delayed until after
> the "slow" one is completed.
>
> Also, I saved your two queries as /db/test1.xq (slow) and /db/test2.xq
> (fast), and noticed *different* results:
>
> 4. Running the two queries outside of eXide, by directly requesting
> http://118.122.165.33:8091/exist/rest/db/test1.xq and
> http://118.122.165.33:8091/exist/rest/db/test2.xq - allowed test2.xq
> to complete quickly and without delay, while test1.xq took the same
> ~25s to complete.  Running a 3rd query involving no database hits or ,
> just "1" (to return the same input)
>
> Attached are two screenshots showing how these requests appear to
> queue in eXide (under Chrome 57.0.2987.133).
>
> This suggests that some of the "queueing" you're seeing has something
> to do with eXide's ajax execution, and that eXist is capable of
> performing the two queries at the same time.
>
> Joe
>
>
>> declare default element namespace "urn:sc-wst:v1";
>> collection('/db/ehr/v2/510682')//DataSet[HDSN00.01.017/@value="51062310120201001001"]
>>
>> then,this can be index optimized:
>>
>> declare default element namespace "urn:sc-wst:v1";
>> collection('/db/ehr/v2/008500')//DataSet[HDSN00.01.013/@value="a894317f-53da-486f-a1df-cea23200273d"]



--
Adam Retter

eXist Developer
{ United Kingdom }
[hidden email]
irc://irc.freenode.net/existdb

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open
Reply | Threaded
Open this post in threaded view
|

Re: 回复:open test server,please give some advices!

Joe Wicentowski
Hi Adam,

In my #4, I did test outside of eXide - by making requests (in Chrome) for queries stored on the server, not processed by eXide. In that test I was able to request and receive responses for test2.xq 30 times during the ~30 seconds that test1.xq was churning away. So it seems quite clear that the POST requests to eXide's "execute" endpoint get queued somehow, whereas outside of eXide these requests can be processed in parallel. Testing with curl would be a good idea too - removing numerous factors that a browser brings into the picture.

Joe

On Mon, Apr 17, 2017 at 4:42 PM Adam Retter <[hidden email]> wrote:
Hi Xiaodong and Joe,

I think you have to test this outside of eXide, perhaps just use Curl
to request the queries.

On 17 April 2017 at 15:38, Joe Wicentowski <[hidden email]> wrote:
> Hi Xiaodong,
>
> I can confirm your results when running your two queries in eXide:
>
> 1. The first, non-index-based ("slow") query takes ~25s
> 2. The second, index-backed ("fast") query returns in ~.004s
> 3. Starting the "fast" query after having submitted the "slow" query
> (in eXide) causes the results of the "fast" to be delayed until after
> the "slow" one is completed.
>
> Also, I saved your two queries as /db/test1.xq (slow) and /db/test2.xq
> (fast), and noticed *different* results:
>
> 4. Running the two queries outside of eXide, by directly requesting
> http://118.122.165.33:8091/exist/rest/db/test1.xq and
> http://118.122.165.33:8091/exist/rest/db/test2.xq - allowed test2.xq
> to complete quickly and without delay, while test1.xq took the same
> ~25s to complete.  Running a 3rd query involving no database hits or ,
> just "1" (to return the same input)
>
> Attached are two screenshots showing how these requests appear to
> queue in eXide (under Chrome 57.0.2987.133).
>
> This suggests that some of the "queueing" you're seeing has something
> to do with eXide's ajax execution, and that eXist is capable of
> performing the two queries at the same time.
>
> Joe
>
>
>> declare default element namespace "urn:sc-wst:v1";
>> collection('/db/ehr/v2/510682')//DataSet[HDSN00.01.017/@value="51062310120201001001"]
>>
>> then,this can be index optimized:
>>
>> declare default element namespace "urn:sc-wst:v1";
>> collection('/db/ehr/v2/008500')//DataSet[HDSN00.01.013/@value="a894317f-53da-486f-a1df-cea23200273d"]



--
Adam Retter

eXist Developer
{ United Kingdom }
[hidden email]
irc://irc.freenode.net/existdb
--
Sent from my iPhone

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open
Reply | Threaded
Open this post in threaded view
|

Re: 回复:open test server,please give some advices!

Adam Retter
Joe,

Okay thanks Joe, so are we happy that this is an issue with eXide? If
so could you and Xiaodong work together to open an issue on the eXide
issue tracker for Wolfgang on GitHub please?

On 17 April 2017 at 17:22, Joe Wicentowski <[hidden email]> wrote:

> Hi Adam,
>
> In my #4, I did test outside of eXide - by making requests (in Chrome) for
> queries stored on the server, not processed by eXide. In that test I was
> able to request and receive responses for test2.xq 30 times during the ~30
> seconds that test1.xq was churning away. So it seems quite clear that the
> POST requests to eXide's "execute" endpoint get queued somehow, whereas
> outside of eXide these requests can be processed in parallel. Testing with
> curl would be a good idea too - removing numerous factors that a browser
> brings into the picture.
>
> Joe
>
> On Mon, Apr 17, 2017 at 4:42 PM Adam Retter <[hidden email]> wrote:
>>
>> Hi Xiaodong and Joe,
>>
>> I think you have to test this outside of eXide, perhaps just use Curl
>> to request the queries.
>>
>> On 17 April 2017 at 15:38, Joe Wicentowski <[hidden email]> wrote:
>> > Hi Xiaodong,
>> >
>> > I can confirm your results when running your two queries in eXide:
>> >
>> > 1. The first, non-index-based ("slow") query takes ~25s
>> > 2. The second, index-backed ("fast") query returns in ~.004s
>> > 3. Starting the "fast" query after having submitted the "slow" query
>> > (in eXide) causes the results of the "fast" to be delayed until after
>> > the "slow" one is completed.
>> >
>> > Also, I saved your two queries as /db/test1.xq (slow) and /db/test2.xq
>> > (fast), and noticed *different* results:
>> >
>> > 4. Running the two queries outside of eXide, by directly requesting
>> > http://118.122.165.33:8091/exist/rest/db/test1.xq and
>> > http://118.122.165.33:8091/exist/rest/db/test2.xq - allowed test2.xq
>> > to complete quickly and without delay, while test1.xq took the same
>> > ~25s to complete.  Running a 3rd query involving no database hits or ,
>> > just "1" (to return the same input)
>> >
>> > Attached are two screenshots showing how these requests appear to
>> > queue in eXide (under Chrome 57.0.2987.133).
>> >
>> > This suggests that some of the "queueing" you're seeing has something
>> > to do with eXide's ajax execution, and that eXist is capable of
>> > performing the two queries at the same time.
>> >
>> > Joe
>> >
>> >
>> >> declare default element namespace "urn:sc-wst:v1";
>> >>
>> >> collection('/db/ehr/v2/510682')//DataSet[HDSN00.01.017/@value="51062310120201001001"]
>> >>
>> >> then,this can be index optimized:
>> >>
>> >> declare default element namespace "urn:sc-wst:v1";
>> >>
>> >> collection('/db/ehr/v2/008500')//DataSet[HDSN00.01.013/@value="a894317f-53da-486f-a1df-cea23200273d"]
>>
>>
>>
>> --
>> Adam Retter
>>
>> eXist Developer
>> { United Kingdom }
>> [hidden email]
>> irc://irc.freenode.net/existdb
>
> --
> Sent from my iPhone



--
Adam Retter

eXist Developer
{ United Kingdom }
[hidden email]
irc://irc.freenode.net/existdb

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open
Reply | Threaded
Open this post in threaded view
|

Re: 回复:open test server,please give some advices!

Joe Wicentowski
Hi Adam and Xiaodong,

I added console logging to test1.xq and test2.xq, so we have a
timestamp when each script starts and ends.  On my end, I'm requesting
both scripts at the same start time.  The difference between curl and
eXide is when test 2 starts.  In curl, test2 starts immediately.  In
eXide, test2 starts just before test1 ends.

eXide
10:01:28.415 starting test1
10:01:54.211 starting test2
10:01:54.212 finished test2
10:01:58.197 finished test1

curl
10:04:14.907 starting test1
10:04:16.744 starting test2
10:04:16.745 finished test2
10:04:44.341 finished test1

I think there's something index-specific about this slowdown.  To show
that this isn't just a case of eXide not being able to process any
queries in parallel, try executing these two queries in quick
succession in eXide:

```
util:wait(10000),
"done"
```

```
1
```

The 2nd query returns "1" immediately, and doesn't wait the 10 seconds
until the 1st is done.  This is quite puzzling!

I'm happy to file an issue, unless you'd like to, Xiaodong?

Joe

On Mon, Apr 17, 2017 at 5:40 PM, Adam Retter <[hidden email]> wrote:

> Joe,
>
> Okay thanks Joe, so are we happy that this is an issue with eXide? If
> so could you and Xiaodong work together to open an issue on the eXide
> issue tracker for Wolfgang on GitHub please?
>
> On 17 April 2017 at 17:22, Joe Wicentowski <[hidden email]> wrote:
>> Hi Adam,
>>
>> In my #4, I did test outside of eXide - by making requests (in Chrome) for
>> queries stored on the server, not processed by eXide. In that test I was
>> able to request and receive responses for test2.xq 30 times during the ~30
>> seconds that test1.xq was churning away. So it seems quite clear that the
>> POST requests to eXide's "execute" endpoint get queued somehow, whereas
>> outside of eXide these requests can be processed in parallel. Testing with
>> curl would be a good idea too - removing numerous factors that a browser
>> brings into the picture.
>>
>> Joe
>>
>> On Mon, Apr 17, 2017 at 4:42 PM Adam Retter <[hidden email]> wrote:
>>>
>>> Hi Xiaodong and Joe,
>>>
>>> I think you have to test this outside of eXide, perhaps just use Curl
>>> to request the queries.
>>>
>>> On 17 April 2017 at 15:38, Joe Wicentowski <[hidden email]> wrote:
>>> > Hi Xiaodong,
>>> >
>>> > I can confirm your results when running your two queries in eXide:
>>> >
>>> > 1. The first, non-index-based ("slow") query takes ~25s
>>> > 2. The second, index-backed ("fast") query returns in ~.004s
>>> > 3. Starting the "fast" query after having submitted the "slow" query
>>> > (in eXide) causes the results of the "fast" to be delayed until after
>>> > the "slow" one is completed.
>>> >
>>> > Also, I saved your two queries as /db/test1.xq (slow) and /db/test2.xq
>>> > (fast), and noticed *different* results:
>>> >
>>> > 4. Running the two queries outside of eXide, by directly requesting
>>> > http://118.122.165.33:8091/exist/rest/db/test1.xq and
>>> > http://118.122.165.33:8091/exist/rest/db/test2.xq - allowed test2.xq
>>> > to complete quickly and without delay, while test1.xq took the same
>>> > ~25s to complete.  Running a 3rd query involving no database hits or ,
>>> > just "1" (to return the same input)
>>> >
>>> > Attached are two screenshots showing how these requests appear to
>>> > queue in eXide (under Chrome 57.0.2987.133).
>>> >
>>> > This suggests that some of the "queueing" you're seeing has something
>>> > to do with eXide's ajax execution, and that eXist is capable of
>>> > performing the two queries at the same time.
>>> >
>>> > Joe
>>> >
>>> >
>>> >> declare default element namespace "urn:sc-wst:v1";
>>> >>
>>> >> collection('/db/ehr/v2/510682')//DataSet[HDSN00.01.017/@value="51062310120201001001"]
>>> >>
>>> >> then,this can be index optimized:
>>> >>
>>> >> declare default element namespace "urn:sc-wst:v1";
>>> >>
>>> >> collection('/db/ehr/v2/008500')//DataSet[HDSN00.01.013/@value="a894317f-53da-486f-a1df-cea23200273d"]
>>>
>>>
>>>
>>> --
>>> Adam Retter
>>>
>>> eXist Developer
>>> { United Kingdom }
>>> [hidden email]
>>> irc://irc.freenode.net/existdb
>>
>> --
>> Sent from my iPhone
>
>
>
> --
> Adam Retter
>
> eXist Developer
> { United Kingdom }
> [hidden email]
> irc://irc.freenode.net/existdb

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open
Reply | Threaded
Open this post in threaded view
|

Re: 回复:open test server,please give some advices!

lin_xd
Thanks, I have tested as you say, and do alst in client.bat gui , it's ok.
---------------------btw,
but cmd:   bin\client.bat -s -ouri=xmldb:exist://118.122.165.33:8091/exist/xmlrpc -uadmin  can't work now:
 
Adding -ouri to JAVA_ARGS
Adding xmldb:exist://118.122.165.33:8091/exist/xmlrpc to JAVA_ARGS
Adding -uadmin to JAVA_ARGS
'-ouri' is missing an assignment operator(=). See usage for -o for proper values.

Usage: Main [Arguments]
.....
can't work now.



--
此致

   林晓东

莫愁前路无知己,天下谁人不识君。


At 2017-04-18 10:21:22, "Joe Wicentowski" <[hidden email]> wrote: >Hi Adam and Xiaodong, > >I added console logging to test1.xq and test2.xq, so we have a >timestamp when each script starts and ends. On my end, I'm requesting >both scripts at the same start time. The difference between curl and >eXide is when test 2 starts. In curl, test2 starts immediately. In >eXide, test2 starts just before test1 ends. > >eXide >10:01:28.415 starting test1 >10:01:54.211 starting test2 >10:01:54.212 finished test2 >10:01:58.197 finished test1 > >curl >10:04:14.907 starting test1 >10:04:16.744 starting test2 >10:04:16.745 finished test2 >10:04:44.341 finished test1 > >I think there's something index-specific about this slowdown. To show >that this isn't just a case of eXide not being able to process any >queries in parallel, try executing these two queries in quick >succession in eXide: > >``` >util:wait(10000), >"done" >``` > >``` >1 >``` > >The 2nd query returns "1" immediately, and doesn't wait the 10 seconds >until the 1st is done. This is quite puzzling! > >I'm happy to file an issue, unless you'd like to, Xiaodong? > >Joe > >On Mon, Apr 17, 2017 at 5:40 PM, Adam Retter <[hidden email]> wrote: >> Joe, >> >> Okay thanks Joe, so are we happy that this is an issue with eXide? If >> so could you and Xiaodong work together to open an issue on the eXide >> issue tracker for Wolfgang on GitHub please? >> >> On 17 April 2017 at 17:22, Joe Wicentowski <[hidden email]> wrote: >>> Hi Adam, >>> >>> In my #4, I did test outside of eXide - by making requests (in Chrome) for >>> queries stored on the server, not processed by eXide. In that test I was >>> able to request and receive responses for test2.xq 30 times during the ~30 >>> seconds that test1.xq was churning away. So it seems quite clear that the >>> POST requests to eXide's "execute" endpoint get queued somehow, whereas >>> outside of eXide these requests can be processed in parallel. Testing with >>> curl would be a good idea too - removing numerous factors that a browser >>> brings into the picture. >>> >>> Joe >>> >>> On Mon, Apr 17, 2017 at 4:42 PM Adam Retter <[hidden email]> wrote: >>>> >>>> Hi Xiaodong and Joe, >>>> >>>> I think you have to test this outside of eXide, perhaps just use Curl >>>> to request the queries. >>>> >>>> On 17 April 2017 at 15:38, Joe Wicentowski <[hidden email]> wrote: >>>> > Hi Xiaodong, >>>> > >>>> > I can confirm your results when running your two queries in eXide: >>>> > >>>> > 1. The first, non-index-based ("slow") query takes ~25s >>>> > 2. The second, index-backed ("fast") query returns in ~.004s >>>> > 3. Starting the "fast" query after having submitted the "slow" query >>>> > (in eXide) causes the results of the "fast" to be delayed until after >>>> > the "slow" one is completed. >>>> > >>>> > Also, I saved your two queries as /db/test1.xq (slow) and /db/test2.xq >>>> > (fast), and noticed *different* results: >>>> > >>>> > 4. Running the two queries outside of eXide, by directly requesting >>>> > http://118.122.165.33:8091/exist/rest/db/test1.xq and >>>> > http://118.122.165.33:8091/exist/rest/db/test2.xq - allowed test2.xq >>>> > to complete quickly and without delay, while test1.xq took the same >>>> > ~25s to complete. Running a 3rd query involving no database hits or , >>>> > just "1" (to return the same input) >>>> > >>>> > Attached are two screenshots showing how these requests appear to >>>> > queue in eXide (under Chrome 57.0.2987.133). >>>> > >>>> > This suggests that some of the "queueing" you're seeing has something >>>> > to do with eXide's ajax execution, and that eXist is capable of >>>> > performing the two queries at the same time. >>>> > >>>> > Joe >>>> > >>>> > >>>> >> declare default element namespace "urn:sc-wst:v1"; >>>> >> >>>> >> collection('/db/ehr/v2/510682')//DataSet[HDSN00.01.017/@value="51062310120201001001"] >>>> >> >>>> >> then,this can be index optimized: >>>> >> >>>> >> declare default element namespace "urn:sc-wst:v1"; >>>> >> >>>> >> collection('/db/ehr/v2/008500')//DataSet[HDSN00.01.013/@value="a894317f-53da-486f-a1df-cea23200273d"] >>>> >>>> >>>> >>>> -- >>>> Adam Retter >>>> >>>> eXist Developer >>>> { United Kingdom } >>>> [hidden email] >>>> irc://irc.freenode.net/existdb >>> >>> -- >>> Sent from my iPhone >> >> >> >> -- >> Adam Retter >> >> eXist Developer >> { United Kingdom } >> [hidden email] >> irc://irc.freenode.net/existdb


 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open
Reply | Threaded
Open this post in threaded view
|

Re: 回复:open test server,please give some advices!

lin_xd
In reply to this post by Joe Wicentowski
Thanks, 
I have tested as you say, and do also in gui admin client, it's ok.
---------------------btw,
but cmd:   bin\client.bat -s -ouri=xmldb:exist://118.122.165.33:8091/exist/xmlrpc -uadmin  can't work now:
 
Adding -ouri to JAVA_ARGS
Adding xmldb:exist://118.122.165.33:8091/exist/xmlrpc to JAVA_ARGS
Adding -uadmin to JAVA_ARGS
'-ouri' is missing an assignment operator(=). See usage for -o for proper values.

Usage: Main [Arguments]
.....




--
此致

   林晓东

莫愁前路无知己,天下谁人不识君。


At 2017-04-18 10:21:22, "Joe Wicentowski" <[hidden email]> wrote: >Hi Adam and Xiaodong, > >I added console logging to test1.xq and test2.xq, so we have a >timestamp when each script starts and ends. On my end, I'm requesting >both scripts at the same start time. The difference between curl and >eXide is when test 2 starts. In curl, test2 starts immediately. In >eXide, test2 starts just before test1 ends. > >eXide >10:01:28.415 starting test1 >10:01:54.211 starting test2 >10:01:54.212 finished test2 >10:01:58.197 finished test1 > >curl >10:04:14.907 starting test1 >10:04:16.744 starting test2 >10:04:16.745 finished test2 >10:04:44.341 finished test1 > >I think there's something index-specific about this slowdown. To show >that this isn't just a case of eXide not being able to process any >queries in parallel, try executing these two queries in quick >succession in eXide: > >``` >util:wait(10000), >"done" >``` > >``` >1 >``` > >The 2nd query returns "1" immediately, and doesn't wait the 10 seconds >until the 1st is done. This is quite puzzling! > >I'm happy to file an issue, unless you'd like to, Xiaodong? > >Joe > >On Mon, Apr 17, 2017 at 5:40 PM, Adam Retter <[hidden email]> wrote: >> Joe, >> >> Okay thanks Joe, so are we happy that this is an issue with eXide? If >> so could you and Xiaodong work together to open an issue on the eXide >> issue tracker for Wolfgang on GitHub please? >> >> On 17 April 2017 at 17:22, Joe Wicentowski <[hidden email]> wrote: >>> Hi Adam, >>> >>> In my #4, I did test outside of eXide - by making requests (in Chrome) for >>> queries stored on the server, not processed by eXide. In that test I was >>> able to request and receive responses for test2.xq 30 times during the ~30 >>> seconds that test1.xq was churning away. So it seems quite clear that the >>> POST requests to eXide's "execute" endpoint get queued somehow, whereas >>> outside of eXide these requests can be processed in parallel. Testing with >>> curl would be a good idea too - removing numerous factors that a browser >>> brings into the picture. >>> >>> Joe >>> >>> On Mon, Apr 17, 2017 at 4:42 PM Adam Retter <[hidden email]> wrote: >>>> >>>> Hi Xiaodong and Joe, >>>> >>>> I think you have to test this outside of eXide, perhaps just use Curl >>>> to request the queries. >>>> >>>> On 17 April 2017 at 15:38, Joe Wicentowski <[hidden email]> wrote: >>>> > Hi Xiaodong, >>>> > >>>> > I can confirm your results when running your two queries in eXide: >>>> > >>>> > 1. The first, non-index-based ("slow") query takes ~25s >>>> > 2. The second, index-backed ("fast") query returns in ~.004s >>>> > 3. Starting the "fast" query after having submitted the "slow" query >>>> > (in eXide) causes the results of the "fast" to be delayed until after >>>> > the "slow" one is completed. >>>> > >>>> > Also, I saved your two queries as /db/test1.xq (slow) and /db/test2.xq >>>> > (fast), and noticed *different* results: >>>> > >>>> > 4. Running the two queries outside of eXide, by directly requesting >>>> > http://118.122.165.33:8091/exist/rest/db/test1.xq and >>>> > http://118.122.165.33:8091/exist/rest/db/test2.xq - allowed test2.xq >>>> > to complete quickly and without delay, while test1.xq took the same >>>> > ~25s to complete. Running a 3rd query involving no database hits or , >>>> > just "1" (to return the same input) >>>> > >>>> > Attached are two screenshots showing how these requests appear to >>>> > queue in eXide (under Chrome 57.0.2987.133). >>>> > >>>> > This suggests that some of the "queueing" you're seeing has something >>>> > to do with eXide's ajax execution, and that eXist is capable of >>>> > performing the two queries at the same time. >>>> > >>>> > Joe >>>> > >>>> > >>>> >> declare default element namespace "urn:sc-wst:v1"; >>>> >> >>>> >> collection('/db/ehr/v2/510682')//DataSet[HDSN00.01.017/@value="51062310120201001001"] >>>> >> >>>> >> then,this can be index optimized: >>>> >> >>>> >> declare default element namespace "urn:sc-wst:v1"; >>>> >> >>>> >> collection('/db/ehr/v2/008500')//DataSet[HDSN00.01.013/@value="a894317f-53da-486f-a1df-cea23200273d"] >>>> >>>> >>>> >>>> -- >>>> Adam Retter >>>> >>>> eXist Developer >>>> { United Kingdom } >>>> [hidden email] >>>> irc://irc.freenode.net/existdb >>> >>> -- >>> Sent from my iPhone >> >> >> >> -- >> Adam Retter >> >> eXist Developer >> { United Kingdom } >> [hidden email] >> irc://irc.freenode.net/existdb


 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open
Reply | Threaded
Open this post in threaded view
|

Re: 回复:open test server,please give some advices!

lin_xd
In reply to this post by Joe Wicentowski
and I also suggest: for exide , do more different queries ,its output should in different window.(or tab pane area). 




--
此致

   林晓东

莫愁前路无知己,天下谁人不识君。


At 2017-04-18 10:21:22, "Joe Wicentowski" <[hidden email]> wrote: >Hi Adam and Xiaodong, > >I added console logging to test1.xq and test2.xq, so we have a >timestamp when each script starts and ends. On my end, I'm requesting >both scripts at the same start time. The difference between curl and >eXide is when test 2 starts. In curl, test2 starts immediately. In >eXide, test2 starts just before test1 ends. > >eXide >10:01:28.415 starting test1 >10:01:54.211 starting test2 >10:01:54.212 finished test2 >10:01:58.197 finished test1 > >curl >10:04:14.907 starting test1 >10:04:16.744 starting test2 >10:04:16.745 finished test2 >10:04:44.341 finished test1 > >I think there's something index-specific about this slowdown. To show >that this isn't just a case of eXide not being able to process any >queries in parallel, try executing these two queries in quick >succession in eXide: > >``` >util:wait(10000), >"done" >``` > >``` >1 >``` > >The 2nd query returns "1" immediately, and doesn't wait the 10 seconds >until the 1st is done. This is quite puzzling! > >I'm happy to file an issue, unless you'd like to, Xiaodong? > >Joe > >On Mon, Apr 17, 2017 at 5:40 PM, Adam Retter <[hidden email]> wrote: >> Joe, >> >> Okay thanks Joe, so are we happy that this is an issue with eXide? If >> so could you and Xiaodong work together to open an issue on the eXide >> issue tracker for Wolfgang on GitHub please? >> >> On 17 April 2017 at 17:22, Joe Wicentowski <[hidden email]> wrote: >>> Hi Adam, >>> >>> In my #4, I did test outside of eXide - by making requests (in Chrome) for >>> queries stored on the server, not processed by eXide. In that test I was >>> able to request and receive responses for test2.xq 30 times during the ~30 >>> seconds that test1.xq was churning away. So it seems quite clear that the >>> POST requests to eXide's "execute" endpoint get queued somehow, whereas >>> outside of eXide these requests can be processed in parallel. Testing with >>> curl would be a good idea too - removing numerous factors that a browser >>> brings into the picture. >>> >>> Joe >>> >>> On Mon, Apr 17, 2017 at 4:42 PM Adam Retter <[hidden email]> wrote: >>>> >>>> Hi Xiaodong and Joe, >>>> >>>> I think you have to test this outside of eXide, perhaps just use Curl >>>> to request the queries. >>>> >>>> On 17 April 2017 at 15:38, Joe Wicentowski <[hidden email]> wrote: >>>> > Hi Xiaodong, >>>> > >>>> > I can confirm your results when running your two queries in eXide: >>>> > >>>> > 1. The first, non-index-based ("slow") query takes ~25s >>>> > 2. The second, index-backed ("fast") query returns in ~.004s >>>> > 3. Starting the "fast" query after having submitted the "slow" query >>>> > (in eXide) causes the results of the "fast" to be delayed until after >>>> > the "slow" one is completed. >>>> > >>>> > Also, I saved your two queries as /db/test1.xq (slow) and /db/test2.xq >>>> > (fast), and noticed *different* results: >>>> > >>>> > 4. Running the two queries outside of eXide, by directly requesting >>>> > http://118.122.165.33:8091/exist/rest/db/test1.xq and >>>> > http://118.122.165.33:8091/exist/rest/db/test2.xq - allowed test2.xq >>>> > to complete quickly and without delay, while test1.xq took the same >>>> > ~25s to complete. Running a 3rd query involving no database hits or , >>>> > just "1" (to return the same input) >>>> > >>>> > Attached are two screenshots showing how these requests appear to >>>> > queue in eXide (under Chrome 57.0.2987.133). >>>> > >>>> > This suggests that some of the "queueing" you're seeing has something >>>> > to do with eXide's ajax execution, and that eXist is capable of >>>> > performing the two queries at the same time. >>>> > >>>> > Joe >>>> > >>>> > >>>> >> declare default element namespace "urn:sc-wst:v1"; >>>> >> >>>> >> collection('/db/ehr/v2/510682')//DataSet[HDSN00.01.017/@value="51062310120201001001"] >>>> >> >>>> >> then,this can be index optimized: >>>> >> >>>> >> declare default element namespace "urn:sc-wst:v1"; >>>> >> >>>> >> collection('/db/ehr/v2/008500')//DataSet[HDSN00.01.013/@value="a894317f-53da-486f-a1df-cea23200273d"] >>>> >>>> >>>> >>>> -- >>>> Adam Retter >>>> >>>> eXist Developer >>>> { United Kingdom } >>>> [hidden email] >>>> irc://irc.freenode.net/existdb >>> >>> -- >>> Sent from my iPhone >> >> >> >> -- >> Adam Retter >> >> eXist Developer >> { United Kingdom } >> [hidden email] >> irc://irc.freenode.net/existdb


 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open
Reply | Threaded
Open this post in threaded view
|

Re: 回复:open test server,please give some advices!

Jonathan Rowell
In reply to this post by Joe Wicentowski

Hi,


isn't this due to the fact that eXide uses one socket to connect to the DB and consequently queries will get queued?

Using WireShark ought to confirm this.


Jonathan




From: Joe Wicentowski <[hidden email]>
Sent: Monday, April 17, 2017 9:22 PM
To: Adam Retter
Cc: [hidden email]; Dannes Wessels
Subject: Re: [Exist-open] 回复:open test server,please give some advices!
 
Hi Adam,

In my #4, I did test outside of eXide - by making requests (in Chrome) for queries stored on the server, not processed by eXide. In that test I was able to request and receive responses for test2.xq 30 times during the ~30 seconds that test1.xq was churning away. So it seems quite clear that the POST requests to eXide's "execute" endpoint get queued somehow, whereas outside of eXide these requests can be processed in parallel. Testing with curl would be a good idea too - removing numerous factors that a browser brings into the picture.

Joe

On Mon, Apr 17, 2017 at 4:42 PM Adam Retter <[hidden email]> wrote:
Hi Xiaodong and Joe,

I think you have to test this outside of eXide, perhaps just use Curl
to request the queries.

On 17 April 2017 at 15:38, Joe Wicentowski <[hidden email]> wrote:
> Hi Xiaodong,
>
> I can confirm your results when running your two queries in eXide:
>
> 1. The first, non-index-based ("slow") query takes ~25s
> 2. The second, index-backed ("fast") query returns in ~.004s
> 3. Starting the "fast" query after having submitted the "slow" query
> (in eXide) causes the results of the "fast" to be delayed until after
> the "slow" one is completed.
>
> Also, I saved your two queries as /db/test1.xq (slow) and /db/test2.xq
> (fast), and noticed *different* results:
>
> 4. Running the two queries outside of eXide, by directly requesting
> http://118.122.165.33:8091/exist/rest/db/test1.xq and
> http://118.122.165.33:8091/exist/rest/db/test2.xq - allowed test2.xq
> to complete quickly and without delay, while test1.xq took the same
> ~25s to complete.  Running a 3rd query involving no database hits or ,
> just "1" (to return the same input)
>
> Attached are two screenshots showing how these requests appear to
> queue in eXide (under Chrome 57.0.2987.133).
>
> This suggests that some of the "queueing" you're seeing has something
> to do with eXide's ajax execution, and that eXist is capable of
> performing the two queries at the same time.
>
> Joe
>
>
>> declare default element namespace "urn:sc-wst:v1";
>> collection('/db/ehr/v2/510682')//DataSet[HDSN00.01.017/@value="51062310120201001001"]
>>
>> then,this can be index optimized:
>>
>> declare default element namespace "urn:sc-wst:v1";
>> collection('/db/ehr/v2/008500')//DataSet[HDSN00.01.013/@value="a894317f-53da-486f-a1df-cea23200273d"]



--
Adam Retter

eXist Developer
{ United Kingdom }
[hidden email]
irc://irc.freenode.net/existdb
--
Sent from my iPhone

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open
Reply | Threaded
Open this post in threaded view
|

Re: 回复:open test server,please give some advices!

lin_xd
but the query also cause the monex to stop response, and dashboard too. 




--
此致

   林晓东

莫愁前路无知己,天下谁人不识君。

在 2017-04-18 22:42:38,"Jonathan Rowell" <[hidden email]> 写道:

Hi,


isn't this due to the fact that eXide uses one socket to connect to the DB and consequently queries will get queued?

Using WireShark ought to confirm this.


Jonathan




From: Joe Wicentowski <[hidden email]>
Sent: Monday, April 17, 2017 9:22 PM
To: Adam Retter
Cc: [hidden email]; Dannes Wessels
Subject: Re: [Exist-open] 回复:open test server,please give some advices!
 
Hi Adam,

In my #4, I did test outside of eXide - by making requests (in Chrome) for queries stored on the server, not processed by eXide. In that test I was able to request and receive responses for test2.xq 30 times during the ~30 seconds that test1.xq was churning away. So it seems quite clear that the POST requests to eXide's "execute" endpoint get queued somehow, whereas outside of eXide these requests can be processed in parallel. Testing with curl would be a good idea too - removing numerous factors that a browser brings into the picture.

Joe

On Mon, Apr 17, 2017 at 4:42 PM Adam Retter <[hidden email]> wrote:
Hi Xiaodong and Joe,

I think you have to test this outside of eXide, perhaps just use Curl
to request the queries.

On 17 April 2017 at 15:38, Joe Wicentowski <[hidden email]> wrote:
> Hi Xiaodong,
>
> I can confirm your results when running your two queries in eXide:
>
> 1. The first, non-index-based ("slow") query takes ~25s
> 2. The second, index-backed ("fast") query returns in ~.004s
> 3. Starting the "fast" query after having submitted the "slow" query
> (in eXide) causes the results of the "fast" to be delayed until after
> the "slow" one is completed.
>
> Also, I saved your two queries as /db/test1.xq (slow) and /db/test2.xq
> (fast), and noticed *different* results:
>
> 4. Running the two queries outside of eXide, by directly requesting
> http://118.122.165.33:8091/exist/rest/db/test1.xq and
> http://118.122.165.33:8091/exist/rest/db/test2.xq - allowed test2.xq
> to complete quickly and without delay, while test1.xq took the same
> ~25s to complete.  Running a 3rd query involving no database hits or ,
> just "1" (to return the same input)
>
> Attached are two screenshots showing how these requests appear to
> queue in eXide (under Chrome 57.0.2987.133).
>
> This suggests that some of the "queueing" you're seeing has something
> to do with eXide's ajax execution, and that eXist is capable of
> performing the two queries at the same time.
>
> Joe
>
>
>> declare default element namespace "urn:sc-wst:v1";
>> collection('/db/ehr/v2/510682')//DataSet[HDSN00.01.017/@value="51062310120201001001"]
>>
>> then,this can be index optimized:
>>
>> declare default element namespace "urn:sc-wst:v1";
>> collection('/db/ehr/v2/008500')//DataSet[HDSN00.01.013/@value="a894317f-53da-486f-a1df-cea23200273d"]



--
Adam Retter

eXist Developer
{ United Kingdom }
[hidden email]
irc://irc.freenode.net/existdb
--
Sent from my iPhone


 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open
Reply | Threaded
Open this post in threaded view
|

Re: 回复:open test server,please give some advices!

lin_xd
In reply to this post by lin_xd
what's this mean, but can open in exide
"sorry, error .."





--
此致

   林晓东

莫愁前路无知己,天下谁人不识君。

在 2017-04-18 15:18:01,"林晓东" <[hidden email]> 写道:
and I also suggest: for exide , do more different queries ,its output should in different window.(or tab pane area). 




--
此致

   林晓东

莫愁前路无知己,天下谁人不识君。


At 2017-04-18 10:21:22, "Joe Wicentowski" <[hidden email]> wrote: >Hi Adam and Xiaodong, > >I added console logging to test1.xq and test2.xq, so we have a >timestamp when each script starts and ends. On my end, I'm requesting >both scripts at the same start time. The difference between curl and >eXide is when test 2 starts. In curl, test2 starts immediately. In >eXide, test2 starts just before test1 ends. > >eXide >10:01:28.415 starting test1 >10:01:54.211 starting test2 >10:01:54.212 finished test2 >10:01:58.197 finished test1 > >curl >10:04:14.907 starting test1 >10:04:16.744 starting test2 >10:04:16.745 finished test2 >10:04:44.341 finished test1 > >I think there's something index-specific about this slowdown. To show >that this isn't just a case of eXide not being able to process any >queries in parallel, try executing these two queries in quick >succession in eXide: > >``` >util:wait(10000), >"done" >``` > >``` >1 >``` > >The 2nd query returns "1" immediately, and doesn't wait the 10 seconds >until the 1st is done. This is quite puzzling! > >I'm happy to file an issue, unless you'd like to, Xiaodong? > >Joe > >On Mon, Apr 17, 2017 at 5:40 PM, Adam Retter <[hidden email]> wrote: >> Joe, >> >> Okay thanks Joe, so are we happy that this is an issue with eXide? If >> so could you and Xiaodong work together to open an issue on the eXide >> issue tracker for Wolfgang on GitHub please? >> >> On 17 April 2017 at 17:22, Joe Wicentowski <[hidden email]> wrote: >>> Hi Adam, >>> >>> In my #4, I did test outside of eXide - by making requests (in Chrome) for >>> queries stored on the server, not processed by eXide. In that test I was >>> able to request and receive responses for test2.xq 30 times during the ~30 >>> seconds that test1.xq was churning away. So it seems quite clear that the >>> POST requests to eXide's "execute" endpoint get queued somehow, whereas >>> outside of eXide these requests can be processed in parallel. Testing with >>> curl would be a good idea too - removing numerous factors that a browser >>> brings into the picture. >>> >>> Joe >>> >>> On Mon, Apr 17, 2017 at 4:42 PM Adam Retter <[hidden email]> wrote: >>>> >>>> Hi Xiaodong and Joe, >>>> >>>> I think you have to test this outside of eXide, perhaps just use Curl >>>> to request the queries. >>>> >>>> On 17 April 2017 at 15:38, Joe Wicentowski <[hidden email]> wrote: >>>> > Hi Xiaodong, >>>> > >>>> > I can confirm your results when running your two queries in eXide: >>>> > >>>> > 1. The first, non-index-based ("slow") query takes ~25s >>>> > 2. The second, index-backed ("fast") query returns in ~.004s >>>> > 3. Starting the "fast" query after having submitted the "slow" query >>>> > (in eXide) causes the results of the "fast" to be delayed until after >>>> > the "slow" one is completed. >>>> > >>>> > Also, I saved your two queries as /db/test1.xq (slow) and /db/test2.xq >>>> > (fast), and noticed *different* results: >>>> > >>>> > 4. Running the two queries outside of eXide, by directly requesting >>>> > http://118.122.165.33:8091/exist/rest/db/test1.xq and >>>> > http://118.122.165.33:8091/exist/rest/db/test2.xq - allowed test2.xq >>>> > to complete quickly and without delay, while test1.xq took the same >>>> > ~25s to complete. Running a 3rd query involving no database hits or , >>>> > just "1" (to return the same input) >>>> > >>>> > Attached are two screenshots showing how these requests appear to >>>> > queue in eXide (under Chrome 57.0.2987.133). >>>> > >>>> > This suggests that some of the "queueing" you're seeing has something >>>> > to do with eXide's ajax execution, and that eXist is capable of >>>> > performing the two queries at the same time. >>>> > >>>> > Joe >>>> > >>>> > >>>> >> declare default element namespace "urn:sc-wst:v1"; >>>> >> >>>> >> collection('/db/ehr/v2/510682')//DataSet[HDSN00.01.017/@value="51062310120201001001"] >>>> >> >>>> >> then,this can be index optimized: >>>> >> >>>> >> declare default element namespace "urn:sc-wst:v1"; >>>> >> >>>> >> collection('/db/ehr/v2/008500')//DataSet[HDSN00.01.013/@value="a894317f-53da-486f-a1df-cea23200273d"] >>>> >>>> >>>> >>>> -- >>>> Adam Retter >>>> >>>> eXist Developer >>>> { United Kingdom } >>>> [hidden email] >>>> irc://irc.freenode.net/existdb >>> >>> -- >>> Sent from my iPhone >> >> >> >> -- >> Adam Retter >> >> eXist Developer >> { United Kingdom } >> [hidden email] >> irc://irc.freenode.net/existdb


 




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open
Reply | Threaded
Open this post in threaded view
|

Re: 回复:open test server,please give some advices!

Joe Wicentowski
Hi Xiaodong,

Re: eXide, I think the most productive route for these issues is to develop a fully self-contained, reproducible test that the eXist developers can run on their own systems.  Then submit an issue at https://github.com/wolfgangmm/eXide/issues.

Re: Dashboard, it looks like you've gotten some kind of 404 or 500 error.  To know for sure, you should open up your browser's developer console and get the detailed error message and response from the server.  If you're seeing this frequently, you might file an issue at https://github.com/eXist-db/dashboard/issues.  

Also, always remember to report your version of eXist.

Joe

On Tue, Apr 18, 2017 at 9:37 PM, 林晓东 <[hidden email]> wrote:
what's this mean, but can open in exide
"sorry, error .."





--
此致

   林晓东

莫愁前路无知己,天下谁人不识君。

在 2017-04-18 15:18:01,"林晓东" <[hidden email]> 写道:
and I also suggest: for exide , do more different queries ,its output should in different window.(or tab pane area). 




--
此致

   林晓东

莫愁前路无知己,天下谁人不识君。


At 2017-04-18 10:21:22, "Joe Wicentowski" <[hidden email]> wrote: >Hi Adam and Xiaodong, > >I added console logging to test1.xq and test2.xq, so we have a >timestamp when each script starts and ends. On my end, I'm requesting >both scripts at the same start time. The difference between curl and >eXide is when test 2 starts. In curl, test2 starts immediately. In >eXide, test2 starts just before test1 ends. > >eXide >10:01:28.415 starting test1 >10:01:54.211 starting test2 >10:01:54.212 finished test2 >10:01:58.197 finished test1 > >curl >10:04:14.907 starting test1 >10:04:16.744 starting test2 >10:04:16.745 finished test2 >10:04:44.341 finished test1 > >I think there's something index-specific about this slowdown. To show >that this isn't just a case of eXide not being able to process any >queries in parallel, try executing these two queries in quick >succession in eXide: > >``` >util:wait(10000), >"done" >``` > >``` >1 >``` > >The 2nd query returns "1" immediately, and doesn't wait the 10 seconds >until the 1st is done. This is quite puzzling! > >I'm happy to file an issue, unless you'd like to, Xiaodong? > >Joe > >On Mon, Apr 17, 2017 at 5:40 PM, Adam Retter <[hidden email]> wrote: >> Joe, >> >> Okay thanks Joe, so are we happy that this is an issue with eXide? If >> so could you and Xiaodong work together to open an issue on the eXide >> issue tracker for Wolfgang on GitHub please? >> >> On 17 April 2017 at 17:22, Joe Wicentowski <[hidden email]> wrote: >>> Hi Adam, >>> >>> In my #4, I did test outside of eXide - by making requests (in Chrome) for >>> queries stored on the server, not processed by eXide. In that test I was >>> able to request and receive responses for test2.xq 30 times during the ~30 >>> seconds that test1.xq was churning away. So it seems quite clear that the >>> POST requests to eXide's "execute" endpoint get queued somehow, whereas >>> outside of eXide these requests can be processed in parallel. Testing with >>> curl would be a good idea too - removing numerous factors that a browser >>> brings into the picture. >>> >>> Joe >>> >>> On Mon, Apr 17, 2017 at 4:42 PM Adam Retter <[hidden email]> wrote: >>>> >>>> Hi Xiaodong and Joe, >>>> >>>> I think you have to test this outside of eXide, perhaps just use Curl >>>> to request the queries. >>>> >>>> On 17 April 2017 at 15:38, Joe Wicentowski <[hidden email]> wrote: >>>> > Hi Xiaodong, >>>> > >>>> > I can confirm your results when running your two queries in eXide: >>>> > >>>> > 1. The first, non-index-based ("slow") query takes ~25s >>>> > 2. The second, index-backed ("fast") query returns in ~.004s >>>> > 3. Starting the "fast" query after having submitted the "slow" query >>>> > (in eXide) causes the results of the "fast" to be delayed until after >>>> > the "slow" one is completed. >>>> > >>>> > Also, I saved your two queries as /db/test1.xq (slow) and /db/test2.xq >>>> > (fast), and noticed *different* results: >>>> > >>>> > 4. Running the two queries outside of eXide, by directly requesting >>>> > http://118.122.165.33:8091/exist/rest/db/test1.xq and >>>> > http://118.122.165.33:8091/exist/rest/db/test2.xq - allowed test2.xq >>>> > to complete quickly and without delay, while test1.xq took the same >>>> > ~25s to complete. Running a 3rd query involving no database hits or , >>>> > just "1" (to return the same input) >>>> > >>>> > Attached are two screenshots showing how these requests appear to >>>> > queue in eXide (under Chrome 57.0.2987.133). >>>> > >>>> > This suggests that some of the "queueing" you're seeing has something >>>> > to do with eXide's ajax execution, and that eXist is capable of >>>> > performing the two queries at the same time. >>>> > >>>> > Joe >>>> > >>>> > >>>> >> declare default element namespace "urn:sc-wst:v1"; >>>> >> >>>> >> collection('/db/ehr/v2/510682')//DataSet[HDSN00.01.017/@value="51062310120201001001"] >>>> >> >>>> >> then,this can be index optimized: >>>> >> >>>> >> declare default element namespace "urn:sc-wst:v1"; >>>> >> >>>> >> collection('/db/ehr/v2/008500')//DataSet[HDSN00.01.013/@value="a894317f-53da-486f-a1df-cea23200273d"] >>>> >>>> >>>> >>>> -- >>>> Adam Retter >>>> >>>> eXist Developer >>>> { United Kingdom } >>>> [hidden email] >>>> irc://irc.freenode.net/existdb >>> >>> -- >>> Sent from my iPhone >> >> >> >> -- >> Adam Retter >> >> eXist Developer >> { United Kingdom } >> [hidden email] >> irc://irc.freenode.net/existdb


 




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open
12