Hi, Hard to believe this is my 1000th post! Amazing how fast time flies when you're having more fun than you thought possible! The brief downtime (or intermittently accessible) that buzztouch.com suffered over the weekend, apparently caused by a hyper-successful app in Australia, gave me pause to think about the implication of a scenario like that on my own BT-Server installation. I believe that one thing we all need to keep in mind is that we need to be prepared for the effects of success if we are running our own BT servers. Remember that for each app you create, unless you take it offline, there are two calls that will be made to your server : one for the Report to Cloud URL (which checks for the last time your app checked in), and the Configuration Data URL, which is the URL that your app pulls configuration information from. Imagine, for a moment, that you create a super successful app...let's say 25,000 downloads (it can happen...it did to another member of this forum!). Imagine that this app is online, in that both the Report to and Configuration URLs are the default...pointing to your server. Now imagine that people actually use that app on a regular basis. Is your server prepared for all that traffic? Does your hosting provider cap the traffic you are entitled to? Do they charge you huge amounts for going over? The basic message here is that for those of us running BT-Server, we need to be aware of the potential increase in demand and traffic on our servers, and be prepared to deal with problems associated with that. This, I believe, is one downside of hosting your own BT-Server. When we use buzztouch.com, David and his gang are responsible for maintaining the servers, and the do an excellent job. With self-hosted BT-Server, we are responsible for maintaining the server (or at least interfacing with our host provider), and we may not be inclined, or skilled enough, to do so. This is something that everybody should take into consideration. And I think it bears a lot of consideration when choosing your host provider. Free providers will most certainly have bandwidth limitations. Cut rate ones will as well. It's important to know what the limits are for your plan. OK, enough rambling. Looking forward to another 1000 posts with Buzztouch. I love this community! Mark

Good point GoNorthWest...I'm over 30,000 downloads on one of my apps and i am glad it is offline...this is a very good point to keep in mind!!

Hi, A big thanks for GoNorthWest for pointing this out. It is something bt-server owners really should take care of. Another thing to consider is (and correct me if I'm wrong): If you install bt-server on a free or cheap host and something goes wrong (e.g. too much traffic causing the server to break) you can't just pick everything up and move it to another server. So if I'm right, with what I just said, you should think this over before you start creating your bt-server setup (and attach clients to it). Best Regards, Danny PS Congrats with your 1000th post. Thank you for helping this community so good.

Congrats GoNorthWest on your 1000th post :) As an Aussie I'd love to know what that highly successful app was! Anything specific to Australia? Go buzztouch!!!! :)

Mark, excellent question. I've been wondering about this issue (hey, I'm allowed to daydream). How much bandwidth is needed? What are the costs of having such a sucess? How do you make the app scaleable? Are there terms & conditions we need to look for, avoid in choosing our host? Fred

I was thinking a bit about this on the way into work. To answer @Fred's question, I'm really not sure how to go about estimating the amount of bandwidth that would be required to support BT-Server in the long run. It would have to be an estimate based on the number of users you expect to use the server, times the potential number of apps they create, times the estimated success of those apps and the size the config files that come with them. Seems like it would be a pretty complex formula. I would be interested to see some numbers from Buzztouch regarding their own bandwidth usage. I know they have tens of thousand of user and probably just just as many successful and popular apps, so the must have some stats on bandwidth related to that. With regards to the question by @PSMDanny, I initially thought that it would be a showstopper with respect to implementing BT-Server, but then it occured to me that everything in the configuration points to a fully qualified domain name - i.e. buzztouch.com - so as long as you keep your domain the same, and probably the file system structure, then you should be OK. What I'm not certain about is moving the database information, but it's probably as simple as dumping a backup, and doing a restore on the new server. Sounds like good material for a new How-To document! Mark

Along those lines, Package name, what should be the proper best method to name a package? appname result com.appname or domainname.appname result com.domainname.appname From my reading I believe it should be the second, especially if you plan on placing on the Android Market or any other market. will this make it easier to move from one server to another, or is this a totally seperate issue?

I believe it should be the second, and that's how I name my packages. For instance, com.thunderstruck.azfishingspots. I don't believe it has anything to do with an actual domain name or anything...it mustn't, because that's the name I use with packages from buzztouch.com. So, you can really use whatever you want! Mark

No, I don't believe it has anything to do with the domain name, just a naming convention to avoid conflictiong package names. Bet there's a million HelloWorld apps, but there can only one on the Market. As far as moving your app from one server, will the package name make a difference?

I don't think the package name will make a difference. I don't think the package name actually connects the app in any way to a particular server...it's just supposed to be a unique name that can identify the app. I'll have to do some research on that to be sure...it's been on my list of things to look into. I'm pretty sure you can name the package anything you want (since it's done after the source download from BT), and as long as it was unique in the marketplace, all would be good. Mark

Hi @Mark, Thanks for pointing that out. There is only one thing (you shouldn't forget): when you create an api key at buzztouch, you have to give the ip-address of the server. Don't know if and how they use them but don't forget to edit this or renew when you move to another server. Would love to see your documentation on this topic (when it's finnished) Best Regards, Danny

Hi @PSMDanny, I'll have to investigate the API Key thing a bit. When I applied for mine, I just gave the domain name, and it grabbed the IP for me. But, there probably is some sort of relationship that has to be understood here. I'll post more info when I have it. Mark

As usually, @GoNorthWest is exactly right - lots of things to consider. Some good news and random thoughts about this... a) Package Names / Domain Names: The package name (java term, android) is not related to the URL the app pulls it's data from and has zero to do with where your apps data comes from. Domain names are important and very much related to the URL and the data the app polls for. Bad Scenarios: You don't have a domain name and you setup a BT-server behind an IP address. Next, you make an app and toss in the market. 10,000 folks download it. All of the remote configuration data in the app (config.txt file, report to cloud, documents, images, etc) use URL's that include the IP address of the data, not a domain name. This is significant when things go south and you need to move your backend. If you compiled your app with config data filled with the IP address of your server, and not a domain name, you'll be stuck for sure. Using a domain name is important because it allows you to 'point' the domain to a different server altogether when you need or want to. http://32.34.234.34/BT-server/.... BAD IDEA http://myCoolAppBuilder.com/BT-server.... GOOD IDEA. When the server hosting myCoolAppBuilder.com takes a dive, you can restore the backend and the apps will continue to work. It's very very unlikely (impossible maybe) to get the exact same IP address restored unless you have taken lots of things into consideration beforehand. You'll have even more trouble using IP addressees if you're relying on a third party host. b) Band width, server load, performance: This is something to think about but for %99.9 of all apps out of the more than 70,000 we've seen, it's not a big deal. Apache web servers and mySQL and PHP, even low cost ones, are totally capable of handing literally millions of requests. In almost all cases, the high volume (bandwidth) comes from downloading the app's config.txt file and the reportToCloud data. This is very very light, small, fast loading data. It's plain text. Plain text is easy for the internet and the device. Compare this for example to loading a giant movie a million times a day, big difference. For sure there are cases where a cheapo server won't cut it but I can say from experience that a low-cost server can handle far more requests than you may expect. We've worked with lots of enterprise clients over the last few years and haven't had much trouble with their existing equipment (usually old and slow! lol) running in some cases some super-duper busy apps. Another way to think about it, buzztouch.com's setup. Every single request made to buzztouch.com is routed through a load balancer. This load balancer is not a super-duper expensive machine, it's a relatively low power machine that's job is to route requests. It handles literally millions of requests a day without any trouble at all. This load balancer is running Apache and PHP just like every other box we run. It's NEVER been the source of any of our backend troubles. When things die around here, it's never been the load balancer server. It's a hard-drive failure, a database crash, a config file we screw up during maintenance, a rogue app that consumes all the memory of the server it's hosted on etc. Bottom line...these are for sure things to consider and definitely very very important but if you're hosting BT-server behind a domain name (and not an IP address) and do regulare backups of your web-directory and your database, you've done about all you can do until you get the 10,000 downloads a day issue. When this happens you'll need to hire two people. A backend guru and a boat captain. Tell the guru you want to ramp-up your backend to support the super-duper popular Angry Bears apps and let him / her do it for you. Tell the boat captain to fire up the yacht to take you to the bahamas so you can hide all your money in an offshore account. @GoNorthWest: 1000 posts, geez, I better get my behind in gear, you'll pass me soon! Great job and applause and thanks and all the other kudos you deserve.

Just a little clarification Dave: The Good Idea/Bad Idea are root settings on the BT-Server install?

Hi @WolfTimJ, Yes..the Good/Bad Idea is related to BT-Server install. Configuring it using a domain name allows you to move it from host to host with no problems. Configuring with an IP makes it difficult to move, because that IP is generally associated with a single server. Mark

Hi, I recently moved my BT-server installation to another server (different ip-address) and moved the old domainname to the new server. Everything went very smooth and had no problems. Just to let you know.... Best Regards, Danny