In the beginning, We have 1 Application Servers, 2 Web Front End Servers and database server in Asia.
Deploying solution(wsp file) is fast.
After adding a WFE server in Sweden to the farm,deploying solution(wsp files) becomes very very slow.
It cost more then 5 hours to deploy. We have adjust TimeZone but it still not work.
Does anyone know the reason why deployment is so slow or
is there a way to detect the deployment process?
Related
I have a database on Azure that is around 500mb, ~50 tables and a few tables with 100k+ records. A single table with ~1000k records. This is not a big database (around 20-50 DTU's). I have an ASP.NET MVC application that runs on top of this database.
When I run towards this database either from local or on my test/production environment, the database is extremely fast. My code is "solid production code" (indexes, paging), meaning I do not do anything crazy and this works on pretty heavy production loads.
However, when I import this database locally, it's VERY, VERY slow (pages takes 10-20 seconds to load, or simply fails). This results in I basically cannot run my application locally. Here is an example error I get (DK error message, but the typical error - see The wait operation timed out. ASP ) :
I experience the same problem when I run queries outside my main application. I am 99% sure this is a database problem, not an application problem because when I run scripts it's very slow too.
Any idea what the problem is? Why is my localhost so slow it cannot barely run normal queries?
This is how I created my local databae:
Save to local desktop:
I import into (localdb)\MSSQLLocalDB :
Wait for this to happen and everything is confirmed. I then change my connection string to this database.
I suspect you do not have enough RAM to host your own server. I had that problem, locally hosting MSSQL server 2012 with 8GB of RAM on a Windows 10 machine, with Core i7 10th Gen. Sometimes there were no problems, but mostly I was getting very slow query response times, and even timeouts. This was my development machine, and I noticed that all the RAM was being consumed, just from development alone, without any database connections. So I suspected that there was not enough memory for querying the database as well.
I increased the RAM to 32GB (but 16GB would have sufficed), and problems solved.
Enabling TCP/IP connections to your local server could resolve this issue.
Start -> Run -> mmc
File -> Add/Remove Snap-in...
SQL Server Configuration Manager -> [OK]
SQL Server Network Configuration -> Protocols for MSSQLSERVER -> TCP/IP=Enabled
Restart server.
we have developed an application using ASP.NET/C# MVC 4.0, SQL SERVER 2012 DB, Entity Framework, WCF Service.
application website is hosted on IIS 10 and the operating system used is Windows Server 2016 and this is standalone WEB server dedicated for our project.
application WCF web service is hosted using Windows Service and this is standalone APP server dedicated for our project.
application database is hosted on SQL Farm and this is a common database server, where other projects databases (more than 60) are also hosted.
application is already running absolutely fine in PROD environment from couple of years.
but suddenly from couple of months, we started facing as intermittent issue and i.e. application slow response
There are no errors, but the response time is too long, and sometimes it doesn't respond either, the browser keeps waiting for the web server.
customer has complained that his web application gets slow sometimes.
It happens at random times, the system just gets slow then after few hours (2-3) it gets back on track with normal response times.
this slowness issue is affecting only to one specific MVC View, whereas other MVC views are rendering correctly at the same time when slowness issue occurs.
error handling is already in place in the .net code, but nothing gets logged in error log file.
also DBA has confirmed that there are no issues on the SQL Farm and none of the other projects apart from us has reported slowness issue whose database is also hosted on the SQL Farm.
when tried to reproduce the same issue on UAT with the same PROD database copy & same user, was not able to reproduce it.
UAT environment is exactly similar for WEB & APP server.
only in case of UAT database server, we do not have SQL Farm here. we have standalone database server dedicated for our project.
here tried doing some R&D and verified few things, but still unable to resolve the issue.
so could you please guide me here that what should i do/verify to resolve this issue.
thank you in advance for your inputs.
Okay, here goes: Our developers are running VS 2012 on Win 7 boxes. I am running TFS 11 on my Win Server 2008 R2 box with IIS 7.5. It runs fine. My gating unit tests fail however. While I am not completely certain what the issue is, I seem to be unable to get the default Web Site or our application that I have installed under it to run. The default web site won't even return a test.htm file choosing instead to return a 503. To date I have tried...
Setting up WCF with access to the test cert installed on the box
Changing the app pool and giving it access to the dir in question
Burning a small offering to the gods of oblique IIS issues
Various other things I can't recall at the moment
I would take Sean Walsh's advice at the end of this post: http://forums.iis.net/t/1183179.aspx/2/10 but I need SQL reporting services for my TFS to work properly.
Thoughts? Thanks in advance.
Sean Walsh had it nailed. This turned out to be due to the fact that SQL server reporting services were using the port at the behest of TFS. I was able to step around this problem by setting up a dedicated build box on a VM.
I have SharePoint farm 2010 with two wfe's, in which one wfe is down. Can I deploy a wsp solution now? What are the consequences?
You can but why would you want to put your WFE Servers out of sync. Consequence is whenever the server is up and if you have load balancing enabled, than the request can go to other server where you didn't do deployment.
Excerpt from Installation and Deployment of a Farm Solution in SharePoint 2010
It is possible to deploy a solution on only one server even in a multi-server farm, using the DeployLocal property. This should be done only temporarily as a troubleshooting step. At all other times, the front-end web servers should be identically configured.
If we have 3 developers working on the same Biztalk project what is the best way to set up our development environment?
We are using TFS to store the Biztalk project.
Should we use 1 sql server and 1 Biztalk server and then have 1 or more developer machines that access the sql and biztalk servers? The issue we get with this is when 1 developer compiles and deploys their changes it can effect other developers if they are also trying to compile and deploy their work.
Should we have each developer host their own complete sql and biztalk server for local development either on their machine or within their own virtual machine? The problem we find with this is that each developer could modify their server settings and those settings are not stored in source control. This can cause confusion when changes are deployed to a testing server. Another smaller issue is that each developer would need to have sql server, biztalk server and windows server installed.
Is there another way to set up a multiple developer biztalk development environment?
You will always want to have each developer have a complete BizTalk installation on their own machines. Believe me, it doesn't work otherwise, as you'll just keep getting on each other while trying to deploy/test/debug changes.
That said, you will also want a centralized dev/test environment where you deploy your code for more complete integrated testing and making sure all the changes from everyone are seen together.
Your point about configuration is true, but only up to a point. This is because you should make your solution configuration part of your source code and keep it in source control as well. This is particularly important once you're a bit ahead in your development as you'll need to start maintaining multiple versions of your binding files for each environment (dev, test, production and so on).
tomasr is right. Also, if you have decent hardware and lots of RAM, you may want to setup a VM image of your full developer environment, then share this will all your team. Not as fast as native hardware, but does allow you to roll back changes, replace your VM if you really mess up and everyone then has the same environment – ideally close to the target one.
Setting up a continuous build server is also a most, if your projects are small, you can get each checkin to cause a full build, BizTalk deploy, export of MSI and then run tests. Later as your solutions get more numerous you might have to move to a continuous build of C# changes only, then say nightly or several times a day, you do a full. We have done this with CruiseControl.net, Nant, nunit and various power shell scripts, it was pretty time consuming, but each morning we come to work to find a fully compiled, deployed, exported and tested set of BizTalk solutions ready for the test team.