iOS Will this process work?

[bmxbrah]

Im wanting to find a developer that can develop an app for me, but before I start shopping I have a very important question that needs to be addressed first.

Is it possible to create an app where users can hit a button, and the application stores the amount of times the button has been hit. So if they hit the button 15 times it will show that they have hit the button 15 times?

I know that is possible, but my real question is this. Take the same concept, but have multiple users hitting the button. So if I hit the button once and two other people hit it once, when I refresh the app it will show that the button has been hit 3 times. I want the app to be able to log everytime the button has been hit, and if 100 people are hitting the button at the exact same time can it keep up?

 

[chown33]

Yes, it's possible. It will take some concurrency control at the point where the count is being maintained, but it's not complicated concurrency control.
http://en.wikipedia.org/wiki/Concurrency_(computer_science)
http://en.wikipedia.org/wiki/Concurrency_control

I assume the point where the count is maintained is a single centralized location, such as a server of some kind.

If you're planning to do a distributed design, where nodes have their own count, and that's somehow communicated to other peer nodes with no centralized "master" node, then that's much more complicated.

 

[bmxbrah]

Yes, it's possible. It will take some concurrency control at the point where the count is being maintained, but it's not complicated concurrency control.
http://en.wikipedia.org/wiki/Concurrency_(computer_science)
http://en.wikipedia.org/wiki/Concurrency_control

I assume the point where the count is maintained is a single centralized location, such as a server of some kind.

If you're planning to do a distributed design, where nodes have their own count, and that's somehow communicated to other peer nodes with no centralized "master" node, then that's much more complicated.

I think so. The count would be maintained on the server rather than i guess several nodes which would be the devices? So then the server would be the master node. How effective is the concurrency control though? If the goal is to get billions of clicks in a relatively short time frame would concurrency control be futile? Thanks a ton for the answer btw.

 

[chown33]

I think so. The count would be maintained on the server rather than i guess several nodes which would be the devices? So then the server would be the master node. How effective is the concurrency control though? If the goal is to get billions of clicks in a relatively short time frame would concurrency control be futile? Thanks a ton for the answer btw.

I don't see any practical reason for simply counting clicks. You'll have to be more specific.

If those clicks represent votes, or auction bids, or something else, you need to be specific.

"Billions of clicks" implies billions of TCP/IP packets, each one arriving over an TCP/IP connection. That's a helluva network load, without even considering the concurrent counter question.

"A relatively short time frame" is meaningless without some scale. Is it minutes? Seconds? Milliseconds? Less? More? How much less or more?

Concurrency controls are commonplace in languages like Java. Other languages have their own controls, either as part of the language (like in Java, with its 'synchronized' keyword) or as library capabilities (like in C). Even Java has library functionality for thread-safe (i.e. concurrency-controlled) counters, in the java.util.concurrent.atomic package:
http://docs.oracle.com/javase/tutorial/essential/concurrency/atomicvars.html

This isn't necessarily a suggestion to use Java on the server side to maintain an atomic counter. Without knowing details of what you're actually trying to accomplish, it's silly to consider what language to write it in.

 

[Yakibomb]

This reminds me of the basic mechanism behind Curiosity

 

[bmxbrah]

I don't see any practical reason for simply counting clicks. You'll have to be more specific.

If those clicks represent votes, or auction bids, or something else, you need to be specific.

"Billions of clicks" implies billions of TCP/IP packets, each one arriving over an TCP/IP connection. That's a helluva network load, without even considering the concurrent counter question.

"A relatively short time frame" is meaningless without some scale. Is it minutes? Seconds? Milliseconds? Less? More? How much less or more?

Concurrency controls are commonplace in languages like Java. Other languages have their own controls, either as part of the language (like in Java, with its 'synchronized' keyword) or as library capabilities (like in C). Even Java has library functionality for thread-safe (i.e. concurrency-controlled) counters, in the java.util.concurrent.atomic package:
http://docs.oracle.com/javase/tutorial/essential/concurrency/atomicvars.html

This isn't necessarily a suggestion to use Java on the server side to maintain an atomic counter. Without knowing details of what you're actually trying to accomplish, it's silly to consider what language to write it in.

As in relatively short timespan im referring more towards a period of maybe a month or more. Theres about two million seconds in a month, and im curios as to whether a counter could log multiple clicks in a second.

As for what the clicks do its a way to find out how many impressions an ad has received. If theres a billion clicks, there is a billion impressions. I dont think an ad would get that many impressions, but im trying to figure out how much a system could support.

Thank you for your response also

 

[chown33]

As in relatively short timespan im referring more towards a period of maybe a month or more. Theres about two million seconds in a month, and im curios as to whether a counter could log multiple clicks in a second.

How many is "multiple"? You're heading into non-specificity again.

Dozens of clicks per second would be trivial. Something with the computational power of a Mac Plus could easily do it.

Today's servers are more powerful than a Mac Plus by 100's of times. Probably the lowest-cost Amazon EC2 instance could easily handle 1000 clicks/second, assuming the necessary network bandwidth could be sustained. The concurrency control on the counter would be only a tiny fraction of everything that's needed.

 

[bmxbrah]

How many is "multiple"? You're heading into non-specificity again.

Dozens of clicks per second would be trivial. Something with the computational power of a Mac Plus could easily do it.

Today's servers are more powerful than a Mac Plus by 100's of times. Probably the lowest-cost Amazon EC2 instance could easily handle 1000 clicks/second, assuming the necessary network bandwidth could be sustained. The concurrency control on the counter would be only a tiny fraction of everything that's needed.

1000 clicks a second would work.

So if my goal is to have a counter log each click at around 1000 clicks a second it would be possible with a concurrency control? After they click the button and refresh the counter it would show the updated amount of clicks. Im assuming there is a lot more that goes on, but with a server logging the clicks it is possible?

 

[chown33]

1000 clicks a second would work.

So if my goal is to have a counter log each click at around 1000 clicks a second it would be possible with a concurrency control? After they click the button and refresh the counter it would show the updated amount of clicks. Im assuming there is a lot more that goes on, but with a server logging the clicks it is possible?

Yes, to both questions.

Again, the concurrency control that ensures an accurate shared counter won't be the limiting factor. If I were guessing, I'd say the network bandwidth or latency would be the limiting factor. "Limiting factor" means the element or factor that limits the speed.

1000 connections/sec of network data in and out is not trivial. Compared to 1000 increments per second on a shared atomic counter, the network cost dwarfs the atomic counter cost.

 

[bmxbrah]

Yes, to both questions.

Again, the concurrency control that ensures an accurate shared counter won't be the limiting factor. If I were guessing, I'd say the network bandwidth or latency would be the limiting factor. "Limiting factor" means the element or factor that limits the speed.

1000 connections/sec of network data in and out is not trivial. Compared to 1000 increments per second on a shared atomic counter, the network cost dwarfs the atomic counter cost.

So 1000 connections of data going in and out is the problem? So when 1000 people hit a button to add to the atomic counter the action goes through the server updates the counter, and then sends the updated number back to 1000 users? Im sure several servers could handle it, but then it comes down to how much the servers cost.

I ran a little calculation, but im not sure how much data would go through every time someone hit the button. I put 500 bytes per page at 1,760 pages a second. The traffic came out to 2000gb per month of bandwidth. Thats 250$ worth of data.

Thank you so much for your answers too