Is there a component in an Azure Mobile service that consumes API calls?
I created an Azure Mobile Service for an application that is still in Development. Its supposed to be an easy way for me to keep an offline sync of my database for a Windows UAP. All I have done so far is import my SQL Database to the mobile service using Visual Studio, haven't even finished implementing the Offline Sync.
My expectation would be to see 0 usage until my app was running, however its constantly showing 50-80 API calls an hour. My only thought is that there is something in Azure consuming API calls and I would like to turn it off.
Is your Mobile Service in the Basic or Standard tier? If so, you can get pings from some automated runners that are checking to make sure your site is working properly. You won't get charged for these API calls, even though they are showing up in the dashboard.
Related
I'm planning a project in which I have a windows service installed in on premise machines (about one hundred of them) which should keep in sync an online azure SQL db with the on premise ones (MS access, third party). That sync happens by calling a Web API.
I then have to build a mobile app which will be used by ~3k users that will access the synced data with Azure mobile app backend.
As for now I've started building a single mobile app backend project which serves both mobile app requests, and webapi2 requests used to sync data.
Furthermore I'll need to add queue/topic section to send realtime notifications from the app to on premise services.
My concern is if is it good practice to keep both "mobile app" and webapi2 in the same project, or should I separate them.
Any suggestion will be greatly appreciated.
Many thanks in advance!
You should, separate them. Based on your description, you should use the microservices architecture, you can read more about it in the links below.
Azure specific:
https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices
https://learn.microsoft.com/en-us/azure/architecture/microservices/
In general:
https://microservices.io/patterns/microservices.html
I am using Azure Web Apps to host my website. The website is loaded from a native apps for iOS and Android. During normal days non peak time , the web is operating as expected. However, from time to time , we are going to push out notification via apns or google gcm and that will drive users back to the apps. From there, content will be loaded from the website which is hosted from the Azure Web Apps.
During this peak times where there are thousands of requests coming in, there will be very high degree of fallout which results in errors.
It is shown in the picture below .
Traffic of the web apps after the push notification blasts
I have make sure that the database will not have any bottleneck during the operation. We are using SQL from Azure as well.
From the new portal, we are using service tier 'S1' for the App Services.
Previously, when the apps are developed, Web Apps and Mobile Services are separate service which are now join to become App Services.
Is there anything I could adjust from the azure backend or there is something which I missed out to handle ? Currently , we are also making the instance to be auto scaling.
As in conclusion, during high concurrent requests rushing in, the web apps seems to stop responding.
I would propose to implement the retry logic if there is no such yet and troubleshoot using the different modes.
UPD:
There is a detailed "analyzing performance" official guidance here - https://azure.microsoft.com/en-us/documentation/articles/app-service-web-troubleshoot-performance-degradation/ .
The most simple way to understand (or just mitigate) if the issue if somehow related to the underlying backend (throttling etc) is to change the mode site is working in. In your case, it can be S or even P.
Next step, if we eliminate the possibility of the throttling/etc, is to implement the diagnostics. My favourite tool is Application Insights, there is New Relic and other great tools as well. There are good guidances i saw and used:
http://www.asp.net/aspnet/overview/developing-apps-with-windows-azure/building-real-world-cloud-apps-with-windows-azure/monitoring-and-telemetry
https://github.com/mspnp/performance-optimization/blob/master/Assessing-System-Performance-Against-KPI.md#insertlink#
So, there is not silver answer about your question - highload is highload :-) Without access to the sources and website, and load tests results it is difficult to say what component of the project behaves itself bad.
If that is the helpful answer, please mark it as a helpful or as the answer. Thanks!
Can anyone please point out any benefits of using Azure Mobile services vs using a plain Azure app service / clean web api? For a starter / project type for a backend mobile solution.
I have somewhat mixed feelings on why I would want to use Azure Mobile Services.
As far as I see on Azure Mobile services you have an easier way of authenticating, you can use the notifcations hub more easily
and you have the different "built-in" ways of handling data (table storage etc).
Usually you would want some custom logics, user registration and handling when users register to your backend and you would like a more solid way of handling
and storing the data not privided by the OOTB datastorage.
You might also have another preference than using the /Table/ odata-endpoint you get with it or end up doing lots of logics to make your DAO's return data in properly for the OData endpoints.
All these things; IMO makes it more difficult to make the API/backend clean when using Azure Mobile services rather than a simple Web API with OData endpoints and swagger documentet API that can be used in a mobile-app just as easy.
Implementing / handling authentication and notifications ++ in Web Api ain't that diffucult nor time consuming.
So my problem Azure Mobile services is that it tends to fine for dev / prototyping and testing, but it might get really messy really fast when developing a proper backend.
Any thoughts and reasons why one should choose one instead of the other?
Think of Azure Mobile Services as V1 and App Service/Mobile App as V2. While Microsoft hasn't announced that Mobile Services will be phased out in the near future, if you start a new project, you should definitively look at App Service.
due to the fact that many people are confused about wether to take Web API or Web App or something different. They are going to put it all under one name. The underlying technology will be the same "i think".
But now you'll have in your portal the opportunity to add mobile push notifications, or add your swagger api definitions.
So when you're goint to stick with App Services you're not going to limit yourself.
Even when you're going to take Web Api you'll get all the functions as if you would take an App Service (if i'm correct).
*Edit: I looked it up in the portal. As I said, my old Web App Projects have the same settings as Web Api projects. So you don't need to decide anymore which kind of project you're taking. You get all the benefits out of the App Service.
A couple weeks back our Mobile App was migrated from the old portal to the new one and it hasn't behaved properly since.
Our main issues are:
We cannot access any logs files, the tab for Diagnostics logs stopped working entirely on Wednesday but even before that we never got any useful data out of this. When something goes wrong with our nodejs backend we can't find any clue as to what went wrong like we could in our old portal under the logs tab.
We are unable to access the FTP server entirely, it just won't let us login even though the credentials are correct and have been reset multiple times in attempts to get them working.
The server is throwing errors about not having enough disk space left even though we should have 53Gb to go (we're currently using 1.05Gb out of 55Gb)
Our deployments slots are not working at all, when we push our code to the deployment slot it just doesn't work, every request we make to the deployment slots tells us we're not allowed to do anything.
We are running a standard tier Mobile App server. The backend is in NodeJS, our CMS is in ASP.Net and our app itself is in Xamarin Forms.
The issues started after we migrated the server a couple weeks back from the manage.azure.com portal to portal.azure.com.
What can we do?
Edit:
We got through to Microsoft via the payed support plan which we're getting refunded because these are basic functionalities which don't work as advertised after the migration. I've got a call with them in about three hours to get things sorted, if I learn anything we can do ourselves I will update this post to share the knowledge.
This needs to be a support request to Microsoft.
If you can, open an incident with Microsoft Support. If you can't, post a question in the MSDN Community Forum. (We need to ask about particulars of your site and that isn't an appropriate topic for SO)
As the architecture of Mobile Apps is changed from Mobile Services, now the mobile apps migrate to Azure App Services.
Actually the Mobile Apps backend in Node.js is an expressjs project, and the mobile app sdk for node is a middleware of express. So the way for diagnostics and troubleshooting has changed from before we use Mobile Service. You can refer to https://azure.microsoft.com/en-us/documentation/articles/app-service-mobile-node-backend-how-to-use-server-sdk/#Debugging for details about Debugging and troubleshooting for mobile services.
Additionally, we can leverage the Visual Studio Team Services editor as the section How to: Edit code in Visual Studio Team Services shows in the link above, we can monitor the output of the Mobile Apps backend application. E.G:
About your FTP issue, please double check your deployment Username, when we login to FTP server on Azure, we need to input the full FTP user name which is "app\username":
You can refer to https://azure.microsoft.com/en-us/documentation/articles/web-sites-configure/#enabling-diagnostic-logs for details.
I have developed web api and deployed in windows azure. That web api is consumed in android application. That app is slow when fetching data from WEB API.
How to speed up app to fetch data from WEB API?
Thanks.
You first need to figure out why it's slow ?
Is the api method execution slow? Is it calling a database query and the DB is slow? Is it a bandwidth problem between the Android device and their network?
Could be a million and one things without you providing more information but here are a few things you could try.
Profile your database queries and see that they're executing and returning to the service in a timely fashion
Call your WebAPI methods from Chrome with the Dev Tools (F12) turned on. Checkout the network tab, and see how long the round trip time is for the request/response compared with the android call
Find out how many simultaneous calls are hitting your application, it could be that you just need to scale out with more web role processes.