If I use Bing Maps Api to calculate a journey from A to B at a specific time where I know of heavy traffic on this route I get an accurate journey duration of 24 Min delay due to heavy traffic 44 Mins in total. If I use the Azure Maps Routing Api
https://atlas.microsoft.com/route/directions with
routeType=fastest
traffic=true
travelMode=car
and exact same time departure date time I am not getting an traffic delay I get duration of 20.9 Mins. I understand that the data comes from Tom Tom which is different from Bing. It seems that the Azure routing is just not accurate when compared to Bing. May be I am doing something wrong?
EDIT:
Here is my example Monday 14th Jan 2019 07:30 in Azure Maps using postman:
https://atlas.microsoft.com/route/directions/json?subscription-key=xxx&api-version=1.0&query=50.795225,-1.117809:50.850064,-1.071691&departAt=2019-01-14T07:30:00&travelMode=car&&traffic=true
Any non holiday monday is fine the route has to be in the future. This route is very traffic congested at this time 07:30.
If the put the same route into Bing maps you traveltime is
58 mins with 30 mins due to traffic.
With azure routing:
"routes": [
{
"summary": {
"lengthInMeters": 19357,
"travelTimeInSeconds": 2166,
"trafficDelayInSeconds": 0,
"departureTime": "2019-01-14T07:30:00Z",
"arrivalTime": "2019-01-14T08:06:05Z"
},
30 mins and no delay due to traffic.
Not getting any delay due to trafiic!
TomTom result does not explicitly show delays. Delays resulting from historic travel information are however included in travel time. As comparison from of Bing and TomTom routes (Start: 50.795225,-1.117809 ,Destination: 50.850064,-1.071691 , Departure: Jan 14 2019, 07:30). Results:
Bing;
Route length; 21 km
Travel time: 41 min
Delay: 11 min
Azure Maps/TomTom:
Route length; 19,35 km
Travel time: 36 min
Delay: 0 min
To get delay resulting from historic traffic information, routing parameter "&computeTravelTimeFor=all" needs to be added. This will not directly return delay from historic traffic, but travel times without any delays, travel time including delays from historic traffic info, travel time including delays from historic plus live traffic info
Related
I'm not getting expected results with some metrics I am tracking in Graphite and displaying in Grafana.
For metric like:
bitbucket.commits-per-user.username1.count
bitbucket.commits-per-user.username2.count
I have a retention policy like:
[default_bitbucket]
pattern = ^bitbucket\.
retentions = 1m:30d,1h:2y
I am pulling the data from an api, summarizing by the minute that the commit occurred for the user and adding it at with a timestamp of that minute (rounded down to the whole minute).
The storage-aggregation policy I am using is this:
[count_bitbucket]
pattern = ^bitbucket.*\.count$
xFilesFactor = 0
aggregationMethod = sum
I would expect that, once the timeframe exceeds 30 days, and I were running the metric with the function:
summarize(1d,sum,true)
, I would see commits per hour for whatever time period. However, It seems to be reporting significantly less per day once I move beyond 30 days.
Is there anything I am doing obviously wrong?
Could there be a problem if I don't add metrics for zeros on minutes when there are no commits?
I really appreciate any guidance - I'm fairly new to graphite.
I would like Prometheus to scrape metrics every hour and display these hourly scrape events in a table in a Grafana dashboard. I have the global scrape interval set to 1h in the prometheus.yml file. From the prometheus visualizer, it seems like Prometheus scrapes around the 43 minute mark of every hour. However, it also seems like this data is only valid for about 3 minutes: Prometheus graph
My situation, then, is this: In a Grafana table, I set the min step of a query on this metric to 1h, but this causes the table to say that there are no data points. However, if I set the min step to 5 minutes, it displays the hourly scrape events with a timestamp on the 45 minute mark. My guess as to why this happens is that Prometheus starts on the dot of some hour and steps either forward or backward by the min step.
This does achieve what I would like to do, but it also has potential for incorrect behavior if Prometheus ever does something like can been seen at the beginning of the earlier graph. I also know that I can add a time shift, but it seems like it is always relative to the current time rather than an absolute time.
Is it possible to increase the amount of time that the scrape data is valid in Prometheus without having to scrape again every 3 minutes? Or maybe tell Prometheus to scrape at the 00 minute mark of every hour? Or if not, then can I add a relative time shift to the table so that it goes from the 45 minute mark instead of the 00 minute mark?
On a side note, in the above Prometheus graph, the irregular data was scraped after Prometheus was started. I had started Prometheus around 18:30 on the 22nd, but Prometheus didn't scrape until 23:30, and then it scraped at different intervals until it stabilized around 2:43 on the 23rd. Does anybody know why?
Your data disappear because of the staleness strategy implemented in Prometheus. Once a sample has been ingested, the metric is considered stale after 5 minutes. I didn't find any configuration to change that value.
Scraping every hour is not really the philosophy of Prometheus. If your really need to scrape with such a low frequency, it could be a better idea to schedule a job sending the data to a push gateway or using a prom file fed to a node exporter (if it makes sense). You can then scrape this endpoint every 1-2 minutes.
You could also roll your own exporter that memorize the last scrape and scrape anew only if the data age exceeds one hour. (That's the solution I would prefer)
Now, as a quick solution you can request the data over the last hour and average on it. That way, you'll get the last (old) scrape taken into account:
avg_over_time(old_metric[1h])
It should work or have some transient incorrect values if there is some jitters in the scheduling of the scrape.
Regarding the issues you had about late scraping, I suspect the scraping failed at those dates. Prometheus retries only at the next schedule (1h in your case).
If the metric is scraped with intervals exceeding 5 minutes, then Prometheus would return gaps to Grafana because of staleness mechanism. These gaps can be filled with the last raw sample value by wrapping the queried time series into last_over_time function. Just specify the lookbehind window in square brackets, which equals or exceeds the interval between samples. For example, the following query would fill gaps for my_gauge time series with one hour interval between samples:
last_over_time(my_gauge[1h])
See these docs for time durations format, which can be used in square brackets.
I have a registration REST API which i want to test as -
Register 15000 users and pound the server with repeated incident reports (varying traffic with max being 100 per minute, min being 1 per 24 hrs and avg being one per minute ) over a period of 48 hours.
Which tool can I use to test stability of my REST API?
For pounding the server with incidents over a period of time, you can use http://runscope.com/ .
It is helpful for testing APIs. You can just trigger events in runscope over a period time or schedule it to hit the server as required.
When we discuss performance of a distributed system we use the terms tp50, tp90, tp99.99 TPS.
Could someone explain what do we mean by those?
tp90 is a maximum time under which 90% of requests have been served.
Imagine you have times:
10s
1000s
100s
2s
Calculating TP is very simple:
sort all times in ascending order: [2s, 10s, 100s, 1000s]
find latest item in portion you need to calculate. For TP50 it will ceil(4*.5)=2 requests. You need 2nd request. For TP90 it will be ceil(4*.9)=4. You need 4th request.
get time for the item found above. TP50=10s. TP90=1000s
Say if we are referring to in-terms of performance of an API, TP90 is the max time under which 90% of requests have been served.
TPx: Max response time taken by xth percentile of requests.
time taken by 10 requests in ms [2,1,3,4,5,6,7,8,9,10] - there are 10 response times
TP100 = 10
TP90 = 9
TP50 = 5
I am accessing an API hosted by Mashery with the following rate limit:
5 calls per second
10,000 calls per day
Does that imply that I can make 10,000 requests at 6:00PM, and then make another 10,000 requests at midnight? Or, does it mean I can only make 10,000 requests within any 24-hour period?
For example, does it mean that if I make 10,000 requests between 6:00PM one day, and 6:00PM the next, that I have to wait until 6:00:01PM before I can make another request. And then, at most I can make requests at the same rate I made the day prior (as the 24-hour period continuously shifts)?
I apologize if this is off-topic. I have a support request in for clarification, but I don't think they'll get back to me any time soon, and I figured that someone here would be familiar with the limits.
The limit is set per Calendar date and resets every midnight GMT time.
So for example if you made 10,000 calls at 6pm pacific (which is 2am GMT) you would have to wait 22 hours until 4pm pacific (which is midnight GMT) until you can start using your next batch of 10,000 daily calls.
Hope that answers your question.
Thanks,
Shai Simchi
Mashery Customer Support