Is it possible in Google App Engine to get resource usage by each user.
Basically, the app is to be used by each user separately. There is no data thats shared between users (Simplifying a bit here, as its projects which are separate, to which users belong). I dont want to blindly charge users the same value, but rather find out the actual usage of resources by each of them, and charge them for the same. How could this be done in Google App Engine.
Also, lets say I create an app in App Engine for Google Apps Marketplace. And, I want each of the companies to pay for there usage of app. Does the problem remain the same in this context also ?
Clarification:
The resource usage by each user might vary a lot. It might even be, that most of the resources are being used by a single user (ex: heavy usage doesnt mean abuse of app, just that one would have to pay for the usage). Thats why I am trying to find per user resource usage.
Having separate apps for each user/project is an option (as suggested below). But then updates to the apps wont be easy.
You can assess some of this using the quota API. This only records CPU used in your app, not in API calls, however. Appstats is capable of recording CPU usage for API calls, so with some work you could reverse-engineer that for your own purposes. For other quotas - bandwidth in and out, data stored, and emails sent - you'd need to record these yourself, manually.
A much simpler option would be to bill your customers per user, or per active user. Simply set those prices at a threshold where you make a reasonable profit off typical users. Your customers will probably thank you, too, as it's much easier for them to predict costs this way.
for your second question you can create a diffrent APPID for each comany and deploy the app exclusively.
Related
I am working on an app where there is 1M hits every day.I want to use google drive as database .Can google drive bare this much traffic??
I strongly discourage using Drive as a database. Since that behaviour isn't its aim, it may create a noticeable bottleneck in your project. I recommend using Cloud SQL as an alternative. Nevertheless, these are the Drive API quota limits extracted from Google Cloud Platform ⮞ Navigation menu ⮞ IAM & Admin ⮞ Quotas:
If you really want to use Drive as a database, you must keep in mind those usage limits. I'll take for granted that you need to read a different row from the database per each hit, so no cache is involved here. In that scenario, assuming ideal user distribution, the project would cap at 8,640,000 daily hits (expecting ten different concurrent accounts to interact with the database in order to provide the data).
Is it possible for alexa user to have different responses based on config in the app. For example my skill is returning measurements. Some users may prefer metric and others imperial. I'd like users to be able to specify this (and may be some other things) to give a personalised experience. Can this be configured in the Amazon Alexa app?
I was thinking I might have to have some persistent storage for this (DDB for example) which would mean the app would write to the DDB and the skill would read from it to get the personalised response.
Thanks
Can this be configured in the Amazon Alexa app?
Unfortunately not in the way which you seem to be suggesting.
If you really wanted users to set preferences through the app, this could be done through account linking. However, it is generally discouraged (Alexa is meant to be "Voice-First") and likely to present additional obstacles if what you're wanting to do is allow users to set preferences for different devices.
However, using persistent storage for user preferences in generally is a good idea and as you've suggested, DynamoDB can do this.
If you take this approach you could ask users what their preferences are the first time they use a skill on a device and store this together with the device ID.
There is some good information about device ID in the Amazon documentation and some helpful tips here:
Get unique device id for every amazon echo devices
Anyone have an idea on how to achieve a differentiated service with Google App Engine? I have two types of users. One is premium while another one is free user. I would like to set different minimum latencies for firing up new GAE instances between the two. In other words, I am willing to pay extra for the traffic generated from the premium users. Nonetheless, for the free users, I would prefer to pay at minimum or within the daily free quota provided by Google. In my case, I expect that the free users are able to tolerate higher latency than the premium ones. I believe that this case should be quite general and apply to many people.
Assuming that I can identify types of users by the URLs they use or via other mechanisms. The only way I could think of is creating two separated applications and letting the premium users access the one that enables billing, while free users access the one that doesn't. However, my free and premium users need to share the datastore because they are also have to communicate within the application. Unfortunately, it seems that sharing a datastore across applications without hurting performance is not possible at the moment.
No, this is not possible right now. App Engine gives you a few knobs to balance cost vs. response time: instance class (applies to all versions), min/max pending latency, and min/max idle instances. The latter two sets of knobs only apply to the default version of your app.
There are other ways you can try to lower cost for free users though. e.g. give them limited storage, limit the number of logins or page views over a period of time, serve them lower quality images (if your app is image intensive), etc.
I'm not sure "cut costs for free users" is a useful strategy though. The conventional wisdom is that you want to turn your free users into paying customers (known as "conversion" in the biz). This is more or less what App Engine itself tries to do :P. There is no magic bullet that instantly turns free users into paying customers. The "trick" (if you can call it that) is to make the paid version of your app so compelling that people would rather part with their money in order to have it.
I´m thinking about to write an application will have to store a small amount of records per user (<300) but hopefully will have a lot of users (>>1000).
I did some research for a platform that allows starting small and scale if there is a need to do so and got stuck with App Engine, but I´m not sure if it is the right tool for it, especially the datastore.
How will I get it to scale if I have a User entity and a Message entity and store all users and messages in that entities? I think the amount of records in the entities will grow really big and filtering i.e. for all messages of a user will get expensive. Is that a problem or will Google handle that ? Do I have to introduce multitenancy and create a namespace for each user so I only see the records in the entities that relates to the user? Is there a limit for the number of namespaces ? What would be the right approach for modeling the data in the datastore?
I do not really have a clue how to handle the App Engine datastore and if its the right tool for me.
The App Engine datastore is explicitly designed to handle this kind of scalability. Queries execute in time proportional to the number of records returned, so fetching all a user's messages will take the same time regardless of how many users there are in the system.
I think with those kind of numbers you are probably ok in terms of scalability. anywhere from 300,000 to millions of records is easily handled by any serious datastore.
It is not advisable to think of scaling during the infancy of your project.. Your first step should always be to build an app/product and launch it... Scaling comes afterwords Most of the app/products that are launched these days never make it to the level where they need to scale.. even if you do make or launch such a website/product/app that gets hit by large amount of traffic and you need to scale, then rejoice!!! because you've made it to that level.. But how to get to that level should always be the first question...
I'm not trying to de-moralise you, rather trying to help you focus where you should be... Thanks for reading and good luck with your App! May you do need to scale and as Toby said, even the most basic App Engine configuration is good enough to handle a couple of hundred thousands of records...
I am trying to figure out the best way to deploy a single Google App Engine application across multiple regions.
The same code is to be used, but the stored data is specific to each region. Motivating examples are hyperlocal review sites, like yelp.com or urbanspoon, where restaurants and other businesses to review are specific to a region (e.g. boston.app.com, seattle.app.com).
A couple options include:
Create multiple GAE applications,
and duplicate the code across them.
Create a single GAE application, and store all data for all regions
in the same Datastore, with a region
identifier field for each model
delimiting the relevant region.
Some of the trade-offs:
Option 2 seems like it will be increasingly inefficient (space: replicating a region identifier for each record of every model; time: filtering/indexing on the identifier for every query).
Option 1 requires an app ID for every region, while GAE only allows 10 apps per account. Moreover, deploying the code across every region, as well as Datastore migration, seems like it could be a pain to manage.
In the ideal world, I would have a single application instance. From that instance, I could route between subdomains (like here), as well as have a separate Datastore for each subdomain. But I believe GAE only allows a single datastore per application.
Does anyone have ideas on the best way to solve this problem? Or options that I am not considering?
Thanks for your time!
I would recommend your approach #2. Storage space is cheap (and region codes are short), and datastore performance does not degrade with size, unlike most databases. Using a single app also makes for easier management and upgrades, and avoids any issues with the TOS (which prohibit sharding your app to avoid billing charges).
If you use source code revision control, then it is not too bad to push identical code into multiple apps. You could set a policy whereby only full-fledged tags are allowed to be pushed up to GAE. Another option is to make your application version the same as the revision number.
With App Engine, I (and I believe most others) always migrate data from within my model code. You can't easily do bulk migrations in GAE and the usual solution is to migrate data as you come across it in code. In this way, you can keep your models pretty much identical across applications.
Having said that, I would probably still go with a unified application. It's more future-proof. What if users want to join their L.A. identity and their New York identity? Or what if an advertiser offers you a sweet deal for you to run some marketing reports on your own data?
Finally, a few bytes of data doesn't matter so much on App Engine. As your site grows, you will very quickly discover that you will always be bumping into ceilings. GAE limits are extremely small compared to a traditional web server and so you will have to work within those limits anyway. For example, you can only fetch 1,000 records at a time. So your architecture will already support a piecemeal paging solution. So don't worry too much about an extra field or two in your record.