I have just started using curator framework and found something that was very interesting and wanted to check if I my assumption is correct. Session time out in Zookeeper is twice the tikr time. So in my local zookeeper config file my tikr time is 8 seconds so the session time out becomes 16 seconds. Now when I create curator framework and set session time out to a value less than 16 seconds the negotiated session time out is set to 16 seconds but if I set the session timeout in the curator framework to say 25 seconds then the negotiated session time out is 25 seconds. Is it right to assume that the greater of the 2 values is set as session time out value?
The client sends a requested timeout, the ZK server responds with the timeout that it can give the client.
The current implementation requires that the timeout be a minimum of 2 times the tickTime (as set in the server configuration) and a maximum of 20 times the tickTime.
So a value less than 16 (8 * 2) will be increased to 16, and 25 is okay.
See https://zookeeper.apache.org/doc/current/zookeeperProgrammers.html#ch_zkSessions for more details
Related
We have registered the activities with auto-heartbeat configuration EnableAutoHeartBeat: true and also configured the activity option config HeartbeatTimeout: 15Min in the activity implementation.
Do we still need to explicitly send heart-beat using activity.heartbeat() or is it automatically taken care by the go-client library?
If its automatic, then what will happen if the Activity is waiting for external API response say >15Min delay?
What will happen during the activity heart-beat if the worker executing the activity crashes or killed?
Will Cadence retry the activities due to heart-beat failures?
No, the SDK will take care of it with this config.
The auto heartbeat will send heartbeat for every interval — the interval is 80% * Heartbeat timeout(15 minutes in your case) so that the activity won’t get timeout as long as the activity worker is still live.
So you should use a smaller heatbeat timeout, ideally 10~20s is the best.
The activity will fail with “heartbeat timeout “
Yes if you have set a retry policy .
See my other answer for retry policy
How to set proper timeout values for Cadence activities(local and regular activities, with or without retry)?
Example
Let say your activity implementation is waiting on AWS SDK API for 2 hours (max API timeout configured) --
You should still use 10-20 s for heartbeat timeout, and also use 2 hours for activity start to close timeout.
Heartbeat timeout is for detecting the host is not live anymore so that the activity can be restarted as early as possible.
Imagine this case:
Because the API takes 2 hours, the activity worker got restarted during the 2 hours.
If the HB timeout is 15 minutes, then Cadence will retry this activity after 15 minutes.
If HB timeout is 10s, then Cadence can retry it after 10s, because it will get HB timeout within 10 seconds.
I'm using Entity Framework Core 2.2 and i decided to follow some blog sugestion and enable retry on failure:
services.AddDbContext<MyDbContext>( options =>
options.UseSqlServer(Configurations["ConnectionString"]),
sqlServerOptionsAction: sqlOptions =>
{
sqlOptions.EnableRetryOnFailure(
maxRetryCount: 10,
maxRetryDelay: TimeSpan.FromSeconds(5),
errorNumbersToAdd: null);
});
My question is what is the maxRetryDelay argument for?
I would expect it to be the delay time between retries, but the name implies its the maximum time, does that mean i can do my 10 retries 1 second apart and not 5 seconds apart as i desire?
The delay between retries is randomized up to the value specified by maxRetryDelay.
This is done to avoid multiple retries occuring at the same time and overwhelming a server. Imagine for example 10K requests to a web service failing due to a network issue and retrying at the same time after 15 seconds. The database server would get a sudden wave of 15K queries.
By randomizing the delay, retries are spread across time and client.
The delay for each retry is calculated by ExecutionStragegy.GetNextDelay. The source shows it's a random exponential backoff.
The default SqlServerRetryingExecutionStrategy uses that implementation. A custom retry strategy could use a different implementation
If Thread: 100, Rampup: 1 and Loop count: 1 is the configuration, how will jmeter start sending requests to the server?
Request will be sent 1 req/sec or all requests will be sent all at once to server?
JMeter will send requests as fast as it can, to wit:
It will start all threads (virtual users) you define in Thread Group within the ramp-up period (in your case - 100 threads in 1 second)
Each thread (virtual user) will start executing Samplers which are present in the Thread Group upside down (or according to the Logic Controllers)
When there are no more samplers to execute or loops to iterate the thread will be shut down
When there are no more active threads left - JMeter test will end.
With regards to requests per second - it mostly depends on your application response time, i.e.
if you have 100 virtual users and response time is 1 second - you will get 100 requests/second
if you have 100 virtual users and response time is 2 seconds - you will get 50 requests/second
if you have 100 virtual users and response time is 500 milliseconds - you will get 200 requests/second
etc.
I would recommend increasing (and decreasing) the load gradually, this way you will be able to correlate increasing load with increasing throughput/response time/number of errors, etc. while releasing all threads at once will not tell you the full story (unless you're doing a form of spike testing, in this case consider using Synchronizing Timer)
JMeter's ramp-up period set as 1 means to start all 100 threads in 1 second.
This isn't recommended settings as describe below
The ramp-up period tells JMeter how long to take to "ramp-up" to the full number of threads chosen. If 10 threads are used, and the ramp-up period is 100 seconds, then JMeter will take 100 seconds to get all 10 threads up and running. Each thread will start 10 (100/10) seconds after the previous thread was begun. If there are 30 threads and a ramp-up period of 120 seconds, then each successive thread will be delayed by 4 seconds.
Ramp-up needs to be long enough to avoid too large a work-load at the start of a test, and short enough that the last threads start running before the first ones finish (unless one wants that to happen).
Start with Ramp-up = number of threads and adjust up or down as needed.
See also Can i set ramp up period 0 in JMeter?
bear in mind that with low rampup and many threads, you may be limited by local resources, so your results may be a measurement of client capability rather than server.
Whenever the URL is trying to load, it takes larger than the time set in the connection timeout, but setting the connection timeout to 20 seconds does not work it happens only after 2 minutes, and also whatever the time that is set in the connection time out, its taking exactly 2 minutes for the server to connection time out.
URL urlConnect = new URL(url.toString());
HttpURLConnection urlc = (HttpURLConnection) urlConnect.openConnection();
urlc.setDoInput(true);
urlc.setConnectTimeout(1000 * 20); // Timeout is in MILLI seconds
urlc.connect();
Or whether the 2 minutes is the default values for timeout? how to set the timeout to exactly 20 seconds. It doesnot have any redirect urls or anythings its a plain url. Why is it taking exactly 2 minutes for the connection to timeout?
I have kept NSURLRequest timeout interval 30sec. And I have also configured the auto retry 3 times for request. So if any problem comes in request then total time should be 120 seconds (i.e. 2 mins).
But When i have kept Debug point on my server and if i request to server then my time out period is getting 3 minutes.
Can I configure this timeout??? Or it should work??
Is this default timeout interval Once request is made to Server??
Please note that 30 seconds times 3 is 90 seconds, or one and a half minutes, not 2 minutes.
As for the timeout problem, try to init your NSURLRequest with initWithURL:cachePolicy:timeoutInterval:. Make sure to check the status of your NSURLConnection delegate methods, especially in connection:didFailWithError:.
Also, maybe you should explain how you measure the time out period on the server.