Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
What would be a good way to restrict an ASP.NET web application to only serve a given ammount of concurrent users?
Some requirements are:
Application requires login (no need to worry about anonymous users).
Multiple servers support (farm / load balancing).
An active user can be considered to be the same as an active session (not signed off or expired).
Additional logins must be denied if the maximum number of concurrent users has been reached.
Accountability is needed (administrators should be able to see who the active users are).
Minimum overhead on each web request (especially avoiding costly trips to a database on each request).
Total number of concurrent users should be kept correct even if a web server hangs, disconnects from network or has to be restarted.
Additional servers are available to host services (e.g. application servers).
You could use a global variable (static) and hook up the logic in your Application_OnStart, Application_BeginRequest, or Page_Load events. Check out this for more an example: http://dotnetperls.com/global-variables-aspnet
To restrict the number of concurrent users you should be able to use,
<system.web>
<applicationPool maxConcurrentRequestsPerCPU="12" maxConcurrentThreadsPerCPU="0" requestQueueLimit="5000"/>
</system.web>
http://blogs.msdn.com/b/rakkimk/archive/2009/07/08/iis7-improving-asp-net-performance-concurrent-requests-while-on-integrated-mode.aspx
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
It's considered good practice to remove listeners from Firebase databases (whether that be Cloud Firestore or Realtime Database) when the listening components are unmounted.
In a lot of applications, mine included (React Native app), this might not happen very often.
For example, when my user is authenticated (signed in), they are subscribed to a number of listeners on both RTDB and CFS. Things like notifications and messages and other "realtime" updates i want them to see app-wide - think notification "badges" for example or "unread messages".
Developers of Native applications will know that apps can remain "backgrounded" for long periods of time. And with auth refreshing, users will rarely log out of my application. This means that those components are never (or rarely) unmounted and thus, remain subscribed to updates - i think.
Should i be adding logic that removes those subscribers to realtime data when a user backgrounds the application, only to re-instate them when they foreground again?
What you're asking is primarily a matter of opinion, which is off-topic for Stack Overflow. That said, you should probably take some time to understand the ramifications of leaving listeners added indefinitely.
A listener that's not removed when the user isn't looking at your app still incurs the cost of downloading updates to the documents it's listening to. Whether or not that's acceptable is entirely up to you.
The host OS will likely throttle the network access of app that can't be seen by the user after some time. This is for the benefit of the user, so poorly implemented apps don't consume excess network and battery. You can't depend on these listeners to work properly when this happens. If you want listeners to stay active while the app isn't visible, you will need to tell the host OS what you want using whatever APIs it provides. Even then, you don't have any guarantees, as the OS may simply kill an invisible app in order to reclaims resources.
You will have to decide for yourself when it makes sense add and remove listeners, after you understand the behavior apps on the given OS.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
My App resubscribes whenever there is a connection loss.
I fear this causes a lot of traffic.
Is all data resend on every subscription?
And how can I monitor this traffic?
(I tried Kadira but could not find a traffic amount tab)
To avoid this kind of traffic, you should try iron-router and manage subscriptions for every template/page. This way you subscribe only to data client needs and also in case of reconnect, the usage is no different from refreshing or changing page.
In case you have a one-page app, you should publish only an amount of data user can process at the moment and increase it in case he needs more.
Kadira Debug is really good for monitoring your app, you can monitor query response time, query rate, memory usage etc. Even if that's not exactly what you're looking for, that's for sure a good place to start to see how your app connects with your db.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I write a phrase and please you say your point of view about it:
For my web site,If My Server Is Secure(Server Admin warranty that) and I prevent XSS and Sql Injenction attack,Is my web site secure?
(please leave your answer with reference)
Thanks
Edit 1 ::
every of above items + Cross-site request forgery
Firstly, don't expect to obtain a "secure" end state as if it's an absolute position - you can't. Software security is about reducing risk and you won't ever reach a position of no risk.
There are many, many other risks you've missed: broken authentication and session management, insecure direct object references, security misconfiguration, insecure cryptographic storage, failure to restrict URL access, insufficient transport layer protection and unvalidated redirects and forwards to name a few. These are all out of the OWASP Top 10 and I suggest you start with these.
Make sure you understand:
The risk
How it's exploited
How you can protect against it
If you'd like to see all this in the context of ASP.NET have a read through the OWASP Top 10 for .NET developers series.
And thee are risks beyond these top 10 too, they're just the most common ones in web apps.
No. There are other attack methods. For example, http://en.wikipedia.org/wiki/Cross-site_request_forgery
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I'm working on a Web project using Asp.Net MVC, which I'll have to deploy to a farm environment.
I've read a lot of articles and I'm thinking on disabling completely the SessionState, I think this would make a more robust application, and will save me a couple of headaches (Everything I've read tells me that handling sessions on a farm isn't trivial).
There are some things that I still don't have totally clear with this approach though, the main one being the authentication/authorization process. Basically I'm not sure of how (if?) I can handle user sessions if there's no SessionState enabled on the server.
If a user logs into the web site and then tries to access another page, how can I know that the user is already logged in?
I know using cookies is insecure, I thought of a mix of cookies with the session Id stored in the DB, but I suppose that if I disable SessionState I won't have access to the session id either.
What's the best approach on this? Is there any recommended book/article you can point me to so I can get this clear?
Thanks a lot for your help
I think use Forms Authentication for this this will be manage your logged in user name and you can also set authorization through this.
http://msdn.microsoft.com/en-us/library/ff647070.aspx
http://msdn.microsoft.com/en-us/library/xdt4thhy.aspx
http://www.codeproject.com/KB/web-security/formsroleauth.aspx
http://www.beansoftware.com/ASP.NET-Tutorials/Forms-Authentication-Active-Directory.aspx
These links are ans of your each question. Through this you can manage role authorization and session
It may be possible that if there are workflows that your application supports that you want to persist over application recycling (cluster node failure) you may be able to ignore the persistent Session complexities completely.
Consider an ecommerce checkout example or a similar multi-step process that requires a lot of state management before completion. The suggestion is to design the model of your application is such a way that during these "steps" the progress of the workslow is persisted to the data store natively though the model. That is, the "workfolow" is not some sort of externality to the main model of your app and as such treated as a "temporary" thing that requires some persistence mechanism like the aspnet Session as opposed to the apps regular data store (database).
For example, rather than storing the checkout object tree (lists of items, orders, etc) in Session, persist it to the database itself. This way not only does that "partially completed checkout" survive node failure or application recycling but additionally, if that user has to go put out an urgent fire in the kitchen or their Windows Update crashes their PC, they can resume when they log in next. :D
And: you avoid all that complex distributed session management stuff. Yuk!
I know this answer extends further than just the authentication point that the question actually highlights, but this is good to know and certainly a problem clustered/farm environments place on aspnet apps.
Hanselman on clustered mvc apps: http://www.hanselman.com/blog/LoadBalancingAndASPNET.aspx
FormsAuthentication and the ASP.NET user profile work without SessionState enabled--they run on cookies and database lookups by default.
For shopping cart-type scenarios I'd strongly consider just saving the data in the database and tagging users -- it lets people come back and grab abandoned carts.
What can and will break without the SessionState enabled is MVC's TempData -- it stashes things in the session between pages. But, if you just avoid using it, you are golden.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I need to create a web application for tasks delegation, monitor and generate reports for a organization.
I am thinking about ASP.Net and MVC should be the architecture to support so many concurrent users. Is there any other better architecture that I should be looking for ?
What kind of server configuration will require to hold this application ?
How do I test so many users connected before I launch this application, is there any free/economical testing tools available ?
Thanks in advance.
anil
the choice of MVC versus webforms have little/nothing to do with the ability for the app to handle load. Your problems will be reading/writing to the DB, and that doesn't change no matter which of the two you choose.
ideas for improving ability to handle load:
first and foremost: absolute minimum is two servers: web server and DB server, they should NEVER run on the same box.
DB:
Efficient queries towards the DB, indexes in the DB, denormalizing tables that are hit a lot, CACHE, CACHE CACHE, running the DB in a cluster, oh, and did I mention CACHING?
Processing:
if you need heavy processing, do this in web services that can run on separate machines from the web servers so that you can scale out (buy more servers and put them behind a load balancer if needed)
WEB:
avoid the need for server affinity (so that it doesn't matter which web server serves a given user at any given time) this means using DB or StateServer to store sessions, syncing the MachineKey on the servers.
the decision of using MVC or not have NO impact on the ability to handle 10k concurrent users, however it's a HUGE benefit to use MVC if you want the site to be unit-testable
remember: Applications are either testable or detestable, your choice
Cache Cache Cache Cache :-) a smart caching policy will make even one server go a long way ... aside from that, you will need to find out where your bottleneck will be. If your application is database heavy, then you will need to consider scaling your database either by clustering, or sharding. If you expect your web server to be the bottleneck (for example if you are doing a lot of processing, like image processing or something), then you can put a load balancer to distribute requests between N number of servers in your webfarm.
For a setup this large I would highly recommend using a Distributed memory caching provider to be layered above your database. I would also really suggest using an ORM that has built in support for the memory cache, like NHibernate since in an application of this scale your biggest bottleneck will definitely be your database.
You will most likely need a webfarm for this scenario, if a single server is strong enough for it currently at some point in the near future you will most likely out grow a single box which is why it's important to architect in the distributed cache first so you can grow your farm out and not have to re-architect your entire system.