I have recently published my ASP .Net core (5.0) API database being used is Azure SQL Database as Azure App service. But while testing Api calls and their response time, I found something very strange. Azure App service response time is much higher compared to localhost running Api.
I am new to azure app service so if anybody could give me some insight on this what's going on.
I am adding app insights of api hosted in Azure and response time while running its locally
Azure Response:
Postman response :
Localhost response:
Update :
Both azure service and Azure Sql server in same resource group and in same region (Central US)
Dylan Morley's comment is useful, please follow his suggestion to investigate this issue.
Troubleshooting Steps:
Create a very simple api to test and check the response time.
If the response time is about the same, then it can be considered that the problem is not related to the App Service.
If the difference is large, please check the logging level.
Please add additional log in your code to check where the is time is spent.
Related
In my AWS remote Desktop, I have hosted my web application and API service application using IIS(internet information service). In that, Application pools stopped my API service in remote desktop IIS at every midnight of lesser usage time. In the morning always I restart my API services in IIS then it works fine. I need a permanent solution to fix this problem always API service will be in Up. Please suggest your solution.Attachment for reference
I was reading this article in looking for differences between creating an API using WebAPI and MVC and came across this statement:
In simple load testing on my local machine, I’ve found that Web API
endpoints hosted in console apps are nearly 50% faster than both
ASP.NET controller actions and Web API endpoints hosted within MVC
projects.
As such, I'm interested in how this would take shape in a production environment.
Obviously I'm looking for performance, so I looked into OWIN and self-hosting. However I'm not clear on if this offers the same efficiency as the console app discussed above.
Can someone please explain the proposal of hosting an API console application for consumption in a production environment - i.e. how would you connect a URL to the console app, etc.?
Thanks.
My understanding is self hosted OWIN apps can be run within any kind of app domain e.g console, windows forms, windows service, AWS EC2, Azure Worker Role etc. The application you should run it in is dependent upon the hosting environment you choose, there are lots of options.
I'm looking for a way to expose my customer's WCF Services as REST Services (and create all the security stack to support claims / oauth authentication and authorization)
I'm working on 2 different approach to do so:
Create a new REST Service which will act as a proxy to
expose my WCF Service as REST Services (11 services / 130 web methods to
migrate...) and secure it using an IP STS / RS STS
Use a existing product like Apigee which will do all those job for me and even more feature than initially planned.
I'm trying to play with Apigee first, but I'm facing an issue while creating the API Proxy.
I've deployed a simple WCF Service (with only 2 methods) on a Windows Azure VM exposed in basicHttp (which works as expected - means I test it in a Console app successfully, even when the client app is located outside my Azure's VM -).
Problem comes when I follow the Apigee workflow to expose it as a REST Service. I try to fetch service's wsdl on Apigee portal and got following error:
Error: Cannot invoke method getOperation() on null object
Does someone know where the issue come from ? I don't have much information from Apigee portal.
I already validate my wsdl through http://www.wsdl-analyzer.com/ but everything looks fine...
Meantime, Amazone webservice works fine on Apigee and generate the REST Service so problem seems to come from my service's WSDL
This bug has been fixed and will be included in the next release (R24.4). If you still have any problems with the new release, please let us know.
I recently got a similar error in the most recent version of Apigee (Version 141029).
The error: "Fetch WSDL Error: Cannot invoke method startsWith() on null object".
The fix was to rename my local file from "somename.xml" to "somename.wsdl".
I have SOAP services with data. I want to download all data from that service and upload it to my own server and then use these data from my server (don't worry I have permission for that). I want to do it because now I don't have function from that service which I need.
I want to use Windows Azure for this and I think SQL Database scenario would be best. Now I have classes for previous SOAP service so I think EF Code first would help me with creating database and I upload data somehow. But what about API? How can I access my data from windows phone or tablet? Is azure database enought or I must create more? Is there any good article for that?
I think what you are saying, is that you are aggregating data from several sources and storing the information in your own database. And, you would like your database to be Azure Database. Then, you want to build an API to expose the data you retrieved.
If this is indeed your goal, then yes, Azure will do everything you need. I'd recommend checking out Web API in conjunction with your Azure deployment. I've used this scheme with some success over the past year.
Warning: You should know that Azure Database does not have an SLA which means that Microsoft does not guarantee any level of performance including transactions/second. This means that if your API has a high load, you could end up getting throttled heavily in an unpredictable way. I've been bitten by this before and ended up moving my data to Azure Table Storage instead.
Windows Azure gives you a few options to expose an API to your mobile clients:
You could build an API yourself with the ASP.NET Web API (and use SQL Azure as backend): Mobile-friendly REST service using ASP.NET Web API and SQL Database
You can use Windows Azure Mobile Services, this does all the heavy lifting of building a backend for you
I have been struggling with setting up an iOS (Objective-C) app which utilizes the Service Management APIs. I've successfully was able to get Storage API calls working fine, but from what I'm reading, one big difference between the two Azure APIs seems to be a matter of authentication. For reference, what I'd ideally like to do is setup a simple API call to list the Hosted Services accounts in an app (eventually geared for public deployment).
According to the API Azure documentation, the Service Management APIs require a management certificate (.cer) to be uploaded and then for the client to utilize that cert to authenticate the request. My hunch is that this will prevent an app like the one I want to create from being feasible by any means, since public users with devices containing the downloaded app won't have that cert or the ability to attach it programatically in the objective-c code.
Is my hunch correct on this? Is this a forlorn idea that should not be pursued? I would think for this to be possible, the user would be required to upload their device's cert file to Azure somehow, and then to somehow have the app use this cert for authentication. I'm a bit lost on where to even begin on that, even if it is possible. :(
Any helpful info would be greatly appreciated. I have a lot of experience in the iOS side of things, but specifically in authentication/certificates of this type, I unfortunately have minimal experience.
Thanks in advance!!
-Vincent
Actually, I have an app that does exactly what you're talking about. CloudTools for Windows Azure is an iOS app that uses the Azure Management Service API to perform Azure management. It's been on iTunes for over a year.
Your question is somewhat broad, but I can tell you that the certificate issues were by far the biggest issues in designing/developing the app. You can't store the certificate in keychain, because keychain works in a manner such as this: a) you request a remote url that requires a certificate; b) that url tells you that it needs a certificate and c) keychain provides an appropriate certificate. It's a multi-request process. That won't work for Azure, because Azure service management APIs expect the initial call to include the certificate.
I require the users to add their certificate through iTunes File Sharing (steps here). Of course, they have to upload the public key portion to Azure. Then, I provide the certificate and private key with each request. I use the HTTP library ASIHttpRequest, although I believe that the latest (iOS 5.x) Apple libraries have similar functionality.
I'd be happy to provide any further details if you have any follow-up questions.
With Windows Azure, if you are using Service Management API then you really need to have certificate based authentication to create a SSL tunnel between your machine which is requesting the connection and Windows Azure Management Portal. I am not sure how wide your iOS application distribution is.
My first thought is that why would you want to deploy Windows Azure application from an iOS application, are you going to build application in iOS devices and deploy? Windows Azure Application deployment is mostly done on client machines so, Azure application management on iOS is great idea, however Application deployment from iOS not sure why. May be you are on something big here.. In both cases you really need Service Management Certificate on iOS device. If it is an enterprise app where you can let users to install Service Management certificate, it would be easier for iOS devices to use Service Mgmt API.
So if you want to use Service Management API from a client iOS app, I think the best solution will be to have WCF service hosted in Windows Azure which is configured to directly connect with your Windows Azure Portal. And from your iOS app, you just make call to your WCF service. This is very popular method to access service management API (through WCF Service) from any client app (WP7, iOS, Android) and the client side code is very light. On other hand you may need to pay to host a WCF service on Windows Azure.