I'm not sure if I am noticing a problem or bug yet, or if I just need to better understand how the URL Request test operates. So I have a few questions about the URL Request:
1. If "Download images" is enabled and a single image is referenced in multiple <IMG> tags on the page, will HostMonitor attempt to download that image only once or multiple times?
2. If a URL Request test executes but it has to wait because of HostMonitor's "tests per second" limit, will that wait time be included in the Reply value?
3. If "Check contents" is enabled, is the time required to do that included in the Reply value?
I guess what I'm trying to understand is what all might affect the Reply value of the URL Request tests. Any additional information along those lines will be greatly appreciated.
URL Request
HostMonitor downloads images only once.1. If "Download images" is enabled and a single image is referenced in multiple <IMG> tags on the page, will HostMonitor attempt to download that image only once or multiple times?
No.2. If a URL Request test executes but it has to wait because of HostMonitor's "tests per second" limit, will that wait time be included in the Reply value?
Time that processor spends for string search? Yes, it is included. But this time should be less than milisecond.3. If "Check contents" is enabled, is the time required to do that included in the Reply value?
Regards
Alex
-
Joel Decker
- Posts: 4
- Joined: Fri Sep 19, 2003 3:59 pm
If you don't mind, I have a couple more questions about the URL Request test:
1. I am assuming "Download nested frames" only refers to <FRAME>s, and that it doesn't do anything with <IFRAME>s. Am I correct in that assumption?
2. I'm also assuming that the time required to "Download nested frames" is included in the reply value. Is that assumption correct?
3. If "Download nested frames" is enabled but the page doesn't actually have any frames is there still some overhead time that would be included in the reply value?
Thanks for your help.
1. I am assuming "Download nested frames" only refers to <FRAME>s, and that it doesn't do anything with <IFRAME>s. Am I correct in that assumption?
2. I'm also assuming that the time required to "Download nested frames" is included in the reply value. Is that assumption correct?
3. If "Download nested frames" is enabled but the page doesn't actually have any frames is there still some overhead time that would be included in the reply value?
Thanks for your help.
Right. HostMonitor does not check IFRAMEs1. I am assuming "Download nested frames" only refers to <FRAME>s, and that it doesn't do anything with <IFRAME>s. Am I correct in that assumption?
Correct2. I'm also assuming that the time required to "Download nested frames" is included in the reply value. Is that assumption correct?
overhead time? HostMonitor may spend several milliseconds for frame search...3. If "Download nested frames" is enabled but the page doesn't actually have any frames is there still some overhead time that would be included in the reply value?
Looks like you concern about reply time a lot. I think it cannot be 100% accurate because your system running other applications, HostMonitor performs other tests, network may transfers some other IP packets at the same time, etc. It means you may see average picture with some little inaccuracy (ms)
Regards
Alex
-
Joel Decker
- Posts: 4
- Joined: Fri Sep 19, 2003 3:59 pm
I'm back. 
You were correct (last year) that we have been, and are, concerned about the reply times we have always been seeing. We have been experiencing reply times with major inaccuracy (many seconds), rather than some little inaccuracy (ms).
For example... one site normally comes back in 2-3 seconds when browsing to it from the Internet (i.e. using a PC external to the corporate network), but takes anywhere from 7-15 when browsing to it from a computer on the corporate network, and Host Monitor... which is on the corporate network... reports anywhere in the range of (on average) 15-45 seconds!
Since we got Host Monitor for it's monitoring/alerting, not for tracking reply times, it hasn't been a major issue. So we just occasionally revisit it, when we get some time, to see if we can determine the cause.
We are fairly confident the problem is some small, hard to find glitch on the corporate network. Which is evident in that fact that browsing to the site from any PC on the corporate network is considerably slower than hitting the site from a PC on the Internet.
The reason I have come back to post a reply to this thread is that we finally have some time to look into this some more, and I have three questions related to our current investigations into the problem.
While we know that anywhere on the corporate network gives slow response (7-15 secs), we are trying to figure out why the reply time in Host Monitor shows even so much slower (15-45 secs) reply times.
(Host Monitor 5.66 is the only thing running on that server, and we have run diagnostics on the NIC that showed the NIC is functioning properly.)
So I have these new questions:
1. Does a "URL request" test make separate connections for each component of the page, or does it use one "shared" connection to retrieve all items of the page?
2. What other differences might there be between the way the Host Monitor "URL request" test retrieves a complete page versus the way a standard browser retrieves a page?
3. Can you think of any reason why Host Monitor would show a page reply to of 15-45 secs, while using a standard browser results in 7-15 seconds?
Thanks for your help.
You were correct (last year) that we have been, and are, concerned about the reply times we have always been seeing. We have been experiencing reply times with major inaccuracy (many seconds), rather than some little inaccuracy (ms).
For example... one site normally comes back in 2-3 seconds when browsing to it from the Internet (i.e. using a PC external to the corporate network), but takes anywhere from 7-15 when browsing to it from a computer on the corporate network, and Host Monitor... which is on the corporate network... reports anywhere in the range of (on average) 15-45 seconds!
Since we got Host Monitor for it's monitoring/alerting, not for tracking reply times, it hasn't been a major issue. So we just occasionally revisit it, when we get some time, to see if we can determine the cause.
We are fairly confident the problem is some small, hard to find glitch on the corporate network. Which is evident in that fact that browsing to the site from any PC on the corporate network is considerably slower than hitting the site from a PC on the Internet.
The reason I have come back to post a reply to this thread is that we finally have some time to look into this some more, and I have three questions related to our current investigations into the problem.
While we know that anywhere on the corporate network gives slow response (7-15 secs), we are trying to figure out why the reply time in Host Monitor shows even so much slower (15-45 secs) reply times.
(Host Monitor 5.66 is the only thing running on that server, and we have run diagnostics on the NIC that showed the NIC is functioning properly.)
So I have these new questions:
1. Does a "URL request" test make separate connections for each component of the page, or does it use one "shared" connection to retrieve all items of the page?
2. What other differences might there be between the way the Host Monitor "URL request" test retrieves a complete page versus the way a standard browser retrieves a page?
3. Can you think of any reason why Host Monitor would show a page reply to of 15-45 secs, while using a standard browser results in 7-15 seconds?
Thanks for your help.