I have a WebAPI project running on local machine that is calling server side codes via remote proxy (local machine) on service layer. The profiler was able to trace the hotspot but up to service layer only and the hotspot is all pointing to methods calling server side methods.
How can I let the profiler trace the bottlenecks in server side codes?
Things to note:
1. Controller and service layer = .Net4.5
2. Server Side = .Net 3.5
3. Remote Proxy is using local web service.
Things I did
1. Profile the whole project
2. Profile the web service
3. Run the remote agent locally
You can run multiple dotTrace standalone at the same time. One dotTrace for each side (WebAPI and server). If you attach to the server side process, you will be able to find the hotspots
What server do you use to host the server-side code? If it is IIS or IIS Express, you need to profile it from the corresponding section of dotTrace Home.
Anyway, you can start profiling from ".NET Process" section of dotTrace Home - in this mode any managed application that is started after clicking Run will be profiled (you just need to select the right application in profiling controller and get a snapshot). See this page for details: https://www.jetbrains.com/help/profiler/Profiling_Guidelines__dotNET_Process.html
Related
I have hosted a WCF application in IIS on my local machine. The host name in IIS and host file is "serv.xxxx.local". My appl pool is running in IIS and my net.tcp Port Sharing Service is is also running in my Service.
However when i try to consume this wcf service from my MVC application, it doesnt work, unless I attach my WCF project to the process in Visual Studio.
Why can I just consume my WCF service without debugging in Visual Studios
I am running WINDOWS 10 by the way, i noticed there is no start automatically for the website in IIS.
The issue with this was that the app pool configured for my WCF service did not have the access to my SQL Server database. I had to add the app pool the list of Logins in SQL Server.
To do this:
1) Open SQL Server
2) Expand the Security tree
3) Right click on "Logins"
4) Add your app pool. e.g "IIS AppPool\" and click OK,
5) Right click on the login you just created and click on Properties, then in the UserMappings tab, select the database you wish to access and then, select datareader and datawriter, click ok.
Everything should be fine after that.
With VS 2010 Web Deploy is functional and working without issue. At the same time, Web Deploy from VS 2012 fails, indicating that the server did not respond and suggesting this link.
This notes the following conditions, all of which are fulfilled.
You can ping the remote machine
That the msdepsvc or wmsvc service is started on the remote server.
Your firewall is not blocking incoming connections of your ports on the destination. If you used the default installation, then it would be 80 for msdepsvc and 8172 for wmsvc
Web Deploy is still functioning for VS2010.
How can this be solved?
Clearly an example of not reading all the documentation first. However, for those looking to understand some of the changes here's what I found.
VS 2012 uses the Web Deployment Agent Service and NOT the Web Management Service
Local deployment is to "http://Your Server/msdeployagentservice" and NOT :8172/msdeploy.axd
For a complete account of the many options GO HERE!
Hope this helps someone else.
I'm trying connect to an in-process StreamInsight host running in Visual Studio (as opposed to the windows service version) using the Event Flow Debugger tool, and I have been unsuccessful.
Does anyone have experience with this? I'm looking at the following blog posts:
End to end StreamInsight example: http://blogs.msdn.com/b/masimms/archive/2010/08/10/building-your-first-end-to-end-streaminsight-application.aspx
In-process vs. Standalone Host deployment models: http://seroter.wordpress.com/2010/06/27/leveraging-and-managing-the-streaminsight-standalone-host/
You need to explicitly open up a WCF management service endpoint for any embedded StreamInsight host. You can choose any URL that you have permission to create. Once you start up your embedded server with the management point host opened, you can connect the Event Flow Debugger to the URL chosen.
For the standalone host, there is an entry in the StreamInsight.exe.config file that holds the management service endpoint URL used by the standalone Windows Service. This host is automatically opened when you start the Windows Service associated with the instance.
When I create a new "WCF Service Application" in Visual Studio and right-click Service1.svc, I can choose "View in Browser". A web browser appears showing http://localhost:50311/Service1.svc, which says
Service1 Service
You have created a service.
To test this service, you will need to create a client and use it to call the service. You can do this using the svcutil.exe tool from the command line with the following syntax:
svcutil.exe http://localhost:50311/Service1.svc?wsdl
...
The service somehow seems tied to Visual Studio itself, since the web page becomes inaccessible if I close the solution. What's going on? I don't have a web server installed, and I didn't (knowingly) start the service. What is the source of the displayed web page, and why is it on port 50311? Can the page be customized?
What you're seeing is the development web server that starts when you run a debugger instance of a project that requires a web server. (WCF, ASP.NET).
The port 50311 is determined by your project settings (most likely random, but you can specify).
The page for a .svc file is not meant to be customized. Since the service is waiting for a caller, that default page simply tells you that it's running properly.
Keep in mind that WCF offers several binding options that use various protocols (HTTP, TCP). Depending on the protocol that you choose, you will have to host in either IIS, a Windows Service or elsewhere. By default, new services will adopt a binding that works in IIS.
Check out Introduction to Building Windows Communication Foundation Services
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).