Some of you may be experiencing some slow load times at buzztouch.com. Additionally, if you're apps are using the buzztouch.com control panel (you're not self hosting) your apps may also be experiencing slow load times (for data, etc). These troubles began yesterday afternoon and we're continuing to look into it. In most cases (when things slow down) the bottle neck is related to some insanely busy apps making tens of millions of requests to our backend. If you own one of these apps, congratulations! LOL. In call cases (when this happens) we need to isolate where the volume is coming from, work with the app owner(s) and move their super-successful home run app to an alternative server. We're in the process of doing this now.

congrats to whomever that is! Hope they have some good monetization going on...

Cool, I thought at first it was at my end.

I thought is my computer. Its great to see success through these ideas we have!

Thx for the heads up David.

Yeah I saw that David @buzztouch! Last night, I received this error: Errors occurred processing your request... 1) An error occurred processing your request. Could not load configuration data. (7) Edit: still receiving the same error..any ideas? LA

Well it;s nice to see that someone is having a great time, and also it's now something I need to report to the broadband people. But I do hope it is fixed soon, as I've got an update to submit to Apple tonight, and it's getting slightly annoying having to wait. We've become speed addicts. Ten years ago, this speed was typical! Only 4 years ago I read an article that some broadband company had managed to get 100Mbs for their internet speed. Now, half of Britain (that excludes me!), have these speeds.

Just as I published the post above, Buzztouch started working quickly again... LOL

The speed just picked back up. Jake

And...It is slow again. Wow. Congrats on whom ever owns this app. When you find out can it be posted? Jake

Tens of millions...wow, I was pretty happy with my quarter mill lol congrats to whomever app this is.

Update: It's been a long night and day, and into another night. Things are coming along. I'm feeling a bit ancy after gallons of coffee, millions of Linux command, and boatloads of hardware changes. The slowness is 100% caused by some crazy busy request volume. How's thousands per second sound. Yikes. In most web-apps it's the site visitor volume that drives things nuts. In our case, it's devices making the requests. One of the engineering challenges we face is the idea that PEOPLE using the site only account for a very small percentage of the volume. It's a boatload but it's nowhere near what apps do. DEVICES account for the majority and they make requests just like you and I do. We have lots and lots of room for improvement in terms of how the backend is engineered and once a year or so (for a few years now) we've gone through a major re-think in terms of what machines handle what processes, how much budget we can throw at it, etc, etc. Optimizing the backend is a full time job and it's bites us every now and again. It's time for another major re-think but not until everything humming along again. It should be soon. We intentionally don't brag or boast about the apps that are getting the volume for a few reasons. Partly because super-crazy-busy apps are generally a short term thing (think fad) and don't last long (the insane volume). When they fall off a top-x chart they slow down. And, because naming the app helps a large number of visitors find it, jump on our site, re-create a COPY (clone) of it, and nobody wins. I hate this part of our offer but for sure it's something we think about. If I posted the names of these apps most of us would giggle a little and move on. But, some of us (them?) would quickly realize how simple it would be to make a competing app that does nearly the same thing and the original app owner would get far less volume. It sucks but it's true. Nobody stands to gain anything (except a copy-catter) when we reveal this stuff. I'll be up all night again monitoring things to make sure all continues - even if slow. We expect the changes we implemented today to keep things fast starting in a few hours?

Well, congrats to the mystery user/app, and good luck to Buzztouch! :) I know it's not me; I'm self hosted, and my 'Guam oriented' apps wouldn't generate that kind of traffic if everyone on the island bought a phone and used my apps, lol! It's one of those 'good/bad' problems. Get some rest, David :) Cheers! -- Smug

Yup....another crazy bottleneck I discovered...which would be well served (to fix) on your self hosted.. Get this...bt_apn_devices.deviceToken is TEXT field. What the! This should be a varChar. It's long because Android device tokens are long. But, TEXT, geez...can't believe this got past me for this long. It "works" but it's super painful running queries on a large table with a WHERE clause against a TEXT field. Let alone the fact that it can't be indexed. Geez... 1) Change the TEXT field to varchar. ALTER TABLE bt_apn_devices CHANGE deviceToken deviceToken varchar(300); That will alter the table but will not alter any data. 2) Create two new indexes so queries run under .01 second as they should! CREATE INDEX deviceToken ON bt_apn_devices (deviceToken(50)); CREATE INDEX deviceType ON bt_apn_devices (deviceType); The first one only creates an index on the first 50 characters of the deviceToken field. This is much faster. It's not necessary to index the entire 200 character long string. These updates are in the next release of self hosted and it's not a big deal unless your pushing to more than about 1,000 devices. But, it'll save your server some pain none-the-less. Things flying now....sleeping for a bit and hoping the "SLOW SERVER ALARM" doesn't wake me. Yes, it exists. LOL d.

Sleep well. No more coffee. Cheers! -- Smug Those changes weren't too hard to implement; thanks :)

Implemented! Thanks David!

I believe I got the first part but the second part is escaping me. Any one got pics of what to do in phpmyadmin

You have to get from local host to the database that you are using for buzztouch. In that, click on SQL option from the main menu, and Paste the two lines, then click on Go. If you executed the first properly, the other two lines would be just more of the same.

Thanks David - sounds like it's been crazy back there behind the curtain. I don't miss those days as a consultant up until 4AM installing servers and PBX systems in the middle of the night. Been there and done that too many times. Thanks for all the efforts!

Thanks David for all your work!

@David: Thanks for the SQL Commants... Got it ... and go to sleep ;-)

Working like normal now, thanks for the work.

This brings up something I'm curious about - I was going to start a new thread but this seems like an appropriate place for it. Does Buzztouch have no data limit for hosted images? In my experience, it doesn't seem to - that's pretty incredible, but isn't that a huge server load? I'm not complaining of course..I'm just amazed at the amount of resources provided by this site at little/no cost to it's users (is file/image hosting available for free users?) This aspect of BT seems even more amazing in light of the fact that Dropbox will kill links with too much traffic AND the fact that Hostgator recently put a block on my site because of hosted images I was using in my apps the point: I don't know how you guys do it, but thanks! :)

Hostgator put a block on your site due to traffic? Even at this moment they're touting 'unlimited bandwidth' for their packages... Blocking a site doesn't quite sound like 'unlimited' to me... Cheers! -- Smug

Dropbox and Hostgator are also a lot more popular. I'd imagine if someone started really taking advantage of the Buzztouch file manager, it would be changed real quick. ;)

>Hostgator recently put a block on my site because of hosted images I was using in my apps What kind of hosting do you have? Shared, VPS or dedicated server? I have a VPS. It does cost more, but I can send 2000 email messages in a row, without throttling, which is prohibited for lower cost packages.