Where in Paw 2 can I see the duration of a request / response? I suppose I could subtract the response time from the request time but there must be an easier way.
It's shown in the title bar right after the request is completed.
Though, as of version Paw 2.1.1, this time isn't accurate enough to judge of your server or network connection. The underlying HTTP library is optimized for logging / debugging and is loosing time between connecting, sending, receving, etc.
Related
I'm troubleshooting a slowness in my web API application. The issue I find is:
- a packet arrives containing the HTTP POST with Headers only.
- Then time passes (sometimes very long ~30 sec, sometimes milliseconds).
- another packet arrives containing the payload.
The split is always between headers and payload.
This causes the processing of the request in the app to be delayed by this interval.
Is it normal a packet will be split like that?
Have you encountered it?
Is it possible an AWS ELBv1 is somehow doing that?
Any direction will help - I'm totally confused...
Request duration? Via Paw HTTP Client: Is there a way to see how long a request took? I can't seem to find out how how something took.
You can see the request duration in the status bar right after sending the request:
Though, Paw is optimized for debug and testing, and is always slower than an actual HTTP client. Durations are always significantly higher than other clients.
I want to send the same http request repeatedly unless I get the right response, and the server is slow, sending the request is quick, receiving the response is quick also, but waiting for server to handle the request is slow. So if I send the request, and then waiting the failure should not be acceptable.
I think of the following workflow:
1)Sending the request
2)After sending the data, start a new request to send the same request
repeat 1-2, and the response should be handled asynchronously, and when detecting the right response, it stop sending request.
How to achieve this workflow or any other workflow can solve my problem. Any language and tool which will be fast would be considerable, like C/C++.
This will cause the server to simply respond slower and slower; your first request will be the first to receive any response, all the others will be wasted CPU time and bandwidth - if you did that to my servers you'd get your IP banned automatically.
What you need to consider is
why do you need the response this fast?
can you cache the response so that re-requesting it is no longer needed
perhaps having a caching proxy between your client(s) and the server will cover your needs? (also, prefetching)
I am trying to measure performance of the server side code. Looking at the request from the client, Fiddler gives me the following view:
Fiddler's documentation states: The vertical line indicates the time to first byte of the server's response (Timers.ServerBeginResponse).
Does that mean the time of servers TCP response (e.g. ACK) or does it mean to tell me that the server has compiled all the data in less than half a second and took about 5 seconds to transfer it?
TTFB is the time from the moment the request is fired to getting the first byte back from the server as a response. It includes all the steps for that to happen.
It is the duration from the virtual user making an HTTP request to the
first byte of the page being received by the browser. This time is
made up of the socket connection time, the time taken to send the HTTP
request and the time to taken to get the first byte of the page.
So yes less than 1/2 second to respond, then 5secs to transfer.
I am submitting POST requests to an external server running IIS6. This is a time critical request where I want to ensure that my request is processed at a specific time (say 10:00:00 AM). No earlier. And I want to ensure that at that specific time, my request is assigned the highest priority over other requests. Would any of this help:
Sending most of the message a few seconds early and sending the last byte or so a few milliseconds prior to 10:00:00. Not sure if this will help as I will be competing with other requests that come in around that time. Will IIS assign a higher priority to my request based on how long I am connected?
Anything that I can add to the message header to tell the server to queue my request and process only at a specific time?
Any known hacks that I can leverage?
No - HTTP is not a real time protocol. It usually runs on top of TCP/IP which is not a real time protocol. While you can get near real-time behaviour out of such an architecture its far from simple - don't take my word for it - go read the source code for xntpd.
Having said that you give no details of the actual level of precision you require - but your post implies that it could be up to a second - which is a very long time for submitting a request to a webserver. On the other hand, scheduling such an event to fire client side with this level of accuracy is very difficult - I've not tried measuring the accuracy of the scheduler on MSWindowsNT but elsewhere I'd only expect it to be accurate to about 5 minutes. So you'd need to schedule the job to start 5 minutes early then sleep for 10 milliseconds at a time until the target time rolls around.
But then again, thinking about why you need to run any job with any sort of timing accuracy makes me think that you're trying to solve the problem the wrong way.
C.
It sounds like you need more of a scheduler system then trying to use http. HTTP is a stateless protocol, you send a request to IIS, you get a response.
What you might want to consider is taking that request, and then storing the information you require somewhere (database). Then using some sort of scheduler (cronjobs, scheduled tasks) you action that information at the desired time.
What you want, you probably can't achieve with IIS, it's not what it is designed to do.