We are currently finishing a web-based time-tracking software built on ASP.NET and WCF (for different desktop-clients). Our customers can register an account and add an unlimited number of users to their account. Pricing is tied to the number of active users in the companys account.
To keep things simple and easily scalable we thought it would be a good architectural decision if we design each account to run as a single IIS-website with it's own application-pool, SQL-Server database and subdomain.
Unfortunately we rapidly run into memory-shortage, due to the fact that a single worker-process will consume at least 150mb, which means that for every single trial-account we need approx. 200mb more of memory...
Beside the heavy costs of such an architecture (trial-accounts!), we are not sure if it was a good decision for scaling, to design the architecture that way.
How would you design such
SAAS-applications?
Single app-pool for many sites?
Single website for many accounts with shared database?
Scaling vertically (more power) over scaling horizontically (more servers)?
Any good books or blogs on this topic?
Thank you!
What are the reasons for creating a new site and application pool for each account?
A single site with a shared database (number 3 in your list) is a much easier solution that can scale much better. You can then scale up the number of web or database servers when needed. This architecture is used in e.g. Sharepoint and most public web sites.
Related
I have implemented an asp.net web site and hosted it in Azure as a Web Role. It is a relatively simple application making use of a database.
I am interested in high availability of the web site, thus I am using scale out feature of the Web Role; instant high usage of the web site is expected (peeks), so I am interested that the scale out operation to be fast.
My question is which is better to use in order to achieve high availability - a Web Role or an Azure Website? I observed that scaling out the Web Role takes sometime (meaning about 10-15 minutes for the virtual machine to be created and started);
Is it supposed the scaling out of the Azure website to be faster?
Is there anywhere on the microsoft's azure documentation mentioned about this?
Thanks.
So, a few general observations that are "as of today". Azure Websites have the following advantages
Azure Websites definately scale much faster. New instance comes up really quickly.
Deployment into Websites is usually simpler and easier
However, from other perspective, Web Roles have more of an advantage when it comes to the following:
You can get alot more control over how scaling occurs, especially if you're using services like AzureWatch. This is because, Web Roles are full blown VM's and one can potentially use any performance counter to input into scaling decisions
Web Roles are not as managed as Websites, and are generally less prone to have "Azure issues". The more managed a service is, the obviously, more possibilities there are to occur some "host-related issues"
So, what this means, is that Websites can execute scale actions faster, but with Webroles you'll know better WHEN to execute them.
Which one is more improtant to you?
HTH
I have three different applications, they all share the ASP.NET membership aspect of the database and almost definitely they won't share anything else.
Should I have a separate database for each of the applications, or would one suffice?
All the application tables are prefixed, so that wouldn't be a problem in integration. Although I was wondering if there would be any performance issues, or if having all three applications share the same database would be some kind of grave mistake.
The applications in question are three web applications, the "main site", a forum and a bug tracker. I'm wondering if this is viable because integration could be easier if I had a single database. For instance, the bug tracker registers asp.net membership tables in it's db connection, and it even creates an "admin" user, where the db that is actually supposed to be holding the membership tables would be the "main site" one.
Update: I added a bounty to this question since the answers seem to have pretty split opinions about whether I should or not use multiple databases for different applications that share only membership providers.
Separate apps = separate databases - unless you have to "squeeze" everything into a single DB (e.g. on a shared web hoster).
Separate databases can be backed up (and restored!) separately.
Separate databases can be distributed onto other servers when needed.
Separate databases can be tweaked individually.
I have always found it would be better to have more databases so that it is easier to:
Migrate to more servers if needed
Manage security / access easier
Easier (and Faster) restores and backups
I would actually go with four databases. A Membership database, and then one for each application (if the membership is truly shared). This will allow you to lock security across applications as well.
Looking at your question closer... You say that the data would "likely not be shared"... will a lot of your queries be joining tables with the membership? If so, might be easier if they are in the same database. However if you are going with a more entity based approach, I would think you would still be better with multiple databases. You might even want to look at something like an LDAP database or some other type of caching for your membership database to speed things up.
You should use the same database unless you have a current need to place them in separate databases - HOWEVER where possible you should architect your system so that you could move the data into a separate database should the need arise.
In practise this means that you should keep SQL procedures working the smallest amount of data possible - i.e. Don't have multi-step stored procs which do lots of separate actions. Have separate usps and call each from code.
Reasons to use separate databases:
1) Unrelated data - Group data that is interrelated - andonce databases get beyond a certain complexity, look to separate out blocks of related data into separate databases in order to simplify.
2) Data that is of either higher importance (e.g. Personal Details) should be separated to allow for greater security measures: e.g. screening this data from developers
3) or lower importance (e.g. Logging Info) - this probably does not need backing up - and if it's particularly volumous, you probably don't want it increasing the time taken to back up the main site database.
4) Used by applications living on different servers at different locations. Quite obviously you want to site data as close as possible to the consuming application.
Without really knowing the size and scale of your system, difficult to give full opinion, if it's just your own site, one db may work for now - if it's commercial then i'd have 4 dbs from the word go: Membership details, Forum, Bug Tracker and MainSite related stuff.
Thus in code you would have a Membership manager which only talks to the Membership db, A BugManager, A ForumManager and anything else will only talk to the MainSite db. I can't think of any reason you'd need any of these databases talking to each other.
Just my inclination: although the three apps might not share much (not yet, anyway: but what happens when a forum post wants to reference a bug report?), they all belong to the same "system," so to speak.
I would definitely put all of the tables in just one database.
In my opinion , it is better to split the database for increased flexibility, security, efficiency, and scalability.
In future if there is any addition of requirement (you never know) which is common to all the three applications , it might be a little difficult to maintain.
For example: User login /audit trace for your 3 applications.
It may sound like I'm wandering a bit, but have you taken into account another possibility, that is separating all the authentication/membership functionality into an application itself?
From your description it seems you may add another application in the future. It would start to look like a network of sites, much like 37signals web apps, Google web apps or MSN web apps.
And thus, you may go for a kind of Single-Sign-On / Connect service. This one single application may offer authentication methods via web-services or any other mechanisms, it will have its own DB for you to tweak, modify, backup and move without affecting the other apps. I myself have found this situation many times and thus I love how easy is to share your Google or Facebook login among applications.
Perhaps I'm seeing it from a little higher perspective than yours, sorry if it's the case. If this is not an option, you may keep 4 databases: 1 for each application and 1 for the membership provider, which has its own connectionstring most of the time.
Of course it depends on the size of your applications' footprint on DB-level. 10 tables per app is OK, 150 tables per app would make the DB a little ugly to us, that being a personal preference.
Good luck with whatever option you choose.
The membership framework allows for partitioning across multiple applications, so you probably should have the following configuration:
Membership Database
Application 1 Database
Application 2 Database
Application 3 Database
Then, in each of the application databases, create synonyms that point to the membership database's tables for when you need to write your own queries that access both application data and membership data. Synonyms are easy to maintain and allow you change where the database is without changing any dependencies on those tables as the synonym names don't change.
Your application configuration in Web.config will determine how the data is partitioned in the membership database as you specify an ApplicationName that should be different for each app.
I was reading this article Build Your First Cloud Application Using Visual Studio 2010 when It hit me:
Why would I switch from my normal
hosting (shared account, VPS, or
whatever) to host it on cloud
servers ?
Do I have to build my website with
ASP.NET Cloud Application to be able
to host it with any cloud providing
service company ?
How can I edit my ASP.NET Web
Application to be an ASP.NET Cloud
Application ?
Those are the questions I thought would help to gather a full picture about this new technology and it's own application template! but please feel free to add more points to consider in the answers.
Edit
so beside the difference in implementing a website between Azure and other cloud server
is there is a performance difference or any other differences between Azure and the other cloud servers ?
I didn't quite get what you meant by "bringing your app on site with your own staff may become more economical"
the Azure pricing are high and requires a whole new dedicated project to work with it restrictions. so both the hosting and the development are costy
I hope if there's any article about the good cloud hosting out there and perhaps any articles about the user experience (a legitimate review and maybe yours if you have any)
First, I believe "cloud" in the context of the blog article you read should really be more granularly defined as Azure. There are several cloud solution offerings and Azure is only one although it is gaining immense popularity in the MS community space. The Azure cloud is fairly unique compared to products like Amazon's cloud in that it requires applications that use it to comply to a specific set of APIs. To build an application for azure requires you to embrace certain architectural principles from the beginning and to build your app using its web and worker roles. To "fit in" to these roles, your app must be built within a special VS project that references the Azure SDK.
If you were to use another cloud solution like Amazon, it is more similar to firing up a VM or group of VMs that can host your app as is without the constraints of specific APIs. You simplu would fire up a windows server instance, install what you need on it like any other server you would use in a hosted or or leased data center environment.
I am not implying that the azure solution is flawed or overly restrictive. Rather, I think it supports some architectural constraints that will allow you to "fall into the pit of success." However, it may be difficult to effortlessly migrate many brown field apps to azure without making significant changes.
As far as why host a application in the cloud as opposed to a normal hosted environment. It really depends on your app, your business/budget constraints and your traffic level. For many small, hobby sites, you may be better off keeping your app on a traditional hosted environment. For larger scale apps, the cloud begins to make more sense. The cloud is really supporting a "pay per use" model. If you need to have the ability to scale out quickly without the funds or the ability to wait on a purchase of lots of additional hardware, the cloud is a good option. Cloud providers have deep pockets and plenty of server resources and bandwidth to send your way at a moments notice that you can rent instead of buy.
Also, because cloud providers are large and typically highly reputable, they can afford to hire expert staff and follow best practices that you may not be able to afford on your own. They can and will handle a lot of the day to day ops administration enabling you as a developer to not have to think of things like security and redundancy.
So as I see it, cloud solutions are ideal for apps that are beginning to see a fair amount of traffic, need guaranteed up time, and do not want to pay or bother themselves with their own admin staff, server purchasing and data center management. I think they are not practical for many small hobby sites and once you become really big, bringing your app on site with your own staff may become more economical.
That all said. it has become "cool" in the .net space for any site to run on azure. I'll admit that some of the architectural models are interesting and seem fun to work with. However, if you take a close look at the pricing model, you may find you are better off with your hosted plan.
Moving your .NET application to a cloud or hybrid infrastructure allows you to start evolving to a Microservices Architecture, with the ability to phase in Containers and a Serverless architecture.
You mentioned that Azure costs are high and maybe cumbersome in your situation.
Maybe consider other popular cloud providers like AWS. They have a ton of vendors and services all readily available to help make the adoption easy, in fact over 57% of Windows workloads currently run on AWS.
Here is an eBook we recently published about this exact topic.
I am on a project helping to analyze the load a VB.Net WinForms application can take. This app has been in production for several years and has many many products on it. We plan to add more products but see the client footprint rapidly increasing. This is contributing the degradation of performance on the system overall.
There is duscussion that moving the UI intensive portions of the app to ASP.Net it will reduce the client footprint and solve many of our issues.
My question which of the following will scale better in terms of performance and load?
- ASP.Net(VB) Web based architecture
- VB.NEt WinForms 3-tier architecture
Links to articles on the topic are also appreciated.
Additional Info
Client - Apparent issue is large memory footprint due to data caching (High cph utilization)
Middle Tier - web services that house BLC & DALC assemblies (Low utilization here)
Database - Multiple database that that serve data to the DALC via sprocs (Medium Utilization)
Deployment is not an issue, we have a very well developent methodology there.
Thanks in advance,
Freeon
Winforms will scale better than ASP.NET
B/c
a. when you use an ASP.NET client - (a Browser) you pay a price, html rendering - another price, Viewstate - a huge price.
about view state - it is a chunk of data that might grow more and more as long as you operate even on the same page.
You need to use special techniques in order to make a asp.net webform efficient (AJAX).
You don't have this on winform.
Anyway - a specific answer should be aware of your product functionality, architecture and design, so this is gust a general advice.
Not enough data...
In terms of a user interface a desktop application should out perform (by various measures) a web based one in all but the most trivial of cases - that's not to say that you can't produce a very decent and capable web application but even then Outlook Web Access is not Outlook on the desktop.
To further illustrate the point, look at the effort going into Silverlight and Adobe AIR which are attempts to provide desktop level capabilites with web level deployment.
So the question becomes one of asking what is it in the current desktop application that is causing the problem i.e. is it a deployment issue, a performance issue or something else?
If its deployment issue then that will suggest one set of solutions, if its a performance issue then things get a lot more interesting.
Either way, there is insufficient data to do anything other than generalise enthusiastically
With a web based application you can scale servers both up and out for both the web server itself and the database servers. I would think that a desktop based application would be somewhat limited in how much scaling can be done, along with the need to update each and every client installation when changes/bug fixes are done.
There are negatives about web based applications. They will live in a stateless enviroment, the UI maybe somewhat slower than a desktop installation. It is possible to create UI's that are very responsive using lots of Ajax/Javascript, but the development time for those RIA needs may be more than desktop development. Connectivity issues maybe be of a concern, along with user browsers and such.
Quick deployment though of updates is one huge benefit of a web based application. You only have to manage one installation rather than many.
Good luck with your project!
The application is planned to be built using ASP.NET, .NET Remoting & MS SQL Server.
High availability is required at presentation layer, application layer and database.
Does IIS 7.0 provide any advantages over IIS 6.0 in regard to the High availability aspect?
Among the many aspects you want to consider, make sure that you have numbers.
By numbers, I mean how many request per second do you want to deliver? How many users per day are you planning? Are they all going to come in 1 hour or through out the day? Are they simply buying stuff on a e-Commerce website or is it a social network website with lots of pictures and videos?
All those questions matters in how you will architecture your website. If you go with a simple e-Commerce website that should not crash, make sure to have 2 servers with load balancing with some health monitoring on the IIS process. For the database, 1 machine will do the trick especially if you have some RAID hard drives.
However, if you go toward a social network site... things get freaky fast. If users upload pictures, you will need lots of space and much more if they upload videos. You might want to use Cloud Service to host those pictures without too much fees. For videos, you might want to use embeded link like Youtube or Google video.
As for IIS 7.0 versus IIS 6.0, I don't think there will be any significant changes. Both are really reliable.
Take a look at the High Scalability Blog
Make sure your design scales in a horizontal manner.
That is, have your system hiding behind a load balance layer with the servers that are actually providing the service behind the load balance layer.
When you need to increase capacity, you build a new server or servers and plug it in alongside the existing servers. Then you configure the load balance layer to also consider the new server(s) when passing out the work.