My java application is connected to remote webservice application where appdynamics is not installed. I am seeing those services as backed services. The remote webservice application has multiple webservices. I want to track response time of each webservice separately. Should i create different tier for each service or resolve all services into single tier? Is there any other better way of doing this?
Business transactions should accomplish this. If you want to report on each web service you can build a report or custom dashboard. If you need more assistance just email help#appdynamics.com
Related
I am developing a mobile application using Telerik Platform. The services consumed by the app are ASP.NET Web API RESTful services which are hosted on Azure. I'd like to build some resilience into the app by adding a service bus and have been looking at Azure Service Bus which seems to be what I'm looking for.
It's fairly new to me and I have a few questions.
Can Azure Service Bus be used for RESTful services that return data or are they fire-and-forget only?
For simple RESTful services is Azure Service Bus the way to go or Azure Storage Queue? When would you use one vs the other?
When would I use a Queue vs Topic / Subscription?
ASB is about messaging. You use messaging for communication between parts of your system/services. RESTful services can leverage ASB by translating a request into a message to perform some work. Emphasis on converting the intent into a message, to instruct about work that needs to take place, not execute the work itself.
ASB or ASQ is your choice. This is where you need to choose between the features and capabilities each provides. There's a good MSFT comparison documentation on it.
Queues vs Topics/Subscriptions - if you need to send a message to a single destination (a command) then queue is simpler. In case a message needs to be broadcasted to multiple receivers (events), topics/subscriptions are your friends.
We're building a real-time Web-based monitoring system for .NET applications (ASP.NET and Windows executable). Those applications can start a long-running operations and statistics are displayed in real-time on Web page.
For ASP.NET ones we found SignalR a perfect solution: Long running operation (even caused by simple WebForms form postback) periodically call JS client-side functions via SignalR RPC to update monitoring page. But we hit 2 caveats:
In ASP.NET we need to monitor several different apps located in several different virtual directories. How do we push data from those different apps onto a single HTML monitoring page?
Another app is a .NET Windows console executable that runs periodically on a schedule. How do we push its run-time statistics to the same monitoring HTML page? One thing comes to mind - have EXE store temporary statistics in a DB and have client pull same data from the DB, but we'd like to avoid polling. Another - periodically at a given intervals the EXE would call the WebApp, passing the data - and WebApp would pass it to client via the same SignalR call. But are there better ways?
One architecture that I've used is a small monitoring collection service, with embedded monitoring clients in every monitored application, Asp.net, Windows desktop app, console app, Windows service, or otherwise.
The collection service is always running. A webapp then connects directly to the service and requests the state of all monitored apps.
Monitored apps run some small embedded client that feeds back application-specific metrics to the monitoring service. The client can either provide data on events or timers, or the monitoring service an ask for it on a timer itself.
With this, we have a unified monitoring architecture - everything that runs just talks to the monitoring service to send updates, and the health viewer clients just ask the service for data using a unified protocol.
It's basically the Application Server pattern applied to monitoring, and takes a couple cues from the design of SNMP.
Very new to SignalR, didn't realize it has multiple clients for different platforms. We will go with SignalR .NET client for all the apps - they will all talk to main SignalR hub directly invoking server-side methods, which in turn update monitoring page.
I am having trouble wrapping my head around whether or not my scenario will require scale out. I have a process in a windows service that pushes messages to a hub hosted in a web app via the signalr .net client. These are user specific messages and are distributed using the Client(connectionid) approach. If this is deployed in a web farm scenario will I need to use a scale out approach? When a user joins I am storing that connection info in the database. I store the url of the webserver and connectionid so I can target that when I publish messages from the windows service.
I would use this if it is an option.
http://www.asp.net/signalr/overview/performance/scaleout-with-windows-azure-service-bus
Louis
I have a .NET web-app (4.5) the app is a cloud app in the sense that it is hosted remotely and has its own local SQL data source.
The web app needs to talk to client SQL servers (in this case lets say my local SQL database). At the core the web app will request data from the remote SQL source and save it to the local SQL source, or the other way around the web-app may notify the remote SQL source that it needs to update a particular record, etc.
What would be the best way to do this?
I was looking at just doing a windows service on the client SQL server, and the web app makes calls to the client SQL box web service telling it what it needs to update or send over?
I started looking into WCF would this be a good application of WCF?
You may want to consider implementing an OData service as a WCF Data Service hosted in IIS that exposes data queried from SQL Server.
The following MSDN article provides an overview of a SQL Server OData implementation:
http://msdn.microsoft.com/en-us/data/gg192995.aspx
The following CodePlex link seems to provide good and relevant information pertaining to your scenario:
http://msftdbprodsamples.codeplex.com/releases/view/101644
Regards,
I am planning a 3-tiered architecture in which I need to track changes to domain objects on the client (a Windows Store app) then send those changes back to the server (an Azure worker-role). I just found out about WCF Data Services which I can run on the client and integrate with Entity Framework Code First on the server. It looks okay but I'm wondering what other tools may also be available.
Are there any alternatives to WCF Data Services for tracking changes in client then sending them to server? If available, I'd like a solution that doesn't require generated DTO classes but instead sends the deltas alone.
Have you considered using rest services?
Im not an AZURE user, but use elsewhere.
Azure rest services docu