I have one ASP.NET website having following associated components
ASP.NET framework 3.5
MS Chart
AJAX Components
Connection with external webservice for data
Oracle 10g Enterprise edition
I am going to deploy all web site component, database, email server and FTP service under same hardware.
Here I would like to know what are the required configuration of Windows Server 2003 to meet above requirements, like RAM, Processor, etc.
Please trigger me if I missed inputs.
It depends more on the load, the size, the complexity of the app and the performance expected, than in the components.
I mean: You can run this requirements with modest hardware, but if your app in heavy or your users are thousands, you will need another beast.
Related
We are just starting to deploy our hosted web application in an Azure environment. We have the database running as an Azure SQL Database and the web application running as an Azure App Service Web App (including a continuous WebJob). We are having some significant performance issues with the Web App and I am hoping to get some advice on how to resolve these performance issues.
Here are some key points:
The Web App is deployed as a compiled web application (binaries, markup, *.resx files), not source code
The Web App is deployed via FTP
The Web App has "Always On" turned On
The App Service is running in the South Central US Azure datacenter
The Azure SQL Database is also running in the South Central US Azure datacenter (so database latency should be minimal)
We have an exact replica of the Web App (same binaries, etc.) running on a non-Azure server in a datacenter in Los Angeles (if database latency were the issue, this site would have worse database latency)
Both instances of the Web App (Azure and non-Azure) are connecting to the very same Azure SQL Database (running in the South Central US Azure datacenter)
I have been testing from a workstation in Utah – not particularly close to either web server
On any “cold” request (site has been idle for a period of time), the Azure site seems to be significantly slower. Pages that load quickly from the non-Azure server take a long time (e.g. 20 seconds or longer) from the Azure server. The content is the same, and both apps are accessing the same database – so I don’t believe it is a database issue. I have narrowed it down to two .NET functions that seem to be the problem:
System.Web.UI.TemplateControl.GetLocalResourceObject(string)
System.Web.UI.TemplateControl.LoadControl(string)
The application includes *.resx files for a few different languages. When a request comes in, it uses the culture in the request header to load the correct resources. The GetLocalResourceObject function seems to be compiling the *.resx files on the fly, which seems to take several seconds on the Azure server. I may need to try something like this to prevent Azure from compiling *.resx files on the fly.
Some of our pages load controls dynamically, hence the call to the LoadControl method. These controls are deployed as *.ascx markup, but the code-behind is already compiled into a *.dll in the .\bin folder. Even though the controls are already compiled, it appears that the LoadControl function is trying to compile each control, which takes several seconds on the Azure server.
A “warm” page access seems to go more quickly on the Azure server (almost as quickly as the non-Azure server), probably because the resources and controls are already compiled and still in memory. I have yet to be able to determine at what point the resources/controls have to be recompiled.
I am trying to figure out the best way to make the site respond well, even on a “cold” request. I have tried running aspnet_compiler.exe on the Azure App Service server (via Kudu CMD). That seems to work sometimes, but it has not been very reliable (sometimes it doesn’t seem to work, or the process doesn’t seem to complete). It also seems that, even after compiling the site, the problem returns after a period of idleness.
Our primary objective is to get the Azure App Service Web App to perform acceptably. It seems that the only way to do that is to force the Web App to precompile the resources and user controls so they are not compiled on demand. I have yet to find a reliable way to accomplish this objective. Any help or insight would be appreciated.
I am working with an ASP.NET web application written in C# deployed to IIS/Windows Server 2008 R2. The application uses NHibernate to interact with an Oracle database running on a networked unix server.
It seems that writes being made by the application to the database have no effect.
If I manually edit the value of a record in the Oracle database, the new value is reflected by the application. However, if I attempt to change a value using the application’s custom “save” functionality, the changes are not reflected in the database. It seems like reads are succeeding, but writes are failing.
Why do writes seem to be failing?
More information:
No obvious error messages are received (ie. the application does not throw an exception and it seems to continue running as if everything is fine).
Another instance of this application is running on IIS/Windows Server 2003. This instance can write to the Oracle database (ie. the changes can immediately be seen in the database by using a database viewer after clicking “save”).
The code is virtually identical between the 2003/2008 applications. However, on the 2008 server, I am using newer versions of Oracle libraries and I changed to target architecture of the visual studio projects from ‘Any CPU’ to ‘x86’ (the 2008 server is 64-bit while the 2003 server is 32-bit).
Disclaimer:
I have very limited experience working with IIS, NHibernate, Oracle databases, Windows Server 2003, and Windows Server 2008 R2. I do, however, have slightly more experience working with C#, ASP.NET web applications, Visual Studio, and MSSQL databases).
I solved it.
It turns out one of the HttpModules was not being initialized. This was because the web.config file was tuned to IIS6, and the application was running in an application pool set to Integrated Pipeline mode on IIS7. Switching the application pool to Classic mode essentially enabled backwards compatibility.
Anyways, here is the resource that helped me figure it out: httpModules not working on iis7
I know next to nothing about databases, but need to store and present user input on my ASP.NET tiny website (up to several thousand records). Should I consider SQL Server Compact Edition? In Microsoft docs I found:
SQL Server Compact 3.5 is not currently optimized to serve as a database for Web sites. By default, connections from ASP.NET-connected applications are blocked in SQL Server Compact 3.5. SQL Server Compact 3.5 is optimized for use as an embedded database within applications. Using SQL Server Compact 3.5 as a database for Web sites requires support for multiple users and concurrent data changes. This can cause performance problems. Therefore, these scenarios are not supported. Other editions of SQL Server, including SQL Server 2005 Express Edition and later versions, are optimized to serve as a database for Web sites.
But then I remember reading some user comment that the 4.0 version of SQL Server CE is finally working OK in ASP.NET scenario. Anyone care to share his experience? I would like to try CE first as SQL server requires additional fee on my hosting.
From the download site for SQL Server Compact 4.0:
Microsoft SQL Server Compact 4.0 is a free, embedded database that software developers can use for building ASP.NET websites and Windows desktop applications.
And:
SQL Server Compact 4.0 enables new scenarios and includes a host of new features, including the following:
SQL Server Compact 4.0 is the default database for Microsoft WebMatrix, which is a stack of web technologies for easily building and deploying websites on the Windows platform.
(emphasis mine)
In conclusion - it has specifically been enhanced for web scenarios.
Yes, SQL Server Compact 4.0 has been designed with scenarios similiar to yours in mind.
New Embedded Database Support with ASP.NET
SQL CE is a free, embedded, database engine that enables easy database storage.
No Database Installation Required
SQL CE does not require you to run a setup or install a database
server in order to use it. You can simply copy the SQL CE binaries
into the \bin directory of your ASP.NET application, and then your web
application can use it as a database engine. No setup or extra
security permissions are required for it to run. You do not need to
have an administrator account on the machine. Just copy your web
application onto any server and it will work. This is true even of
medium-trust applications running in a web hosting environment.
SQL CE runs in-memory within your ASP.NET application and will
start-up when you first access a SQL CE database, and will
automatically shutdown when your application is unloaded. SQL CE
databases are stored as files that live within the \App_Data folder of
your ASP.NET Applications.
Visual Studio 2010 SP1 includes new tooling support for SQL CE
We are struggling to find out what could be the ASP.NET application performance decrease when we pass from our staging server to our production server and we would like to hear from you to help us find the bottleneck.
Our staging server is a Intel Core 2 Quad CPU Q8200 (2.33 GHz) with 4GB of RAM, Windows Server 2003 R2 SP2 x64 Edition. Databases are hosted on Sql Server 2008 Express Edition. Everything seems to work smoothly. Page change is almost immediate ad page load time (for example switching pages in a grid) is ok.
Our production server is a VIRTUAL double Intel Xeon 3.00 GHz with 2GB of RAM, Windows Server 2008 Web Edition SP2 x86 Edition. Database are hosted on Sql Server 2008 Web Edition.
Our application is a .NET 3.5 (migrating to .NET 4 in these days) using classical best practices (masterpages, CSS, AJAX, paging for data, client cache for static resources, gzip compression on IIS for static and dynamic resources, server side cache for data that doesn't change frequently...).
I really can't understand what can cause the application to run so differently between the two scenarios. What could that be? The missing RAM? The load on the production server? The network limit?
What can I do to narrow bottlenecks' research?
You could briefly enable tracing on your production server (don't forget to turn it back off) and see what stages of your page loading are taking so long).
If you can easily add 2 GB more of RAM to the virtual server, try that, it's easy and might matter. Check your RAM usage in task manager and see how much you're using.
Are these servers hosted at the same place or might there be network latency differences?
On the server, run perfmon.msc and watch the counters, what's maxing out?
I'm seeing it pop up more and more and not really understanding the purpose of it? Can I only use it when I am developing locally on my desktop?
Or can I put a commercial site on a server with say Win2003 thats using VistaDB? Is it faster than using a SQL DB? Is it secure?
Confused...
VistaDB is a .NET alternative to the lightweight database systems offered by Microsoft: Jet (Microsoft Access), MSDE, Sql Server CE or Sql Server Express. You can use it in any .NET application where you need a database and you don't really want the overhead of having a client/server database.
VistaDB is an embedded database (some other embedded databases are SQLite and FireBird). This basically means that your database is totally "invisible" to your end users. They don't need to install a client/server database like SQL Server for instance. Deploying VistaDB is simple. All you need is the database file and a reference to the VistaDB runtime DLL within your application.
A commercial application that uses VistaDB for it's backend is Graffiti CMS.
From what I can make out of their website http://www.vistadb.net/:
You can use it for both development and commercial purposes
It's not a server, it's an assembly for your website/application
My guess is that since it's not a full featured SQL server it should be faster and lighter on the resources
Don't know how secure it is, but they state that you can put it on "medium trust" websites.
You may also want to see this StackOverflow topic about VistaDB.
Nothing is faster than SQL Server for what it does. If you think SQL Server is too slow you are probably doing something wrong. It is incredibly fast. There is no way a 100% managed engine is going to be faster than SQL Server on everything.
Lighter on resources - Yes
Easier to deploy - Yes (xcopy deployment)
Desktop database - Yes, you can use it for desktop development of applications. Some people also use it for multi user applications on a shared drive. Websites are another target where you can't install a service or don't want to pay extra for SQL Server access on the hosting account.
Security - VistaDB runs in-process with your application. There is no concept of user security since you are loading it directly.
Concurrency - Depends on your application. We support multiple processes access the same database, but some operations will still have locking issues you have to work with in your code.