We work in the area of video streaming and we are writing some software for a set top box that queries our server for a list of channels (NBC,FOX etc) so that it can select one. Also it needs to tell the server what it is currently doing (i.e. which channel selected, is it playing or paused etc) as the user can control the STB with remote control.
Also from another UI to the server another user can change the channel that is played on the STB.
So my question is an architecture one - would it be better for the STB to poll the server every so often (say few seconds) or should the server push the changes and check the STB every few seconds. There could be 100s of set to boxes.
I was thinking about exposing a number of web services and then the STB would poll and with each poll if there is change from another user it can then react otherwise each poll would be a status update.
In addition, whatever design we come up with we should be able to expose our API to 3rd party STB manufacturers so that they work with us.
Related
1.Through jmeter recorded the script with out images.
2.Run the script by keeping 10 users.
3.Jmeter will show the execution and response time.
But how can we justify and show evidence to top level managemnt that even though with out capturing images the application response time is same as live user experience.
The better way to do it would be to check the option "Retrieve All Embedded Resources" in: Thread Group Right Click -> Sampler -> HTTP Request -> Advanced -> Retrieve All Embedded Resources so all resources all loaded.
If you don't want to measure the embedded resources response times, for example if you are using a CDN or 3rd parties, you can use a "View Results Table" and enable the option "Child samples". This way you can see the response time from the main requests and from the embedded resources separately.
The issue is, secondary requests are made in parallel threads, so the sum of the response times is larger than the response time registered by the Transaction Controller. To avoid this you can select the option "Parallel downloads. Number", next to "Retrieve All Embedded Resources" in "HTTP Request" and enter the number of "parallel downloads".
Moreover you may link to follow blog :
https://www.redline13.com/blog/
Comparing the two directly is not an apples-to-apples comparison, because they measure different things. Actually, Load Tester measures a lot of the same things for each, but what is generally considered the most important metric – Page Duration – is actually measuring a different aspect of performance in each case.
Virtual Browsers:
Virtual Browsers work at the HTTP layer – they send the same HTTP messages to the server that real browsers would send. The Page Duration measures the time from the beginning of the first request that is sent to the server to the end of the last response for a resource on that page.
Our Virtual Browsers(JMeter) will use the same number of connections to the server as a real browser. And it will distribute the requests amongst those connections in a very similar way: it will use inactive connections first, connections remain open for a while, etc. When done correctly, the target application cannot tell the difference between our Virtual Browser and a human operating a real browser.
Real Browsers:
well, REAL browsers that are driven by our virtual user instead of a human user. The driving takes place via APIs into the browser that are designed for automation (Eg : JMeter Selenium Web Driver)
For example, a Go To URL step instructs the browser to navigate to a URL. The Duration of that step measures from the time the command is sent to the browser until the browser reports completion (or failure). In the case of the Go To URL command, the command is complete when the browser fires the “On Load” event. This step will include the amount of time to get all the resources from the server – which is what is measured by the Virtual Browsers. It will ALSO include the amount of time the browser takes to render the page on the screen, which is not measured by the Virtual Browsers (since they never render the page).
I am developing a multi-user Windows Store client app. The app's main screen displays data that can be updated by users at any time. Any changes made by a user needs to be pushed onto all clients in order to update the data displayed on the main screens of all the other users.
Would Azure's Notification Hubs apply to my scenario? The demos I've seen so far only show the pushing of "toast" notifications. In my case, I need to push notifications to client application code for programmatic processing rather than for direct display to the user.
My client app is programmed in a way that requires an object/relational mapping tool sitting between it and the database. It appears that Azure's Mobile Services includes support for Entity Framework and so can facilitate this. Is it possible to leverage Notification Hubs to achieve the goal of keeping all clients updated with the latest database changes? If so, then how would I accomplish each event in the following sequence?
Inform the mobile service that the database has changed.
Notify all the clients about the changes.
Materialize the changes on each client as objects via the O/R mapper.
I'm working on Arena of little robots, using an AJAX/PHP frontent, Websockets to send commands to an arduino, and the arduino sending IR commands to a robot. The user views the robots via a network camera feed.
Right now, if you go to the website, it's a free for all. There are two robots with separate control buttons, but many people can load the site simultaneously and click buttons, meaning nobody has exclusive control over a robot.
I am not looking to have people register and create a username/password, but I would like to have the site require them to enter a Nickname when they connect. Once they enter a nickname, they can choose to take control of a robot if nobody is waiting, and the controls will be revealed. (If user #2 now want to control that robot, the site will show him that user 1 has control, and he may place his name on the queue. (I imagine i'd give people 45 seconds to a minute of control if others are waiting)
I know my way around PHP and javascript a bit, but I'm not sure how to approach this. Do I need to use a mySQL database to keep track of the queue and lock/unlock status of the controls?
Thanks!
TL/DR I need to create a queue, so two users can't access the same set of buttons on a website at the same time.
I suggest you to use cookies for the "user identification" where you can save a timestamp. This either will unique identify the user and also will give u an idea about the queue of users. If you mind about the cookies hacking, you should encrypt that timestamp.
Using this procedure, you dont need to ask for a nickname neither use databases.
Also you can provide a time window access checking the difference of times between the "cookie timestamp and the "actual time" every time the signal is sent.
This will be my first iOS app with any bit of complexity. I'd like to outline the components and structure to get some feedback before I dive into attempting it.
From the user's perspective, the app monitors the water level of a local lake and receives push notifications when the water level changes a user-specified amount. I think using Parse will be easiest to manage user data and I will attempt a Node.js server-side component on Nodester (I know some basic JS and figure its an good up and coming language to get familiar with). Here's how I see it working...
The user creates an account on the device and specifies a lakeLevelChange amount in which they will receive a push notification. The user's data is pushed to Parse's data mgt.
The server side component will run this program 3-6 times a day:
Pulls a currentLakeLevel via HTTP request
Pulls user data from Parse
Compares the currentLakeLevel to the user specified lakeLevelChange
If the difference is => lakeLevelChange, a push notification HTTP Post request is sent, per user which their specified condition is met
Parse receives POST request and sends a push notification to APNS server
Client receives push notification
It actually doesn't sound terribly complex when its typed out. Is this the proper way of structuring this functionality? Am I missing anything? Suggestions are greatly appreciated!
Bit of a logic problem:
The server side component will run this program 3-6 times a day:
Pulls a currentLakeLevel via HTTP request.
Pulls user data from Parse
Compares the currentLakeLevel to the user specified lakeLevelChange
If the difference is => lakeLevelChange, a push notification HTTP Post request is sent, per user which their specified condition is met
You actually need to store the level at last alert for each user, too. Otherwise incremental changes could creep over your users' threshhold and never trigger an alert.
Imagine if I said I want to be alerted when the level has changed by 6 inches. You then record seven events in which the level rises by an inch each time. At no point did you observe more than 6 inches of change, but the total change is over my threshold for notification, and I probably meant to have you notify me about that.
So when you fire an alert, you need to store the current level, and then on each change event, you compare that to the last level you notified them about.
You're missing the unhappy path. It's the path programmers never travel while programs always travel. Nothing goes the way we plan it so we have to plan for failures. Ask yourself questions like, "What happens when the server powers down for maintenance or outages and misses one or all of its 3-6 scheduled runs?" "Should the missed executions queue up and send out a bunch of missed notifications?" "What happens when the user changes what they specified as lakeLevelChange but the radio is out and/or the server request cannot complete?" "What happens when Parse gets garbage data in or produces garbage date?" Asking just a few of these will steer you towards an optimal design.
I'd like to have something in my app that is just like Twitter but not Twitter. Basically it will be a place people can submit messages and do not need an account. They only way they can submit is through the app. I want other app users to see the submitted messages nearly immediate. I believe push notification can do that sort of work but do I need push notification for this? How does Twitter do it?
-- EDIT --
After reading some of the responses, push might be what I need. People will be submitting messages to my server often. If someone is watching the feed, they might see one new message per minute depending on the query they are using. I'm thinking to go with a MySQL database, (which allows switching to cheaper non Windows servers w/o much hassle) and push notification. Are there any reasons those won't work for my scenario?
You only need push notification if you want the app to be able to receive new messages while closed.
Here's a rough description of one way to do this:
Your app sends a message via HTTP Post to your server.
Your server stores the message in a database, using the iPhones unique ID as an identifier.
Your app connects to the server frequently, asking for new messages.
If there are any new ones, the server hands the message to the app, which displays it.
This is approximately what twitter/iphone twitter apps do.
Your choices are fairly binary:
Use push notification
Use Polling
With Push Notification:
You control when you contact your users... Heavy Load means you can slow updates down to avoid taxing your infrastructure
Contrariwise, you have to push to clients that may not even be there anymore (And thus may need some sort of register model), high load may mean that clients don't get immediate update
You can leverage things like Amazon's EC2 to give you more processing power
Unless you're out of capacity, users are almost certain to be receiving updates as they happen
To pick up messages missed while offline, the SERVER needs to know what message was last successfully received, store older messages and forward many all at once
If you choose to use polling:
You must have a stable address to be polled
You need the ability to have lots of quick query connections checking for new data, then returning that data if required.
If your application becomes popular enough you may find you don't have enough resources
If your resources are taxed your application will go down, rather then just slow down
You don't need to register clients and keep track of their on/offline state
Parallelizing on the fly is a bit trickier
To pick up older messages, the CLIENT needs to know when they last received a message and then request the server send any message since that time
Both can be fast, but they come with different bandwidth and processing profiles. I prefer push for everything that's real-time.
Might want to take a look at XMPP.
Twitter doesn't really push events out to the iPhone in realtime. It's more like polling by the various clients.
If you really want instantaneous for the last mile you'll want to use push.
Twitter uses lots of servers and raid arrays to handle the load of millions of people posting 140 character messages. Twitter clients log in and request a list of updates for all of the people the user is following within a certain time frame.
Push wouldn't be a good candidate for this because it does not persist the "tweets". It is simply a notification mechanism. There is a text messaging app on the App Store (called Ping!) that relies completely on push notification for sending text messages. This seems to work fine, but if the developers are keeping track of the messages, it is all done on their servers. In their case push makes sense as you want to alert the user of a new message. In the case of a twitter clone, however, it would probably just annoy users if they got a new notification every time someone tweeted.
In the end you're better off just implementing it server side and then developing an iPhone client that logs in and retrieves the latest tweets for the people the user is following.