Got an App - Loads of tiny server requests - What solution to choose ?
Ok, so I programmed an app.
The app connects to the server many times a day, and with potential many users, this will give a ton of info to be passed to the server and info sent back..
Say we send info of 6 bytes pr 1 time.
10.000 users x 6 bytes = 167 operations pr second (1 time each user within a minute)
100.000 users x 6 bytes = 1670 operations (1 time each user within a minute)
This is expected 1 read / 1 write to the mysql db for each user for each time.
This is off course with perfect balancing, which is part of what i also try to make sure the app adapts to.
Say we have multiple operations on top of each other for users.
Then we have some other random as well.. should we say average 1 reads and 1 write on top.
Then we have 3340 reads and 3340 writes pr second at 100.000 users.
Should we say i need at least 40% overhead for cases where the op top average is not balanced.
A roughly 40% overhead - That is around 5000 reads and 5000 writes pr second and full 33mbit of bandwidth @ 100% time -
By the way... There is not expected to be implemented any catchup, if the server would be unreachable/user is out of reach from connecting to the server.
I suspect that i need a pretty capable solution or multiple servers like a CDN of my own.. ?
But i might be wrong - Can anyone give me a good idea of what i should look for, when selecting a solution for something like this.. ?
All numbers are straight out of my blue - but i like to prepare - not to end in a position where i did not see problems coming if I ever reach such a level.
The server side is php/mysql - connection i use is httppost.
Thanks in advance.
If there are responds with services like google app engine, amazon, azure - please tell your experience of solution / pricing in comparison, what you else have used comparable in normal server/vps solution.
Last edited by niehoe; 11-05-2013 at 11:09 AM.
Reason: Adding services
1. i wouldn't use vps if you're thinking at that number of users. You need resources dedicated to use that.
2. you didn't include the time it takes for mysql to reply when there are 100k users online / minute. i guess you didn't test it that far.
3. google app engine/amazon/azure - are all VPS in one way or another, not dedicated machines. See point 1... even if i host an amazing app on google app engine, with no downtime and google taking care of cpu/ram/etc... i find it expensive to run it for personal projects (unless you have a huge budget)
4. are all users next to your server? if you get 50% of users from europe and 50% from US, it might worth looking into a CDN and host same thing in 2 places.
what i would do in your place:
- it looks like you're at the beginning of the road with your app, so i would start small.
- one small dedicated or one medium-big vps depending on budget
- if you need to expand, ask your provider to bring in another server and load balance your requests to both of them (cloudflare does an amazing load-balancing)
- if not, you'll keep your costs down
hopefully i understood your questions... good luck!
You understood me perfectly. We are in the very early stages of this app.
I know i could go with a big hardcore scalable solution, but i suspect that we do not have enough money flow to have it flow perfectly permanently if we don't keep it cost-effective from day 1.
Currently I am running a website on a VPS where I have a I7-4770k CPU / 16gb RAM running on 1 normal single harddrive. The server is used for encoding purposes, as well as media distibution, and we never really push it with the traffic we are leading to it. I have no idea what such a solution is capable of in reference to the app world.
I actually did not really think of it that way db-wise.
I just tried to input something into the current VPS i have online.
Inserted 1 row : 0.0036 sec ~ 277 single entries / sec
During a try to input a ton of rows in 1 entry i got this stats of the server load :
Load average: 0.80, 0.35, 0.12 - It does not really mean a lot to me.
Also just tested a with a mysql db i have hosted in a shared hosting solution.
First time : Inserted 1 row : 0.0008 sec ~ 1250 single entries / sec
Second time : Inserted 1 row : 0.0034 sec ~ 294 single entries / sec
Third time : Inserted 1 row : 0.0015 sec ~ 666 - || -
So what should i aim for to have the best solution for mysql tasks like this : cpu power / ssd's / ram amount ?
Last edited by niehoe; 11-05-2013 at 07:07 PM.
Reason: corrected language
you can't calculate the times like this... there are so many other factors.
> First time : Inserted 1 row : 0.0008 sec ~ 1250 single entries / sec
What if after entry 999, there's a cron that locks the table for 1min?
> So what should i aim for to have the best solution for mysql tasks like
> this : cpu power / ssd's / ram amount ?
MySQL is amazing, google "percona".
I guess after a while you'll be adding indexes. Insert will slow a little bit. Add on top of that concurrency and you'll slow a lot more.
CPU is great, but if you're reaching the cpu limit, either the app is wrongly designed or the queries are wrong (eg. not using indexes as they should)
RAM is even better, google "innodb buffer pool"
SSD... i wouldn't even consider running a high traffic DB without SSD as storage.
Then off course, when the time comes, you can move DB to dedicated node, add 2-3-4 PHP nodes, couple of static, look into master-slave replication... the usual scalability issues of mysql.
By the way, if you didn't start your app yet, look into RIAK as well, it might work for you...
Your benchmarks are malformed. Rules of scalability:
Rule 1) Raw number benchmarks are useless.
Rule 2) You never know where the bottleneck is before hand.
Rule 3) You never know what the bottleneck looks like before hand.
Rule 4) You never know why the bottleneck occurs before hand.
Rule 5) The bottleneck is always the database.
Step back, and look at what data is being written and read. Are they independent, or do you need to read-back the writes. Even if you need to gather results, how synchronous is the problem? Do you really need to impose db level locking (eg: index inserts)?
If you manage to relax any of those, then most likely the DB will not be the issue.