Closed laurelnaiad closed 9 years ago
Ok, once you've had a chance to count it we can start to digest root cause questions and try to assess where we stand with how well the server is warmed up now.
Today i trying the day zero case ( removed SamplesTack repo , got a rc1 branch fresh and install on ML 01/29 ) On accessing the IE9 browser i saw it waited for approx 30 sec and then gave the error message below . Able to reproduce the issue on latest .
Well, here's what that error screen looks like to me.
The middle tier is still taking too long for the http call from node express. 30 seconds is too long. The timeout error you're seeing in the gulp window is the same as was previously happening (before commit for #537). The error in the browser now shows the timeout from the proxy HTTP client, rather than getting back an error from node as previously happened.
That's my take. Do we push the milestone now? I'm more than happy to continue effort on this. Maybe we need to just tune some things and make the whole server faster, because it's not very fast. I'll put together the metrics of that first request and subsequent ones... it could be that pushing forward with CORS protection will alleviate this error too.
We can push the warm-up milestone and I can increase the timeout to 60 seconds for this release and until we get the warm-up straightened out. Sound ok?
Yes that sounds right to me.
With the latest i see the spinner for 60 sec and then browser shows the error message .
Wait seems some issue with my setup , retrying
If it isn't some other issue, I think it's worth noting that this machine seems to be getting slower and slower. how is the fragementation? How much of the RAM is virtual?
Just want to point out that if we have issues like #551, which should have been pretty much RAM only and takes more than 5 seconds, then the only problem here may be the QA machine, not anything in our code.
Yeah I gotta say, these timeouts are so long that I would WANT an error.
Like "talk about getting a MarkLogic cluster :)"
Look at the metrics on this search
cgreer@cgreer-laptop:~$ scurl http://appw7-brwt-3.marklogic.com:8006/v1/search
<search:metrics>
<search:query-resolution-time>PT0.399S</search:query-resolution-time>
<search:facet-resolution-time>PT0S</search:facet-resolution-time>
<search:snippet-resolution-time>PT0.072S</search:snippet-resolution-time>
<search:total-time>PT6.601S</search:total-time>
</search:metrics>
That is insane slow total time. Is this MarkLogic running over NFS or something?
Total time drops to 0.018 after a few requests (for the same query)
I think we've solved this issue though various mitigations and using better windows hardward. Recommend moving this along to ship -- gaurav was satisfied with 8.0-1 perf
:+1:
I am delighted by this :+1:
In e2e tests, I have a "dummy" request that gives the Java middle-tier a poke in order to warm it up. This helps avoid timeouts.
In the actual application, we have no such option. Let's discuss what we could do around the tail end of the bootrun task to get the JVM/Spring into memory and ready to respond to requests, so that we can bring down the browser tineout. I've just set the browser timeout to 30 seconds, but for a local app (or really any app that's not having actual internet connectivity problems) that shouldn't be necessary.