Is there any voice call or any other diameter charging scenario in which 'Granted Service Unit' (GSU) can be more than 'Requested Service Unit' (RSU) ?
I think it is possible when subscriber uses less than the minimum charge interval, and when next time it sends CCR-Update request, our charging system should be able to grant requested quota + balance quota which we charged in previous call. i.e.
1) Initial quota request = 300 sec,
2) granted 300 sec,
3) Used - 4 sec (but minimum charge interval is 5 sec)
In this case when next time system re-request quota for 300 sec, charging system should grant 300 + 1 sec from previous balance.
Not sure if there is any other case where GSU > RSU
Related
how can I check my requirement of 100 requests are processed in less than 1 second in my gatling3 report. I ran this using jenkins.
my simulation looks like as below
rampConcurrentUsers(1) to (100) during (161 second),
constantConcurrentUsers(100) during (1 minute)
Below is my response time percentile graph of two executions for an interval of one second.
enter image []1 here
What does the min,max here will tell us, i am assuming the percentages 25%-99% are the completion of the request.
Those graph sections are not what you're after - they show the distribution of response times and the number of active users.
So min is the fastest response time
max is the longest
95% is the response time for which 95% of your requests were under
and so on...
So what you could do is look at the section of your graph corresponding to the 100 constant concurrent users injection stage. In this part you would require that the max response time always be under 1 second
(Note: there's something odd with your 2nd report - I assume it didn't come from running the stated injection profile as it has more than 100 concurrent users active)
If I use the gmail api to batch fetch 100 mails, does that count 500 quota units or 5? If its 500, then what should the queue setting on my App Engine queue.yaml be so I don't hit the 250 quota units/sec rate limit?
It will count as n items and not one. Also, 250 Quota units per sec is for per user. So, if in your batch request, you have different users, each user will have a 250 Unit Limit.
In the documentation it states:
The ListOrders and ListOrdersByNextToken operations together share a maximum request quota of 6 and a restore rate of 60.
It was my understanding that this means I could do something like this:
Call ListOrders: request quota = 5, orders downloaded = 100
Call ListOrdersByNextToken: request quota = 4, orders downloaded = 200
Call ListOrdersByNextToken: request quota = 3, orders downloaded = 300
Call ListOrdersByNextToken: request quota = 2, orders downloaded = 400
Call ListOrdersByNextToken: request quota = 1, orders downloaded = 500
Call ListOrdersByNextToken: request quota = 0, orders downloaded = 600
Then, since the restore rate is 60, after 6 minutes my request quota would be back to 6 and I could repeat the process. If I submit all the requests back-to-back, I could pull 600 orders every 6 minutes per merchant.
QUESTIONS:
Is my understanding of the throttle limit correct?
If it is correct, why have I been able to pull over 1000 orders in less than a minute? The only reason the program stops is that the merchant has no more orders to be pulled.
Thanks!
In my testing in February 2017, requests for ListOrdersByNextToken do, in fact, count against your request quota for ListOrders.
It is my understanding that the ...NextToken calls do not count towards the throttling limits. That means you've only made one call as far as throttling is concerned.
I send emails with cron job and task queue usage. The job is executed every 15 minutes and the queue used has the following setup:
- name: send-emails
rate: 1/m
max_concurrent_requests: 1
retry_parameters:
task_retry_limit: 0
But quite often apiproxy_errors.OverQuotaError exception happens. I am checking Quota Details and see that I am still within the daily quota (Recipients Emailed, Attachment Data Sent etc.), and I believe I couldn't be over maximum per minute limit, since the the rate I use is just 1 task per minute (i.e. send no more than 1 mail per minute).
Where am I wrong and what should I check?
How many emails are you sending? You have not set a bucket-size, so it defaults to 5. Your rate sets how often the bucket is replenished. So, with your current configuration, you can send 5 emails every minute. That means if you are sending more than 75 emails to the queue every 15 minutes, the queue will fill up, and eventually go over quota.
I have not tried this myself, but when you catch the apiproxy_errors.OverQuotaError exception, does the message contain any detail as to why it is over quota/which quota has been exceeded?
try:
send_mail_here
except apiproxy_errors.OverQuotaError, message:
logging.error(message)
I'm using the AppEngine's Backend instances and the daily free quota is 9 instance hours. However, I've been using a Backend with 10 instances for around 16-17 minutes and my usage has already crossed 66%.
The calculation I had in my mind was 17 mins * 10 instances = 170 mins ~ 2.8hrs which is definitely less than 66% of 9 hours.
Can someone explain me the billing scheme here?
From https://developers.google.com/appengine/docs/quotas#Requests:
Instance Hours (billable) In general, instance usage is billed on an
hourly basis based on the instance's uptime. Billing begins when the
instance starts and ends fifteen minutes after the instance shuts
down. You will be billed only for idle instances up to the number of
maximum idle instances set in the Performance Settings tab of the
Admin Console. Runtime overhead is counted against the instance
memory.
In your case, you'd have 17min of activity + 15min after activity = 32 minutes. So 320 minutes (32 * 10) is pretty close to 2/3 of 9 hours.
You should be able to see the details in the Usage History of your application.