I develop locally using IIS express and always perf/load test my app, but I've run into some scenarios lately, especially when publishing to Windows Azure, where contention issues due to multiple servers simply cannot be simulated locally. I know IIS supports a web garden model where multiple worker processes are used to serve requests and utilize multiple processor cores more effectively. Does IIS express support this same setting? If so, where do I configure it?
It does not. Web garden and other application pool related features rely on Windows Process Activation Service and other IIS underlying mechanism which are not available for IIS Express.
Related
I have a SQL Server database which serves multiple ASP.NET windows applications. They each have their own SiteID to distinguish the data.
I recently realised that it isn't good practice to have multiple applications accessing one database directly and decided I would implement a service to handle all database connections.
All the windows applications and database sit on the same windows 2008 server.
I want to know what kind of service is best for this functionality. windows service?
I am kind of new to system architecture. That is, all of my web apps have been relatively flat...two machines at the most running web client and database.
I have been handed the following architecture:
1 VMware machine will run the web application, an MVC 3 app.
1 VMWare machine will host the SQL Server database
1 VMWare machine will host the services.
The machine I'm confused about is the last one. From what I understand, the services project contains references to three other projects: the model, where the entity framework edmx resides, the entities project, which contains T4 templates that use the entity edmx file as input, and the business project which is where the actual business rules are implemented and the meat of the CRUD actions take place.
From what I understand, the intent is to not run an IIS WCF web services interface, but to make calls to WCF services (like those hosted in the MMC services snap in) on the machine over the internet. There is a deployment project in the solution for the services project but I don't know if it's configured properly. I think the idea is to just run the installer on the services machine and it will work.
My specific question is if there are any important things that I need to keep in mind when implementing, configuring, and deploying these services?
I'm kind of new to all of this. I was under the impression that you had to make calls to WCF services via IIS hosted endpoints and that you couldn't (or it at least was inadvisable) to make what amounts to RPC-like calls to machines over the internet.
Since you are new to WCF services, I suggest reading this MSDN article on Hosting and Consuming WCF services.
From what you describe, it looks like you are using Windows Service as a host for your WCF service.
The most common choice for a host is IIS because of its extensive features including self-starting services, ease of deployment, load balancing and so on.
Windows Service is a valid host, provided you can justify the question 'Why not IIS?'. Maybe, you need full control over the activation and lifetime of your WCF service. Not sure.
p.s. Ensure the account that your Windows Service runs under, has the minimum privileges.
what is the requirments to run my own web server, if i bought for instance Dell PowerEdge T110 II compact tower server, what is the requirments and what do i need to host my own web application on my server?
Is this something your planning to use for your own web app? If so I would definitely recommend not going this route and instead using a service like RackSpace or GoDaddy. Especially if you're doing this out of your home as you probably would be paying a small fortune in extra bandwidth usage.
Also, what are you developing the web app in? If PHP then you'll need a LAMP (Linux, Apache, MySQL, PHP) server. If you're doing a .net application using Microsoft's Visual Web Developer then you would need a Windows Server.
I hope this helps you.
This question has probably less to do with actual programming and more to do with environment setup.
I'm developing an application for a Windows CE device, which will use a service hosted in Microsoft Azure. Obviously, this is all under development, and the service itself has not yet been uploaded to Azure. So I'm using the emulators provided by MS to deploy the service locally. Also, I don't think uploading the service to Azure just to debug it is a good idea, as that could net us a bill for Azure we don't yet want to pay.
Also, please note, I'm using VS2008 for the Windows CE project and VS2010 for the Azure project (thank you MS for dropping support for mobile devices -_-).
The problem is, the service seems to be accessible only via 127.0.0.1 or localhost, and if I physically connect a Windows CE device or use an emulated one, it becomes a new entity on the network, and cannot access that service any more.
How can I debug my Window CE application and have it see the service, whilst still being able to debug the service itself?
You are correct, the development fabric (the compute emulator that allows you to build an azure application and debug it locally) is only meant for local development. There are some hacks that allow you to get around that, but I wouldn't recommend it.
My recommendation would be to spin up the service in a more traditional hosting environment, at least in these early stages. You can define it as a web app just as you always would have, and get it functioning. Then, when you know its mostly complete, create a cloud service project and do an add existing to bring your web app into the cloud service solution. Once in, its a simple matter to add the web app as a web role.
From there, you can complete testing of the service in both the local and hosted azure environments as needed. This allows you to minimize your development costs while still leveraging the power of the cloud. As an upside, you also have done most of the basic work to ensure your service is compatible with multiple deployment scenarios giving you a greater degree of choice for its final production state.
OK, I don't know if this was intentional, or if I found one of the mentioned hacks, but I saw that IIS hosts the Azure site I created on port 5100, and the binding for this site is *, so it accepts all connections.
Using this I could access the service from my emulator, and I could still debug all Azure related stuff.
I am working with a team of 5 developers at a small company. There are 3 who work here and 2 work remotely. Currently, we are using Assembla with Trac for source control. We are working on a ASP.NET MVC web site. We are not hosting our production environment right now. I am setting up a BuildServer with Teamcity!! I have it working right now on my locally on my laptop. Should we host our own buildserver or pay some else?
TeamCity is pretty good for small shops such as yours. Hosting your own really shouldn't be bad in terms of setup and cost. As long as your remote colleagues can access it without issue and it fulfills your requirements, go for it.
I'd recommend hosting it closer to your version control server so that it can obtain the sources and perform builds faster. If you host your own version control server, either install TeamCity on the same machine (if the hardware allows it) or put it in the same network. You will also need to install build agent(s) somewhere and a database server (as the internal database may lack the performance and reliability). In a small shop a standalone server would handle all of it (TeamCity Server + Build Agent + MySQL database). In a long term buying a server and hosting it by yourself would be much cheaper than paying some hosting provider each month for a virtual or dedicated server with limited resources. It would also simplify upgrading if it becomes necessary.
TeamCity server by itself is a web application hosted on the Tomcat server. It's accessed via the web interface from the browser. If you have an external IP address on the server, just configure the Tomcat to listen on that address and TeamCity will become accessible from all over the world (don't forget to configure the security).