I'm having this problem with grafana to query the number of requests incoming to my service.
Using Prometheus-net on my dotnet core Service, I have the "http_requests_received_total" which is a counter metric.
I run a 100 requests to Postman, ideally what I'd like to see is that at 12:20, a 100 requests came in (which is visible from seeing the counter go from 0 requests to 100 requests).
However, when using rate() or increase(), or sum(rate/increase), I keep getting approximate results and it's never an exact 100 requests.
Can anyone point me into a direction on how I can achieve this or read up upon it?
Thanks!
Prometheus may return fractional results from increase function because of extrapolation. See this issue for details. If you need exact integer results from increase() function, then try VictoriaMetrics - this is a Prometheus-like monitoring solution I work on. It returns the expected integer results from the increase() function.
Related
I am recording how long each request takes by capturing Date.now() before and after the request.
I am doing this because the inbuild metric for the response time only records the time taken for the FIRST REQUEST and not for any redirects that it follows.
My method was working fine until I started using the rps option.
The rps option throttles how many requests per second are sent.
The problem that this is causing is that my manual calculations are going up even though the HTTP_REQ_DURATION is roughly the same.
I presume this is because of the RPS throttle i.e. it is WAITING and this is causing my calc using Date.now() to go up - which is not an accurate reflection of what is happening.
How can I calculate the total time taken for a response to a request including all redirects when I am using the rps option?
I'd advise against using the RPS option and using an arrival-rate executor instead, for example, constant-arrival-rate.
Alternatively, you can set the maxRedirects option to 0, so k6 doesn't handle redirects itself. Then, when you handle the redirects yourself, you can get the Response object for each of the requests, not just the last one. Then you can sum their Response.timings.duration (or whatever you care about) and add the result in your custom metric, it will not contain any artificial delays caused by --rps.
I successfully sent my application logs which is in JSON format to Cloud Watch Logs using the Cloud Watch Logs SDK but I could not understand how to handle the constraints provided by the end point.
Question 1: Documentation says
If you call PutLogEvents twice within a narrow time period using the
same value for sequenceToken, both calls may be successful, or one may
be rejected.
Now what the word "May Be" means, is there no certain outcome?
Question 2:
Restriction is 10,000 inputlogevent are allowed in one batch, this is not too hard to incorporate code wise but there is size constraint too, only 1 MB can be sent in one batch. Does that mean every time I append inputlogevent to logevent collection/batch I need to calculate the size of the batch? Does that mean I need to check for both number of inputlogevent as well as size of overall batch when sending logs? Isn't that too cumbersome?
Question 3
What happens if one of my inputlogevent's 100th character reached 1 MB. Then I cannot simply send incomplete last log with just 100 characters, I would have to comepletely take that inputlogevent out of the picture and send it as a part of other batch?
Question 4
With multiple docker container writing logs, there will be constant change in sequence token, and alot of calls will fail coz sequence token will keep on changing.
Question 5:
In offical POC they have not checked any constraint at all. why so?
PutBatchEvent POC
Am I thinking in the right direction?
Here's my understanding on how to use Cloudwatch log. Hope this helps
Question 1: I believe there is no guarantee due to the nature of distributed systems, your request can land on the same cluster and be rejected or land of different clusters and both of them accept it
Question 2 & Question 3: For me log events should always be small, fast and put pretty rapidly. Most logging frameworks do help you configure ( Batch size for AWS / Number of lines for file logging... ) Take a look at these frameworks
Question 4: Each of your containers ( Or, any parallel application unit) should use and maintain their own sequenceTokens and each of them will get a separate log stream
I have been using the rvest package to perform screen scraping for some data analytics, but there are some queries that are taking a few seconds each to actually collect the data. e.g.
sectorurl = paste("http://finance.yahoo.com/q/pr?s=,",ticker,"+Profile", sep= "")
index <- read_html( sectorurl)
The second step is that one that is taking the time, so I was wondering if there were any diagnostics in the background of R or a clever package that could be run that will determine "network wait time" as opposed to CPU time, or something similar.
I would like to know if I'm stuck with the performance I have, or if actually my R code is performing well and it is http response that is limiting my process speed.
I don't think you will be able to separate the REST call from the client side code. However, my experience with accessing web services is that the network time generally dominates the total running time, with the "CPU" time being an order of magnitude, or more, less.
One option for you to try would be to paste your URL, which appears to be a GET, into a web browser and see how long it takes to complete from the console. You can compare this time against the total time taken in R for the same call. For this, try using system.time, which returns the CPU time used by a given expression.
require(stats)
system.time(read_html(sectorurl))
Check out the documentation for more information.
I have a requirement where I need to send HTTP requests to large number of small files (probably many 100 thousands) and I am trying to find an efficient way to create a large nuumber of HTTP Samplers under a thread group.
Is there a way to automate this so that I can create a request in such a way that
http:///folder[index]/file[index]
index can vary from 0..500000
I would like to pump the traffic with GETs on this request.
I believe that JMeter Functions is something which can help you in implementing your scenario.
If that index bit can be a random value in range from zero to 500000 amend your request as follows to use __Random function:
http://folder${__Random(0,500000,)}/file${__Random(0,500000,)}
If you want the index to be consecutive, i.e.
1st request - index=1
2nd request - index=2
etc.
Then __counter function is your friend and path stanza should be something like:
http://folder${__counter(,)}/file${__counter(,)}
See How to Use JMeter Functions post series for more details on the most popular JMeter functions.
I'm using JMeter for load testing. I'm going through and exercise of finding the max number of concurrent threads (users) that our webserver can handle by simply increasing the # of threads in my distributed JMeter test case, and firing off the test.
Then -- it struck me, that while the MAX number may be useful, the REAL number of users that my website actually handles on average is the number I need to make the test fruitful.
Here are a few pieces of information about our setup:
This is a mixed .NET/Classic ASP site. Upon login, a browser session (with timeout) is created in both for the users.
Each session times out after 60 minutes.
Is there a way using this information, IIS logs, performance counters, and/or some calculation that will help me determine the average # of concurrent users we handle on our production site?
You might use logparser with the QUANTIZE function to determine the peak number of requests over a suitable interval.
For a 10 second window, it would be something like:
logparser "select quantize(to_localtime(to_timestamp(date,time)), 10) as Qnt,
count(*) as Hits from yourLogFile.log group by Qnt order by Hits desc"
The reported counts won't be exactly the same as threads or users, but they should help get you pointed in the right direction.
The best way to do exact counts is probably with performance counters, but I'm not sure any of the standard ones works like you would want -- you'd probably need to create a custom counter.
I can see a couple options here.
Use Performance Monitor to get the current numbers or have it log all day and get an average. ASP.NET has a Requests Current counter. According to this page Classic ASP also has a Requests current, but I've never used it myself.
Run the IIS logs through Log Parser to get the total number of requests and how long each took. I'm thinking that if you know how many requests come in each hour and how long each took, you can get an average of how many were running concurrently.
Also, keep in mind that concurrent users isn't quite the same as concurrent threads on the server. For one, multiple threads will be active per user while content like images is being downloaded. And after that the user will be on the page for a few minutes while the server is idle.
My suggestion is that you define the stop conditions first, such as
Maximum CPU utilization
Maximum memory usage
Maximum response time for requests
Other key parameters you like
It is really subjective to choose the parameters and I personally cannot provide much experience on that.
Secondly you can see whether performance counters or IIS logs can map to the parameters. Then you set up proper mappings.
Thirdly you can start testing by simulating N users (threads) and see whether the stop conditions hit. If not hit, you can go to a higher number. If hit, you can use a smaller number. Recursively you will find a rough number.
However, that never means your web site in real world can take so many users. No simulation so far can cover all the edge cases.