I don't really understand the expression "multiple outstanding requests".
could you please give me an example?
what is an outstanding request? what is the oposite of an "outstanding request"?
An outstanding request is one which has not been served yet.
For instance, an application could make 30 concurrent requests to different web servers. 10 of them may come back with a response, while the other 20 have not been serviced. Therefore, those 20 are outstanding since they are waiting for a response.
The opposite would be one that is served or completed I guess.
You can use an analogy of a restaurant. If you ask a waiter for water and a spoon, and he only returns you a water, then your request for a spoon is outstanding. It isn't complete until he gives you your spoon or tells you that he doesn't have one to give you.
Related
Why does Locust does not report RPS as greater than or equal to the user count? As you can see from the images below, despite have 100 users, RPS never reach close to 100.
Furthermore, there seems to be dips in the graph when running with high user count (1 million)
You can reach RPS equal to use count only if response time will be 1 second sharp.
if response time will be 500 ms - you will get 200 RPS
in case if response time will be 2000 ms - you will get 50 RPS
and so on
Check out How do I Correlate the Number of (Concurrent) Users with Hits Per Second for more comprehensive explanation if needed.
If you want to conduct the load of 100 RPS you can take a look at Locust issue 646 and choose the workaround you like the most.
In addition to response time Dmitri mentioned, your code will also play a factor in the RPS you'll be able to hit. wait_time in particular can limit RPS by increasing the amount of time between one user finishing their tasks and another one being spawned to replace it.
This answer has more details about wait_time's effect on response time but the majority of that will also apply here to you trying to hit an RPS target.
For your second graph, the dips you mentioned and the wild swings in RPS, general downward trend in RPS, and upward trend in response time are most likely mostly due to the system you're testing being unable to consistently handle the load you're throwing at it, with a bit of overloading your workers thrown in for good measure, especially at the higher end of the user count. Depending on your code, Locust may not be able to generate the 250,000 users you're wanting. Looks like it's possible Locust started falling behind after you hit 50,000 users. Each worker may only be able to easily maintain 10,000 users. You may need to make some changes to your code or increase the number of workers you're using to get better performance. See the Locust FAQ for more details.
Chrome gives a granular breakdown of the request lifecycle for a single resource.
The lifecycle shows how much time is spent in the following categories:
Queuing
Stalled
Request sent
Waiting (Time to first byte (TTFB))
Content Download
I was wondering does AFNetworking give us the ability to captures these categories?
I tried digging but there's not much info about these.
Although I have calculated the complete duration of request hit to response got time, but how could we make use of such granular breakdown through AFNetworking in order to improve our app performance.
I am building a web crawler. It grabs a main page, which has about 50 links. Then I need to do 2 requests for each link. I dont want to make 101 requests within a few seconds. What is the best way to randomly space these out? I want to somewhat mimic human activity.
urls.each do |url|
# Do Something
sleep([1,2,3,4,5].sample)
end
This will work, but is this the best was to do it? Let's say this takes about 1 hour to run, will the server become slow to respond when when it's sleeping?
Mimicking human behavior is very hard. It's impossible if you're requesting literally every single link on a website anyway. I would probably just request one page per second. The server will not be impacted at all by a thread that's currently sleeping.
Following a similar topic: http://developer.yahoo.com/yql/guide/usage_info_limits.html , and after reading the YQL documentation regarding: http://developer.yahoo.com/yql/guide/usage_info_limits.html, I still wonder about a certain issue:
considering YQL allows 1000 calls per IP, HTTP 304 (not modified) result still considered a hit?
meaning - are "304" results are counted as part of the 1000 calls per IP per hour?
thanks
EDIT:
I acceppted spier's answer since I got no better answer, and it;s been long enough since the question was asked :)
The following seems to indicate that cached 304 responses do not count against your limit.
http://www.yqlblog.net/blog/2010/03/12/avoiding-rate-limits-and-getting-banned-in-yql-and-pipes-caching-is-your-friend/
I don't know if the 304 responses counts to your hourly IP limit.
On the other hand if your underlying issue should be that the 1.000 calls are not enough:
What speaks against registering an application so that you get an access key and then use OAuth to authenticate? That would give you 10k calls per hour and 100k calls per day which is plenty for most use cases.
I'm designing a .net interface for sending and receiving a HL7 message and noticed on this forum theres a few people with this experience.
My question is.... Would anyone be able to share their experience on how long it could take to get a message response back from a hospital HL7 server. (Particularly when requesting patient demographics) - seconds / minutes / Hours?
My dilemma is do I design my application to make the user wait for the message to come back.
(Sorry if this is a little off topic, it’s still kinda programming related? – I searched the web for HL7 forums but got stuck so again if anyone knows of any please let me know )
cheers,
Jason
In my experience, you should receive an ACK or NAK back within a few seconds. The receiving application shouldn't do something like making you wait while it performs operations on the message. We have timeouts set to 30 seconds, and we almost never wait that long for a response.
This is quite dependent on the kind of HL7 message sent, typically messages like ADT's are sent as essentially updates to the server, and are acknowledged almost immediately if the hospital system is behaving well. This will result in a protocol level acknowledgement, which indicates that the peer has received the message but not necessarily processed it yet.
Typically, most systems will employ a broker or message queue in their integration engines so you get your ack almost immediately.
Other messages like lab request messages may actually send another non-ack message back which contains the information requested. These requests can take longer.
You can check with the peer you're communicating with to see what integration engine they are using, and if a queue sits on that end which would help ensure the response times are short.
In the HL7 integration tool I work on, we use queues for inbound data so we can responde immediately. And for our outbound connections, 10s timeouts are default, and seem to work fine for most of our customers.
When sending a Query type event in HL7, it could take a number of seconds to get the proper response back. You also need to code for the possibility that you will never get a response back, and the possibility that connected systems "don't do" queries.
Most HL7 nets that I have worked on, assume that all interested systems are listening for demographic updates at all times. Usually, receiving systems process these updates into a patient database that documents both the Person and Encounter (Stay) information on the fly.
In my location, my system usually gets about 10-20 thousand messages a day, most of which are patient demographic updates.
It depends if the response is generated automatically by a system or if the response is generated after an user does something on the system. For an automatic response it might take less than a second, depending of course on the processing that is done by the system and the current work load of that system. If the system is not too busy and processing is just a couple of queries and verification of some conditions, considering network delays, response time should be a few seconds or less.