Les serveurs virtuels sont-ils originaux avec Windows Server 2003, IIS 6, ASP.NET MVC?

Question

Depuis plusieurs mois, je travaille sur un site client en construisant un site web en utilisant ASP.NET MVC avec C#, SQL Server 2005, ADO.NET Entity Framework, JQuery et certaines API Web et géodatabases ESRI. Le serveur de test est en cours d'exécution IIS6 sur Windows Server 2003. Au cours de cette fois que je l'ai vu des choses étranges qui ont causé beaucoup de réusinage:

1. fichiers JavaScript sur les serveurs du client ne reconnaît pas un chemin relatif normale aux scripts ou URL: au lieu de configurer un jqGrid avec une URL de '/Reports.mvc/GridData' je dois l'initialiser à <% = ResolveUrl ("~/Reports.mvc/GridData")%> dans une vue, ou capturer le chemin d'application dans la balise de tête < > de la page principale:

 
    // Declare a variable to pass to jQuery functions that don't seem to 
    // handle URLs below the top-level pages on MVC in IIS6. 
    var _applicationPath = new String(''); 
    // Reset the variable after jQuery document loaded event to make sure 
    // every jQuery library and plugin sees the value. 
    jQuery(document).ready(function() { 
     _applicationPath = new String(''); 
    }); 

2. J'ai testé les formes et les fonctions qui affichent de nouvelles données dans la base de données et celles qui éditent les données. Sur deux machines de développement et sur le serveur je suis capable de montrer que tout fonctionne. Pourtant, chaque fois qu'ils testent, le client revient et dit que ce champ ou ce champ n'a pas enregistré, ou "affiche drôle".

À ce stade, le compte de l'utilisateur est utilisé uniquement pour se connecter au Web. Mon code de structure d'entité est dans une DLL de données et fonctionne avec la base de données via une connexion d'utilisateur de l'application unique. Il ne devrait donc pas y avoir de problèmes avec les permissions ou la sécurité.

Le code ne change pas lorsque quelqu'un se connecte, les vues ne changent pas et la base de données ne sait même pas qui s'est connecté au site Web. J'ai donc dû revenir sur le code encore et encore et essayer de programmer encore plus défensivement. Mais j'ai atteint le point il y a un moment qu'il n'y avait plus rien à faire.

Hier, le client m'a dit que le serveur que j'utilisais sur son réseau était un serveur virtuel. C'est dans un environnement académique, et le serveur est dans un autre bâtiment quelque part sous le contrôle d'un autre département. Lors de la première utilisation de ce serveur de test, j'ai pu créer un site ASP.NET, mais la plupart des contrôles de données empêchaient le chargement des pages et les autres composants d'ASP.NET ne fonctionnaient pas sur le système de développement. C'est pourquoi je suis passé à ASP.NET MVC.

Nous avons migré vers un serveur de test physique que je n'avais jamais utilisé auparavant avec un serveur virtuel. Quelqu'un at-il eu des expériences bizarres lorsque vous travaillez avec des serveurs virtuels avec ASP.NET ou l'un des autres?

Answer 1

Je ne fais pas confiance serveurs virtuels beaucoup de serveurs virtuels disponibles sur le marché de l'hébergement (en particulier ceux à faible coût avec des ressources trop limitées et la promesse de ressources supplémentaires "flexibles") pour héberger des sites Web publics parce que l'allocation flexible des ressources ne fonctionne souvent pas pour le trafic de pointe, causant parfois des accidents et des instabilités. Ce que vous décrivez pourrait provenir d'un serveur virtuel équipé de ressources trop limitées, ou être exécuté dans un environnement instable ou surchargé. Cependant, il se peut aussi que la machine soit configurée et que le serveur Web soit configuré. (Ce problème de chemin dans 1. est certainement un problème de configuration, je dirais.)

Vous pourriez essayer de demander aux personnes qui exécutent la chose d'augmenter les ressources (temps processeur, RAM, trafic réseau) pendant un moment et de voir si ça devient meilleur. Si c'est le cas, vous devrez voir si l'augmentation peut être rendue permanente, ou un serveur dédié utilisé à la place.