We have a few 'classic asp' client facing websites feeding off a central asp.net mvc site which acts as a webservice ie we query the MVC controllers directly from the ASP sites with extensive use of jquery ajax. This MVC site in turn queries sql server running on a seperate box. We have a custom session profile which requires a call to the database on every page view.
At the moment the client facing websites sit on the same box as the mvc site. We now want to use Windows 2008 network load balancing service to both contain high bursts of traffic and maintain availabilty. Within a currently limited budget...
What is the best policy: 2x2 - client sites on 2 NLBed boxes & MVC on seperate pair of NLBed boxes- or both on a single group of 3 NLBed boxes?
I would go with the 2x2 solution just to help keep those MVC sites away from the Web. If you do not need the MVCs kept away from the web then go with 2 or 3 NLB'd boxes.
Be aware that NLB is a IP to IP load-balancing solution so if you are funneled through a single connection it will end up always going to the same server and you really just get Fail over.
Related
I am running a site in which I am using SignalR with a custom scaleout backplane that allows us to push out real-time data to users connected to any of our load balanced web servers.
I recently found out that the Kendo UI components for MVC (which we use for other site features) can be configured to use SignalR rather than AJAX for binding with the data model. It seems like using web sockets via SignalR could potentially offer a performance boost over using AJAX as we are now. However, I would ideally like to let our kendo components access a SignalR instance that only uses whatever web server they connect to rather than using the instance with the scaleout backplane since that would involve a lot of overgead that isn't necessary for that data binding.
I should mention that there would be cases where we would have one page with one partial view that uses one SignalR configuration and another partial view that uses the other.
Is this something that can be done? If so, are there recommended ways of going about doing so?
I am not entirely certain about your approach but you can of course have 2 SignalR servers using different kinds of backplanes and connect to the 2 servers from a client. You would have to though look into how to handle cross-domain requests with SignalR.
I currently have a ASP.NET MVC 2 web application and would like to enhance the architecture to support a SAAS model. I plan on eventually building a number of web applications so would like to design the system accordingly.
The goal would be that when a client would hit the following url clientxyz.domain.com they would see an image of all their subscribed applications. This would essentially be a web page with a bunch of application icons. Once a client would click on a icon it would navigate to that actual web app at the following example url clientxyz.domain.com/application_name.
We currently use GoDaddy to host our domain and plan on using a Cloud based iLand server to host our application. We only plan on a few new clients a year due to the nature of our software.
I have a number of questions:
Is it possible to programmatically create subdomains on the fly using a .Net api. I'm pretty sure GoDaddy does not let you do it. So is there another provider that would let me create subdomains via C#. This may be the wrong approach and may not even need to physically create client subdomains. Instead I may be able to accomplish this using url rewriting in IIS/MVC?? If I use rewriting, it would have to satisfy the url requirements mentioned above. Any suggestions/links/examples?
Should I create a separate IIS website for each tenant/client? Or should I use URL rewriting and simply have a single website / application pool? Looks like you can programmatically spin up IIS websites (example: http://www.eggheadcafe.com/tutorials/csharp/d4bba585-b517-4834-8476-ff05b085d86e/iis--create-app-pools-virtual-directories-and-web-sites-c-net.aspx)
Since we are using a Virtual Server on iLand do I simply have to point GoDaddy to the nameserver at iLand.
I would like to automate the entire new client process if possible. To accomplish this, I would have to created the database (probably going to have single db per tenant), populate the global client/tenant table, create admin user account and subscription details in newly created database and create subdomain depending on approach. Am I missing anything?
thanks in advance.
I will developp and host an e-commerce website based on Asp.Net MVC4 (with several SQL Server Jobs).
I think use Azure in order to stay in Microsoft's world and avoid dedicated server management.
The package Web Site Shared with 1 site / 5Go SQL Server Database / 200Go Bandwidth is very interesting with the price based on 12 months.
But i don't know if this configuration is enough specially on the bandwidth.
What do you think of ? Did you use Azure with this type of application ?
Regards,
Guillaume.
If you want to develop E-Commerce application you will have to secure customers' sensitive data i.e. credit cards, address details etc. via secure connections (HTTPS; in many countries this is legal requirement). For that reason you will have to have SSL support.
Azure Website do not support SSL for custom domains. However, they support SSL for *.azurewebsites.net DNS name. So if your E-Commerce application DNS will be, say, my-ecom-app.azurewebsites.net then it's fine. Otherwise, I would not recommend Azure Website solution yet (I am sure SSL support for custom domains on Azure Website will be implemented).
Azure Cloud Services, on the other had, have full support of SSL for custom domains.
One of the really good websites to check Azure features and development roadmap is ScottGu's Blog
Azure Web Sites do not support SSL and I really don't know of any successful e-commerce site that does not run SSL for at least part of the website. If you really want to host your e-commerce on Azure today your only real choice is to run Virtual Machines for your web front end servers and use them for your DB or use SQL Azure.
We developed platform called Virto Commerce that does just that, MVC4 website hosted on Azure. There was also a need for SQL Jobs (indexing, payment processing, cart cleanups and so on) for which we used WorkerRole (instead of WebRole). WorkerRole and WebRole can actually be combined as part of a single deployment, however it is better to use a different instance for worker roles. In our case WorkerRole acted as a scheduler for multiple jobs defined in the database.
The challenge with WorkerRoles however is to make sure they scale well when new instances are added. So the workload needs to be distributed between multiple instances. This is done through the use of queues and blob locks, where each job is now split into two, one that schedules and partitions the work and the second that actually picks up the next partition and completes it.
Hope this helps!
PS: Virto Commerce is now available as an open source project on codeplex, go to http://virtocommerce.codeplex.com
I'm working on a project that involves two web portals hosted on the same IIS 7.5 server:
(A) MVC4 web application for administration
(B) Mobile MVC4 web application with jQuery Mobile
Both are retrieving the data from the Web API based services hosted on other IIS server.
Now I'm about to add manipulation of images that are managed on Admin portal (A) and displayed to clients within Mobile app (B). Images will be added/changed dynamically with higher frequency.
I had two solutions in my mind:
Store all images in database on the server that hosts Web API as byte arrays, and send them on demand as base64 strings - render them on mobile app pages as base64 strings:
Can set any kind of security restrictions and integrate them well with MVC
Pages would be rendered in one request
Transferring from Web API to Mobile app
What happens to caching?
Store all images on the server that hosts both (A) and (B) in some shared folder, include them in rendered pages as regular tags.
No transfer between WebAPI and Web server
Caching of images
Several requests for each image on the page
Thing that I have to take in consideration as well is that there will be native iPhone app that will do the same role as mobile web app, meaning it should have access to same set of images.
Any thoughts would be appreciated on this, I'm looking for best practices solution, a guide, hints, or anything that I could use.
Also, if option 2. is suggested, what is the best place to store images to be shared between two portals?
Thanks!
I would recommend you going with option 2 and store the images on some shared folder. The best would be to have a specific application that will act as CDN hosting all your static resources. According to YSlow best practices this CDN should be hosted on a different top level domain than the clients, thus allowing cookieless access to those lowering the bandwidth consumption.
I'm looking at putting together a REST based system which still has a standard browser style access. My desire is to have both of these on the same machine, but what are my options?
Use IIS to host both the web-site and the REST service (different URIs, e.g. http://mysite.com/ and http://mysite.com/api
Use IIS and some magic I don't yet know to have two domains mapped to the same machine but different services (e.g. http://www.mysite.com and http://api.mysite.com
Combine the two technologies into a single service (that perhaps uses routing tables to direct the requests to MVC or WCF where appropriate).
My preference would be the third option, this would allow me to have a single code-base and single repository accessing. The WCF page on codeplex mentions in its release notes, "not tested with MVC3" - is this suggesting that this is a possible approach?
I'm not keen on using MVC for the REST implementation as it is intended that the majority of interaction with my site goes via API, so I want that as the focus.
I've ported the contact manager to use MVC 3. It definiately works though we've not done exhaustive testing. The one thing in general to cognizant of with regards to web api is that both MVC Routes and Service Route are greedy. If your default route is first then MVC will try to grab your HTTP Service requests. One thing you will want to do is put your Service Route first before your MVC routes. If you run into additional issues, you may need to use custom routing constraints.
In http://webapicontrib.codeplex.com there is a sample that works with MVC 3. It is in the Samples/experimental folder. However, it was built with a custom version of WCF Web API. I don't believe it needs to be though. I've been meaning to get the author of the sample to switch it over.