http://www.asp.net/signalr/overview/signalr-20/performance-and-scaling/scaleout-with-redis
I followed this link to scaleout my simple signalr chat visual studio project.
I made my ubuntu virtual mchine on azure which runs redis.
I added GlobalHost.DependencyResolver.UseRedis("server", port, "password", "AppName"); to my startup class and right now I am only testing it on my machine , not other servers.
But it does not work.
As soon as I put in that line my chat program gets stuck at line 1(see below) and never reaches line 2.
1)$.connection.hub.start().done(function () {
2) $('#sendmessage').click(function () {
What am I doing wrong?
It's best to setup server and client-side logging. This page details it http://www.asp.net/signalr/overview/signalr-20/performance-and-scaling/scaleout-in-signalr.
Let us know you're results and maybe we can help...
So after 2 months someone asked for more detail... so here's it copied and pasted
Enabling Tracing For SignalR Scaleout
To enable tracing for the backplanes, add the following sections to the web.config file, under the root configuration element:
<configuration>
<system.diagnostics>
<sources>
<source name="SignalR.SqlMessageBus">
<listeners>
<add name="SignalR-Bus" />
</listeners>
</source>
<source name="SignalR.ServiceBusMessageBus">
<listeners>
<add name="SignalR-Bus" />
</listeners>
</source>
<source name="SignalR.ScaleoutMessageBus">
<listeners>
<add name="SignalR-Bus" />
</listeners>
</source>
</sources>
<switches>
<add name="SignalRSwitch" value="Verbose" />
<!-- Off, Critical, Error, Warning, Information, Verbose -->
</switches>
<sharedListeners>
<add name="SignalR-Bus"
type="System.Diagnostics.TextWriterTraceListener"
initializeData="bus.log.txt" />
</sharedListeners>
<trace autoflush="true" />
</system.diagnostics>
. . .
</configuration>
You need to enable pub/sub channel on redis server.
Steps:
Open redis.windows.conf file
Go to the Event notification section
Add or uncomment notify-keyspace-events E
Restart redis server.
Related
I have a WCF Service which is currently in Production. The code performance are not where we would like them to be and we are unable to reproduce in our Staging environment.
I was wondering if it is possible to log every single method call made to the service and by the service. Essentially I would like a sequential list of all the calls and time stamps (our code isn't multi-threaded).
Is there a way to achieve that without having to instrument the binaries. Is there a level of tracing under the system.diagnostic node in the web.config that we could change?
Have you configured tracing in your configuration file? This is a good article on the subject.
Here is a sample configuration you can use and modify for your needs:
<system.diagnostics>
<trace autoflush="true" />
<sources>
<source name="System.ServiceModel"
switchValue="Information, ActivityTracing"
propagateActivity="true">
<listeners>
<add name="ServiceModel"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData="C:\ServiceModel.svclog" />
</listeners>
</source>
<source name="System.ServiceModel.MessageLogging">
<listeners>
<add name="MessageLogging"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData="C:\MessageLogging.svclog" />
</listeners>
</source>
</sources>
</system.diagnostics>
<system.serviceModel>
<diagnostics>
<messageLogging logEntireMessage="True"
logMalformedMessages="False"
logMessagesAtServiceLevel="True"
logMessagesAtTransportLevel="False"
maxMessagesToLog="10000"
maxSizeOfMessageToLog="10000" />
</diagnostics>
</system.serviceModel>
Use the Service Trace Viewer Tool (SvcTraceViewer.exe) to view the resulting logs.
Check WCF Tracing and optionally also WCF message logging and use SvcTraceViewer to check collected data - you can alternatively build your trace listener for logging traces for example to database. WCF also provides performance counters.
I'm sending files from clients to a server using WCF with different bindings. I need to know the sizes of the packets that the client send. How should I configure diagnostics in the config?? Or how can I view this?? Thanks.
To enable diagnostics, edit .config file
<system.diagnostics>
<trace autoflush="true" />
<sources>
<source name="System.ServiceModel" switchValue="Information, ActivityTracing" propagateActivity="true">
<listeners>
<add name="sdt" type="System.Diagnostics.XmlWriterTraceListener" initializeData="App_Data\WCF.svclog" />
</listeners>
</source>
</sources>
</system.diagnostics>
Then you can open .svclog file with Microsoft Service Trace Viewer
See also:
Configuring Tracing at MSDN
Administration and Diagnostics at MSDN
Configuring Message Logging at MSDN
Update:
I have been trying to turn on WCF tracing, but still no success... Below is my lastest update.
Do I need a permission to write to the below location?
<system.diagnostics>
<trace autoflush="true" />
<sources>
<source name="System.ServiceModel"
switchValue="Information, ActivityTracing"
propagateActivity="true">
<listeners>
<add name="sdt"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData= "#\\myservername\folder1\traces.svclog" />
</listeners>
</source>
</sources>
</system.diagnostics>
I am using .NET Framework 3.5.
What is the step-by-step instruction to turn on the WCF tracking for debugging purposes?
The following configuration taken from MSDN can be applied to enable tracing on your WCF service.
<configuration>
<system.diagnostics>
<sources>
<source name="System.ServiceModel"
switchValue="Information, ActivityTracing"
propagateActivity="true" >
<listeners>
<add name="xml"/>
</listeners>
</source>
<source name="System.ServiceModel.MessageLogging">
<listeners>
<add name="xml"/>
</listeners>
</source>
<source name="myUserTraceSource"
switchValue="Information, ActivityTracing">
<listeners>
<add name="xml"/>
</listeners>
</source>
</sources>
<sharedListeners>
<add name="xml"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData="Error.svclog" />
</sharedListeners>
</system.diagnostics>
</configuration>
To view the log file, you can use "C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\SvcTraceViewer.exe".
If "SvcTraceViewer.exe" is not on your system, you can download it from the "Microsoft Windows SDK for Windows 7 and .NET Framework 4" package here:
Windows SDK Download
You don't have to install the entire thing, just the ".NET Development / Tools" part.
When/if it bombs out during installation with a non-sensical error, Petopas' answer to Windows 7 SDK Installation Failure solved my issue.
In your web.config (on the server) add
<system.diagnostics>
<sources>
<source name="System.ServiceModel" switchValue="Information, ActivityTracing" propagateActivity="true">
<listeners>
<add name="traceListener" type="System.Diagnostics.XmlWriterTraceListener" initializeData="C:\logs\Traces.svclog"/>
</listeners>
</source>
</sources>
</system.diagnostics>
Go to your Microsoft SDKs directory. A path like this:
C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools
Open the WCF Configuration Editor (Microsoft Service Configuration Editor) from that directory:
SvcConfigEditor.exe
(another option to open this tool is by navigating in Visual Studio 2017 to "Tools" > "WCF Service Configuration Editor")
Open your .config file or create a new one using the editor and navigate to Diagnostics.
There you can click the "Enable MessageLogging".
More info: https://msdn.microsoft.com/en-us/library/ms732009(v=vs.110).aspx
With the trace viewer from the same directory you can open the trace log files:
SvcTraceViewer.exe
You can also enable tracing using WMI. More info:
https://msdn.microsoft.com/en-us/library/ms730064(v=vs.110).aspx
Instead of you manual adding the tracing enabling bit into web.config you can also try using the WCF configuration editor which comes with VS SDK to enable tracing
https://stackoverflow.com/a/16715631/2218571
How can I log what xml is sent to my WCF REST service prior to being deserialized into my datacontract class?
You can use WCF tracing to log the raw XML messages.
Tracing is not enabled by default. You can enable and configure tracing by editing the application’s configuration file. The following .config example enables WCF tracing with raw message logging:
<configuration>
<system.serviceModel>
<diagnostics>
<messageLogging maxMessagesToLog="30000"
logEntireMessage="true"
logMessagesAtServiceLevel="true"
logMalformedMessages="true"
logMessagesAtTransportLevel="true">
</messageLogging>
</diagnostics>
</system.serviceModel>
<system.diagnostics>
<sources>
<source name="System.IdentityModel"
switchValue="Verbose"
logKnownPii="true">
<listeners>
<add name="xml" />
</listeners>
</source>
<!-- Log all messages in the 'Messages' tab of SvcTraceViewer. -->
<source name="System.ServiceModel.MessageLogging">
<listeners>
<add name="xml" />
</listeners>
</source>
<!-- ActivityTracing and propogateActivity are used to
flesh out the 'Activities' tab in SvcTraceViewer to
aid debugging. -->
<source name="System.ServiceModel"
switchValue="Error, ActivityTracing"
propagateActivity="true">
<listeners>
<add name="xml" />
</listeners>
</source>
<!-- This records Microsoft.IdentityModel generated traces,
including exceptions thrown from the framework. -->
<source name="Microsoft.IdentityModel" switchValue="Warning">
<listeners>
<add name="xml" />
</listeners>
</source>
</sources>
<sharedListeners>
<add name="xml"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData="C:\logs\trace.svclog" />
</sharedListeners>
<trace autoflush="true" />
</system.diagnostics>
</configuration>
You can read more about WCF Tracing from MSDN: Configuring Tracing.
Microsoft provides a Service Trace Viewer Tool to read .svclog files.
Make sure the path defined in initializeData is writable by your service.
If you want to look at the raw HTTP traffic, a proxy tool like Fiddler is the simplest way. You'll be able to see all the information that's been POST/PUT'd to your REST service.
If you mean "log" as in "always write the HTTP traffic to a specific location on file," then you can use the built-in tracing to do most of that. Here is a link to an example of doing this, otherwise just look for "WCF tracing" online. You'll find a ton of great examples.
I configured message tracing for my WCF webservice like this:
<!--TRACING -->
<system.diagnostics>
<sources>
<source name="System.ServiceModel" switchValue="Verbose, ActivityTracing" propagateActivity="true">
<listeners>
<add name="xml" />
</listeners>
</source>
<source name="System.ServiceModel.MessageLogging" switchValue="Verbose">
<listeners>
<add name="xml" />
</listeners>
</source>
</sources>
<sharedListeners>
<add name="xml" type="System.Diagnostics.XmlWriterTraceListener" initializeData="log_messages_verbose.log" />
</sharedListeners>
<trace autoflush="true" />
</system.diagnostics>
This works fine on my development machine, it logs all messages and traces to an xml file.
Now when deploying the webservice as (sub) Webapplication inside a Sharepoint Webapplication, the service works fine but the trace file stays empty.
I checked the permission on the file, tried absolute file paths, but it still does not work.
Because the webservice is deployed as sub webapplication, it inherits the web.config settings from sharepoint. Could this be an issue? Does sharepoint somehow disable the normal tracing?
Any suggestions are welcome..
Assuming your web service is deployed to its own directory (so that it does not interfere with SharePoint), have you tried adding a web.config with the above trace config to that directory?
Otherwise as Shiraz suggests try adding the trace code to SharePoint's web.config.
I had the same issue. What worked for me was to use the "SvcConfigEditor.exe" tool on the SharePoint web.config. I probably did something wrong trying to do it without the tool. C:\inetpub\wwwroot\wss\VirtualDirectories\.
Do you have the possibility of copying this into sharepoint's web.config?
Also check in your event log for error messages.
Edit
Not sure what the default is for enabled, you could try setting it to true
<trace enabled="true" />
I had the same problem, then moved the section to the root web.config in C:\inetpub\wwwroot\wss\VirtualDirectories\80.
I had the same issue with log4net not working, and again moved it into the parent web.config file.
Both now work.