What we have here is a hard limit (3 streams per user, Basu does a good job
in explaining the math as you've quoted him), but it's in the SDK, not the
player. We based this on some empirical testing - we're not dynamically
measuring your bandwidth. I wondered aloud if it made sense to allow
developers to modify that limit, which I think I'm hearing the answer is
yes, we should.
hope that helps
Hi Fang -- the service looks great. I'd like to clarify a point about potential high-volume usage.
We're building a video chat app that could become very high-volume. Hypothetically, let's say we have 1m users, day and night. Each one sends 100 messages per hour and -- each month -- uses 100 MB of bandwidth. Hypothetically again, all the video/audio streaming would go through P2P.
1) Would it really cost $14.5 million per month, or does a 'user minute' register only when there is server activity for a user during a given minute?
2) Do you see these stats below as more or less accurate? [note that messages would be used only for: peering; IM on our site]
What's interesting about this model is that you're assuming 1M users at
all times. Based on experience, concurrency tends to run at less than 5% for
any service, so you're talking about at least 20M users total. So, if you
can derive $1/month of value per user, you're making $5.5M. Is that not
Thanks for your response, Nigel. I don't think that model will scale for any significant business. As an example, Facebook derives around $2 per year from its users, and it is starting to do a decent job monetizing. Now imagine if it relied on a 3rd party service like LCCS and they proposed taking a cut of 65% of gross revenues. Not realistic.
It seems to me that LCCS pricing is far out of line with FMS pricing -- around 100x more, even if you include Amazon EC2 hosting for FMS -- so I wondered if I am misreading the LCCS pricing?
You are quite right about 20MM users equating to 1MM connections. But what are the advantages of LCCS over FMS (or 'FMS + our own cluster engineering') when the price disparity is so enormous?
Comparing the "pay-per-use" pricing model with that of FMS's is really apples and oranges. The real answer here is that your project is probably too big for "pay-per-use" as this pricing model is really designed for people to get started quickly, easily, and cheaply. I think a concurrency based pricing model is more appropriate for your scale -- check out this blog post: http://blogs.adobe.com/collabmethods/2010/04/have_it_your_way.html.
Can you answer the following questions about LCCS Pay Per Use Pricing?
Is this version of LCCS only for developing prototypes or doing light development?
How would one be sure of uptime guarantee and is there any sort of technical support available?
I have heard that this environment will be taken offline for 12-24 hours or sometimes a day or two. Is this correct? If so, how can we deploy apps for our customers?
No, this version of LCCS is as good as it gets =). We've definitely never
taken the system offline for any length of time you describe - our uptime
for 2010 is actually above 99.9%. We do have scheduled maintenance windows,
which typically last an hour or less, and in most cases don't have any
downtime for our customers.
hope that helps
The current support mechanism available for "pay-per-use" and free trial customers today is through the forums. If you need full-time coverage, phone support and a service level guarantee, it's best to look at the other pricing options -- see this blog post here.