I have a public web application and need to know (for statistics) how many simultaneous executions occurs. An example would be the equivalent of how many visitors are on a web page or how many users are connected into DB.
I think one way to achieve this is by registering users in a DB on Internet and count the records periodically. The problem with this, if the application loses connection to the Web or the OS crash, the application not send the code to subtract the count, giving false positives.
Please if you can give me a starting point to made this code.
Regards Amigos
Related
I have a web application that displays inventory, orders, tracking information from drop-shippers for orders and tracking updates. When a customer logs in, he will see all the above information in different pages.
I have a Console based application in the server that hosts 4 background workers to do each of the above tasks and updates the database. Now i have one console application for each customer. I did this because for any reason the console application fails because of one customer's data, it should not effect others.
Is there a better approach or any existing tools, api, frameworks available to support this kind of stack in Microsoft? Or what i am doing is correct and best approach? Are there any technologies that are more stable to support Subscription based membership, Offline data sync, Queue User requests and notifying user when they are completed.
I would take a look at the Azure Queues and Webjobs (Links below)
With a queue structure, you can simply decouple your application and make the application only do what is needed. Your main application can then just put relevant and needed information in the Queue and forget about it.
Next (and perhaps the most crucial part of this) you can write a simple console application that will run when a queue is present and ready. The beauty of this is that you not only can have multiple webjobs doing the same thing (I don't recommend it) but also, you only need to have and maintain one Console application. If the application crashes, it will simply restart it again (within a few seconds) and go back at it again.
Below, please find a link to the tutorial of how to make a sample Queue and Webjob:
http://azure.microsoft.com/en-us/documentation/articles/websites-dotnet-webjobs-sdk-get-started/?rnd=1
I am somehow familiar with benchmarking/stress testing traditional web application and I find it relatively easy to start estimating maximum load for it. With tools I am familiar (Apache ab, Apache JMeter) I can get a rough estimate of the number of request/second a server with a standard app can handle. I can come up with user story, create a list of page I would like to check and benchmark them separately. A lot of information can be found on the internet how to go from novice like me to a master.
But in my opinion a lot of things is different when benchmarking single page application. The main entry point is the most expensive request, because the user loads majority of things needed for proper app experience (or at least in my app it is this way). After it navigation to other places is just ajax request, waiting for json, templating. So time to window load is not important anymore.
To add problems to this, I was not able to find any resources how people do it properly.
In my particular case I have a SPA written with knockout, and sitting on apache server (most probably this is irrelevant). I would like to have rough estimate how many users can my app on the particular server handle. I am not looking for a tool recommendation (also it would be nice), I am looking for experienced person to share his insight about benchmarking process.
I suggest you to test this application just like you would test any other web application, as you said - identify the common use cases, prepare scripts for them, run in the appropriate mix and analyze the results.
Web-applications can break in many different ways for different reasons. You are speculating that the first page load is heavy and the rest is just small ajax. From experience I can tell you that this is sometimes misleading - for example, you can find that the heavy page is coming from cache and the server is not working hard for it, but a small ajax response requires a lot of computing power or long running database query or has some locking in the code that cause it to break or be slow under load - that's why we do load testing.
You can do this with any load testing tool, ideally one that can handle those types of script with many dynamic values. My personal preference is WebLOAD by RadView
I am dealing with similar scenario, SPA application where first page loads and there after everything is done by just requesting for other html pages and/or web service calls to get the data.
My goal is to stress test the web server and DB server.
My solution is to just create request for those html pages(very low performance issue, IMO, since they are static and they can be cached for a very long time in the browser) and web service call requests. Biggest load will come from the request for data/processing via the web service call requests.
Capture all the requests for html and web service calls using a tool like fiddler, and use any load test tools(like JMeter) to run these requests using as many virtual users as you want to test your application with.
I have the requirement to close the application after 10 minutes if the user has not interacted with the application.
All the questions about this are related to the session time out, the problem here is that the application has no security and is a requirement to run it without connectivity.
Any idea about how to implement this?
Thank you.
First of all, as I mentioned in the comments above, this is a really bad user experience. You should tell your customer you just don't do something like this to your users. never.
If I understand you correctly, the application is running offline, meaning it does not connect to the Worklight Server...
So you should probably just maintain some counter... if the user does any action in the application (touch a button, whatever), reset it. If no action was done and 10 minutes have passed, called WL.App.close.
Please note that using WL.App.close in such a manner in iOS can make your application be rejected from the App Store if found.
We are extremely new to ASP.net...actually working with an outside consultant which I don't currently have access to.
I am looking for:
Good documentation/best practices for session and session management.
I'm finding some info now:
http://support.microsoft.com/kb/317604
Review of application below for comments about how to best handle this scenario.
We have the following scenario:
OEM machine on floor providing status UPDATES every x.x seconds to Device_Status table.
When ASP.net client/user wants to view status of a particular machine, I want to notify the OEM machine on the floor to increase update rate to near real-time. Potentially with "realtimeupdate" flag in Device_Status table.
When ASP.net client/user moves on or logs out, update rate needs to return to x.x seconds.
Since we are very new to ASP.net, we don't have any clue about sessions and session management or if it is possible.
The only problem I see so far is if the ASP.net client connection is terminated prior to setting the "realtimeupdate" flag to 0. If this happens, the OEM machine will continue to provide real-time updates when they are no longer needed.
you can't count on a browser (or the user) to say "hey I'm done". People walk away from thr PC, surf to stackoverflow.com, hit the X to close the browser, etc. you'll need to code your web page to request "live" frequency with every page refresh. and have some independent server process turn off the "live" frequency if you don't get a page refresh asking for "live" frequency after some set amount of time. In addition to your page turning it off if the user asks for that.
When facebook rolls out a new version of their site, they show it to a percentage of users first.
How could I go about doing this cleanly?
Have your users sign up for your Beta.
Select a certain percentage of those who sign up for your Beta. As you make changes, keep incrementally adding some more testers. You don't want to let everyone in at once so you can get testing all the way up until the feature is complete and released. Look at stackoverflow as an example.
You would do this because most of the people who sign up will check out your beta version, then leave. They most likely will not come back / keep testing for you.
It is also better to opt-in than opt-out. Your users may not want to be your test subjects.
With a proxy that diverts some fraction of the sessions to one of two separate running instances. The proxy can be a software proxy on the hosting machine.
Well, depending on the change, if you have a farm of web servers you could apply the change to only some of the servers in the farm. That way only certain users who were "lucky" enough to hit one of the updated servers would see the change. Of course, this approach assumes that your web proxy will always route any given user to the same server (or group of updated servers) in the farm.