I am using JBoss JMX Console to monitor my Web Application.
How can i find what http requests are being processed at any point in time?
For eg: I see 25 busy theads - i want to know what http requests are these threads processing.
I am not really sure if there is an ability to map a specific request to a thread but you can certainly see what HTTP requests are made to Tomcat using AccessLogValve. You can probably use the timestamps to map those requests if need be.
Jasper;
The arduous way to do this is to examine every instance of the MBeans that have this pattern:
jboss.web:name=HttpRequest1,type=RequestProcessor,worker=http-0.0.0.0-18080
They are MBeans that represent the web request serving threads and they have an attribute called currentQueryString which is the query string of the request currently being processed. There are also attributes for currentUri and method. You could script the collection of this data as well.
An easier way, which is enabled in JBoss servers by default, is to use the available at:
http://localhost:8080/web-console/status
It handily aggregates those same MBean's and reports them in one page.
There is also options for a fuller report
http://localhost:8080/web-console/status?full=true
and an XML formatted output
http://localhost:8080/web-console/status?XML=true
Related
I am logging raw http requests to kafka.
GET /api/v1/user
GET /api/v1/friends
POST /api/v2/problem/solve HTTP/1.1
Host: domain.com
Content-Length:111
Cookie:...
{
"input":"{...}"
}
Obstruction, such as sessions and JWT tokens, will modify the source of the server.
I would like to make new requests based on these data, test them, and see the results, can you recommend a suitable solution?
I looked for Jmeter, K6, and others, but it was not a satisfactory solution.
You're looking for a load testing tool which will take the stuff you put to Kafka and generate end-to-end load test out of it? Good luck.
JMeter might be used in at least 2 ways:
If you're capable of exporting messages from Kafka into files you could consider using HTTP Raw Request sampler which has more or less the same syntax as your records
If not, you could use JSR223 PreProcessor for reading the records from Kafka and constructing the HTTP Request out of them, the JMeter API class you will need is HTTPSamplerProxy
I am using a fairly expensive external API (there's a cost per request) which makes testing code which uses it impractical.
In an ideal world, I would have a proxy server I would do my requests against which would cache each request (based on URL + query string) indefinitely and only hit the actual API server when I explicitly invalidate the cache for a given request. Is such a server available off the shelf with minimal configuration?
My current stack is Node.js, Docker, Nginx, PostgreSQL & AWS S3 (for non ephemeral state). I think Varnish might accomplish what I need but I'm not sure.
Varnish can and will accomplish that, but only if you build a 'test' API that returns some similar data you can play with. Your best bet if you have to save money, is to query the API a few times to get different typical responses. Once you know the ballpark of what to expect from it, create some sort of dummy API, or even some static JSON or XML files that you can use to mimic it. At that point you can test Varnish and Cache invalidation, and I'd be more than happy to help you with the syntax for that, given some examples of the code.
We are looking to add some performance measuring into our LOB web application. Is there a way to log all requests into IIS including the details of the request, the upload speed and time, the latency and the download speed and time?
We will store this into a log file so the customer can post this to us for analysis (the customer internally hosts our LOB web application).
Thanks
IIS 7 natively provides logging features. It will give you basic informations about requests (status code, date, call duration, IP, referer, ...) It's already a good starting point and it's very easy to enable in IIS manager.
Advanced Logging, distributed here or via WPI, give you a way to log additional information (http headers, http responses, custom fields...) . A really good introduction is available here.
that's the best you can do without entering into asp.net
There is no out-of-box direct solution for your problem. As Cybermaxs suggests you can use W3C logs to get information about requests, but those logs do not break down the request/response times in the way you seek.
You have two options:
1) Write an IIS module (C++ implementing CHttpModule in HTTPSERV.H) which intercepts all the relevant events and logs the times as you require. The problem with this solution is that writing these modules can be tricky and is error-prone.
2) Leverage IIS's Failed Request Tracing (http://www.iis.net/learn/troubleshoot/using-failed-request-tracing/troubleshoot-with-failed-request-tracing) which will cause IIS to write detailed logs which include a break down of time spent per request in a verbose/parseable XML format. You can enable "Failed Request Tracing" even for successful requests. The problem is that an individual XML file is generated for each request so you'll have to manage the directory (and Failed Request tracing configuration) so that this behaviour doesn't cause too much pain for your customer.
I have a .NET web service hosted in IIS. The web service has been used by clients over the past few years and there has been occassional timeout events when the client is on a slow connection (e.g. GPRS). On the other hand the clients sometimes have to POST some data to another web page (part of an ASP.NET web app) and usually the size of the data in the POST requests is bigger than the actual payloads in the web service calls. However the POST requests are far quicker as compared to the web service calls.
To establish this further I created a test web service with one method and another single web page with exactly the same operation i.e. receive 100K and send back 100K (random bytes) and I used a test client to call the web service method as well as did a post to the web page and got a response back using the same client. The difference in receiving a reply back from the web service and a response back from the web post request is huge i.e. about 1200 ms. Why is that the case? Is there any such configuration on the web service that would make such a big difference? Is it SOAP call stack? Serialization/Desrialization?
A number of factors could be contributing to this.
The first thing that leaps to mind for me is that SOAP could be considered a verbose protocol. That is, there's a LOT of data in the XML payload going both ways. XML is verbose in and of itself, and it's not exactly the fastest thing in the universe to process. Sure, you can use an optimized library to process it's data, but it'll be parsed out into object trees, then you can walk the nodes to drill down to the data you want. Unless you're using XPath, which will just do the same darned thing.
This is all presuming that you're actually using SOAP. And that your WebService is correctly configured. And that no packet loss is occurring while connecting to the Web Service. And that your firewall isn't creating issues. And that there's no encryption/decryption overhead.
In my own experience, one thing that frequently causes signficant slowdowns server side is one or more thrown exceptions. Try a Fiddler trace.
Scenario:
localhost receives the current HttpRequest with 3 hidden inputs and a posted file. I must then forward this form data to an external image host and get the response.
See the System.Net.WebClient and related classes. You can use them to create a request to the remote server and handle the response. Also get Fiddler to help you replicate what the browser sends.
I hate doing this. It wastes my server's bandwidth and ties up IIS threads as well as using my server's CPU. It sucks and it's worth avoiding at all cost. Many services like, one that comes to mind is fliqz, provide a mechanism such that the files are uploaded directly from the client to their server (bypassing yours) and then they make a request to your server passing it various info on the query string.