4 ms·

HTTP(S)

deleted 3y ago
[deleted]
withinboredom 3y ago
Interesting. Where are you pinging from? I'm seeing much less https ping: https://cloudup.com/c47xyiOpV4g https://cloudup.com/c47xyiOpV4g for https://statusduck.io/76687749-5690-48d9-9bd6-2f258f615978 https://statusduck.io/76687749-5690-48d9-9bd6-2f258f615978 and see ~500ms when curling from various places outside the EU.
- duckyio 3y ago
  It's fairly simple right now as we're on fly.io with machines in SJC and BOS. Being able to configure regions and having more clarity over the metrics is on the list
  - withinboredom 3y ago
    If you aren't already, you might want to do a HEAD request to cut down down on bandwidth usage. It'd be kinda messed up, but someone could just send you a few dozen gb's worth of data.
    - throwawaaarrgh 3y ago
      You'd get quite a few false positives
    - breather 3y ago
      HEAD requests are sometimes handled separately, why not just drop the connection after the header?
      - withinboredom 3y ago
        It depends on what you're measuring. If you just want the "ping", then send a SYN packet, wait for a SYN-ACK. You're done. If you want to get HTTP status message, send a HEAD request. If a server handles it differently than a GET without a body, that's not your problem. As an application developer, you might do this on purpose as a health check.
        breather 3y ago
        Sure, but if you're testing uptime, only the GET request matters. HTTP statuses are just one mode of failure. Timeouts are a major issue HEAD requests might not trip, for instance. I'm not saying my solution is without flaws, just saying actually detecting "status" automatically isn't trivial and HEAD requests only expose one facet if this.
        withinboredom 3y ago
        I’m not sure what you are saying makes sense. A HEAD request is (according to the http spec) a GET without the body. It can timeout, send cookies, status, etc. If someone decides not to implement the http spec properly, how is that your problem?
        breather 3y ago
        I mean if you want to provide value it is your problem. Regardless, just because HEAD requests CAN time out doesn't mean they WILL, even in good faith. GET requests will surface precisely the same behavior browsers do.
- dubcanada 3y ago
  It probably depends on what it considers to be a "response" it's very unlikely your 15ms is the total response, but probably just the initial server reply. 1400ms is more likely the actual full response.
  - withinboredom 3y ago
    Yeah, a HEAD request would likely be better. This 15ms check is also checking the body for some magical text to make sure the appropriate content is on the page and not an error message of some kind. > it's very unlikely your 15ms is the total response I'm seeing 9ms for the entire HTML payload on the server itself, and 90ms from my house. It's just returning a pre-generated html file, so it shouldn't be slow at all, bandwidth/RTT withstanding.

HTTP(S)

deleted 3y ago

[deleted]

Interesting. Where are you pinging from? I'm seeing much less https ping: https://cloudup.com/c47xyiOpV4g https://cloudup.com/c47xyiOpV4g for https://statusduck.io/76687749-5690-48d9-9bd6-2f258f615978 https://statusduck.io/76687749-5690-48d9-9bd6-2f258f615978 and see ~500ms when curling from various places outside the EU.

duckyio 3y ago
It's fairly simple right now as we're on fly.io with machines in SJC and BOS. Being able to configure regions and having more clarity over the metrics is on the list
- withinboredom 3y ago
  If you aren't already, you might want to do a HEAD request to cut down down on bandwidth usage. It'd be kinda messed up, but someone could just send you a few dozen gb's worth of data.
  - throwawaaarrgh 3y ago
    You'd get quite a few false positives
  - breather 3y ago
    HEAD requests are sometimes handled separately, why not just drop the connection after the header?
    - withinboredom 3y ago
      It depends on what you're measuring. If you just want the "ping", then send a SYN packet, wait for a SYN-ACK. You're done. If you want to get HTTP status message, send a HEAD request. If a server handles it differently than a GET without a body, that's not your problem. As an application developer, you might do this on purpose as a health check.
      - breather 3y ago
        Sure, but if you're testing uptime, only the GET request matters. HTTP statuses are just one mode of failure. Timeouts are a major issue HEAD requests might not trip, for instance. I'm not saying my solution is without flaws, just saying actually detecting "status" automatically isn't trivial and HEAD requests only expose one facet if this.
        withinboredom 3y ago
        I’m not sure what you are saying makes sense. A HEAD request is (according to the http spec) a GET without the body. It can timeout, send cookies, status, etc. If someone decides not to implement the http spec properly, how is that your problem?
        breather 3y ago
        I mean if you want to provide value it is your problem. Regardless, just because HEAD requests CAN time out doesn't mean they WILL, even in good faith. GET requests will surface precisely the same behavior browsers do.
dubcanada 3y ago
It probably depends on what it considers to be a "response" it's very unlikely your 15ms is the total response, but probably just the initial server reply. 1400ms is more likely the actual full response.
- withinboredom 3y ago
  Yeah, a HEAD request would likely be better. This 15ms check is also checking the body for some magical text to make sure the appropriate content is on the page and not an error message of some kind. > it's very unlikely your 15ms is the total response I'm seeing 9ms for the entire HTML payload on the server itself, and 90ms from my house. It's just returning a pre-generated html file, so it shouldn't be slow at all, bandwidth/RTT withstanding.