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 9 years ago.
Improve this question
I know this sound confusing.. so I am trying to be as brief as possible.
I have a main web with an ASP.NET 4 classic app pool on a windows server 2008 R2; within this website there is a sub folder that contains all the admin functionality of this site; the main developer decided to convert this sub folder into another ASP.NET 4 classic app pool.
so basically I have the main folder converted to an application and a sub folder also converted into an application.
So far we did not had any issues, however I am not convinced that this solution is an optimal one.
I would like to know your ideas on this.
There are lots of reasons to separate out applications into their own app pools. For one when you have a separate app pool a new W3WP process is spun up, meaning that in some cases it can give you better performance. The new process will also have it's own allocation of memory, so overwriting cache entries for example will not interfere with cache entries on your main site (this could also be bad). Finally and most importantly if your app pool on admin crashes it will not affect the main app pool for your customers. In a lot of cases the app administrative sections are the most likely to fail since they contain so much functionality (but that's not with all cases).
All those good things above can also have negative effects. For example you may want to force expiration of a cache item from the administrative application to the front end portion of the site, this is now going to be more difficult. Also these applications should be split up now in visual studio as two separate applications otherwise deployment will be quirky (both have to use items in the same bin folder). If it's a subdirectory (as you had mentioned) then you'll need to turn of web.config inheritance otherwise you'll get all sorts of problems. Check out this question on how to do that
Avoid web.config inheritance in child web application using inheritInChildApplications
I personally do think in some cases splitting the app pool for an administrative section can be beneficial but that depends on the application itself, you will have to look at your own application and make that decision.
I would not recommend this approach after experiencing it first hand.
Not long ago I developed some new functionality in a large web application which required adding a new HttpModule and the corresponding web.config entry. A short time after the live release we received a phone call stating an application that we don't maintain and I had no idea of was broken.
The cause was my web.config setting requiring this new HttpModule which the sub-application didn't have, therefore it crashed, troubleshooting and mitigating this issue took time and effort.
The next time I wanted to upgrade our application from .NET 3.5 to .NET 4, and we had to confirm that their app would be OK after we upgraded our application, which again took time and effort.
Long story short, it takes minutes if not seconds to create a new app pool and setup an app, it takes excessive time and effort to coordinate these changes for an architecture that simply isn't necessary or beneficial.
Related
This question already has answers here:
ASP.NET Web Site or ASP.NET Web Application?
(25 answers)
Closed 9 years ago.
I've read a lot of discussions about web site vs web applications in asp.net
The way we work in my team (10 programmers), we use the project type "web site", and for our dev environment, we just copy the source code (aspx + .cs) to the server. This way, all the programmers can be doing changes at the same time.. and the server does the build dynamically. .....(for the prod environment, they build the application)
Now, I'm starting a new project, and I decided to use web application (the main reason was the web config transform option).. I soon realized that (as far as I know) it forces you to do a build/publish of the web app to the server with every change... which is not a big problem if I'm the only one working on this project...
But, now I'm wondering, what's going to happen if more programmers needs to work on this new project at the same time?
Any advise or similar situation?
EDIT
we're using Visual Source Safe... but only for keeping track of the older versions (not for builds)... I'm familiar with Subversion... but.. unfortunately, I don't take the decision on what we should use.. and I don't think they're willing to change
Thanks everyone for your answers...
Anytime I hear the, this isn't a big problem as long as. . . . immediately tells me, that I should assume that it will be a problem. In short, go with what you know. If you are familiar with using the ASP.NET website, then I would use that. Your development practices are already focused around handling that.
This is the same model that I used when doing classic ASP when I first started programming at a company. This model works, although I would strongly suggest getting source control too. That being said, here is what I would do long term:
Source control
Develop locally
Get a continous build process going (cruise control is a free one).
Have one person push everyone's changes to the development server, once everyone agrees that all the changes are compatible with each other. (normally this is done by making sure the build server can compile everything).
If you choose to use web application and add more programmers on the project, I recommend using source control. Git and Subversion are very popular. In Git, for example, you can see who commits what.
Of course, I would use source control from the get-go, whether you're on your own or collaborating with a group.
As #edmastermind29 said source control is really the #1 thing to keep that straight if you are having more then 1 developer.
It really depends on your development process. Most shops do some type of continuous integration and have unit tests running and have some sort of automated build process.
I have found that using a web application project is really the best for all the "best practice" types of things.
Check out this link for some guidance.
It really depends on how your team works, and how your environment is configured. Regardless though, you need to have some sort of source control system in place to ensure that your not overwriting each other's changes. If you don't already have a source control system in place, stop now and get one immediately.
Depending on which source control system you choose, you will at least have the basic checkin/checkout features that serve as a library for your code base; meaning if I have a file checked out you can't touch it until I've checked it back in.
If you choose a more feature-rich source control system, you should be able to take advantage of features like branching and shelving, which will allow your team to work on the same files simultaneously, and merge the changes when the files are checked in.
While your question is about web sites vs. web applications, the answer is source control. With a good source control system in place, your question becomes more or less irrelevant, aside from needing to coordinate builds with a web application.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'm evaluating MS cloud Windows Azure for hosting 3 completely separated websites.
Every website has its own database and they are not connected, so 3 websites and 3 databases.
My aim is to optimize costs for a start-up project with the possibility to scale up on demand.
I would like to know:
If is possible to host 3 websites on the same instance (Extra small instance or Small instance).
if is possible to host 3 databases on the same Sql Azure database (so I would use the total amount of SQL storage for my 3 databases) or for each website database I have to pay an instance of SQL Azure.
Thanks for your time on this.
You can absolutely run multiple web sites on the same instance, starting with SDK 1.3, as full IIS is now running in Web Roles. As Jonathan pointed out with the MSDN article link, you can set up the Sites element to define each website. You should also check out the Windows Azure Platform Training Kit, which has a lab specifically around building a multi-site web role.
You can also take advantage of something like Cloud Ninja or Windows Azure Accelerator for Web Roles, which provides a multi-tenant solution that you can load into your Web Role (check out the Cloud Cover Show video here for more info).
When hosting multiple websites, remember that they're all sharing the same resources on an instance. So you might find that an Extra Small instance won't meet your performance needs (it's limited to 768MB RAM and approx. 5Mbps bandwidth). I think you'll be fine with Small instances and scaling out as you need to handle more traffic.
For the past several months, I've been running three websites on a pair of extra small instances, including albahari.com, linqpad.net and the LINQPad licensing server (which uses LINQ to SQL). The trick is to serve large static content directly from blob storage so that it's not subject to the 5MBit/second I/O bandwidth restriction. And I've never got anywhere close to running out of memory.
A pair of extra small Azure instances is a great alternative to shared hosting when you need better reliability, security and performance.
Edit: close to a year now, still no problems with multiple websites on Azure. I will never go back to shared hosting.
You can definitely run 3 websites in the same instance. Check out this MSDN article that shows you how to form your configuration file such that you can host multiple websites within a single role. One thing to note though since you mentioned "scaling on demand" - when you scale an instance with multiple websites, you are scaling the instance, which means all of the sites will scale together. You can't scale just one of the sites on the shared instance.
For the databases, in theory this can be done, but it would be "manual" in that you would have to all of your tables across the three databsaes in the same database and you would probably want to prefix them with some sort of indicator so that you know which table belongs to which application. This is certainly not a recommended practice, but if it works for your solution, then there is nothing technical preventing you from doing it. If at all possible, I would recommend multiple databases.
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 are different ways that we can do some optimum level of stress testing for asp.net application before moving it to the production environment ?
Here is the free tool for the stress testing in asp.net application.
https://learn.microsoft.com/en-us/archive/blogs/alikl/stress-test-asp-net-web-application-with-free-wcat-tool
Another is called asp.net performance engineering which will tell how we can stress application.
https://learn.microsoft.com/en-us/archive/blogs/alikl/asp-net-performance-engineering-stress-test-your-architecture-design-and-code
Also go through the following post:
Best way to stress test a website
From my experience before moving to the production environment please take of following things.
set debug=false into the web.config
set trace enabled=false into the web.config
Always use precompiled version of your code.
Compile your project into the release mode.
Publish your code if you are using asp.net 2.0 or higher version
User caching api as much as possible.
Decrease your html kb.
remove blank spaces from the asp.net html code.
Use stylesheet as external .css file
USE IIS Compression if poosible.
Put your javascript file in .js files
Use Server.Transfer instead of Response.redirect
Use Inproc Session State if possible.
Use Viewstate efficiently- Use controlstate instead of viewstate which is newer feature in asp.net 2.0
Avoid giving big name to controls it will increase your html kb.
Use Div instead of tables it will decrease your size.
Do IIS Performance tuning as per your requirement
Here is the good link that teaches us good way of deployment in production environment.
http://www.vbdotnetheaven.com/UploadFile/dsdaf/111222006014732AM/1.aspx
Apache JMeter (http://jmeter.apache.org/) is an excellent tool for stress-testing web applications. It can be used with any web server, not just Apache.
Visual Studio 2010 provides some fantastic Test Automation tools and also for Load Testing the web applications.
This question already has answers here:
Pros and cons of having dedicated application pools over keeping web applications in one default app pool
(5 answers)
Closed 3 years ago.
On an server running multiple ASP.NET sites, is it better to use one application pool per site or for sites to share a single application pool? What are the advantages or disadvantages inherent to each setup? Or is there a hard and fast rule here?
This really depends on what the requirements are of the site, as well as your concern regarding risks.
When two applications run inside the same application pool they have the same security level, so there is a security concern here for some as in theory each could have access to files of the other. Also, if one site starts having issues and using memory it could cause recycles or freezes that could impact both.
Although there is not a "hard and fast" rule to this, some of the things that I consider and that cause "automatic" decisions for me are the following.
Is the application mission critical? (If so, separate app pool)
Is this a third party application? (If so, and unsure of what all it does, separate app pool)
Will this application see major spikes in activity? (If so, it might be best to isolate)
There is a lot out there, but the keys are isolation and ability to troubleshoot single applications. Here is a Microsoft article that touches on it a bit as well.
One of the advantages of separate AppPools is that in the event that you need to recycle the AppPool you can do so for one site without affecting the performance (or caching) of the others.
One critical rule to remember:
DO NOT put .Net 1.1 and .Net 2.0 applications in the same application pool. It will mess things up really fast.
It would depend a lot on if certain sites need more reliability than others, what your expected load per site is, etc.
Sharing a pool will be more efficient in general, but a single misbehaving application can more rapidly cause problems for other sites. Additionally you can recycle or update separate app pools separately which may make maintenance schedules easier.
There's no hard and fast rule. I tend to use one app pool per site (and IIS7 even defaults to creating one per site) because I like to play it safe in case I have a memory leak in one site/pool, I don't want it affecting and taking down other sites. But I've also got some servers where 100 sites share a single pool without issue. So, as always, it depends.
I would strongy prefer single application - single application pool - unles you have performance concerns. An exception in background thread (once someone starts playing async) can bring down the whole app pool. And unless you have automatic recycling enabled this may cause lot of trouble.
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 7 years ago.
Improve this question
I am tasked with moving quite a few web apps including the databases to new servers, they are ASP.NET. I was not the one to create and setup these originally so I must try to figure out what exactly I need to replicate in order to not break anything and so the customers have no idea that anything was moved.
Does anyone have any tips for this, or know any automated ways?
Is there any software that can help with this?
I know the web app sends emails, so I will need to setup SMTP and it connects to a database so that I also will need to move. I suppose I should do this at night and take down the servers so I can move the database at it's latest state...
Any tips or tricks?
This might help: IIS 6.0 Migration Tool
"The Internet Information Services 6.0
Migration Tool is a command line tool
that automates several of the steps
needed to move a Web application from
IIS 4.0, IIS 5.0 or IIS 6.0 to a clean
installation of Internet Information
Services (IIS) 6.0 and Windows Server
2003.
The tool transfers configuration data,
Web site content, and application
settings to a new IIS 6.0 server if
desired, or can move just application
settings using the copy functionality.
"
I don't think it will help with the database migration, though.
Here's a link to more detailed information about using the tool.
May I suggest setting up the new servers in a staging environment. Allow business users to verify the functionality in the staging environment before flipping the switch and going live. Once you are ready, then bring over a fresh copy of the data. As far as the emails go... you should be fine with ASP.NET but some classic ASP programs require COM components in order to send email.
The route I've taken in the past is to do a live/current copy (whatever that entails) of $CURRENT_SERVER to $NEW_SERVER. If the DB is not moving, just make sure $NEW_SERVER can reach $DB_SERVER, and that it will continue to run once copied.
Then update DNS to point to $NEW_SERVER.
After some period of time (2-3x the TTL for the DNS record), remove the old server.
We just went through the same thing--bought a new server and had to transfer ASP.NET sites + Databases to the new server. We experienced problems with the IIS Migration tool, so we followed a "staging environment" approach, as stated in Berkshire's answer and had much success. When all issues are cleared from the staging environment, you can make it "live" with much confidence.
One other thing to watch out for is that you'll have to skim the ASP & VB/C# code for any hard-keyed connection strings to the database. These will have to change to reference the new location of the database.