We are testing out Sentry and currently using the Sentry.io service for the server. When sending the error logs using the .Net Raven client to Sentry.io, it takes a rather long time (10 - 15 seconds) for such a small amount of data. Is this normal? Is it because we are using a free account or is this delay typical of paying customers as well? For us this is being used by a Windows C# gui application so the user is waiting for the log to be sent. I am using async programming so the GUI is not locking up or anything, but the pause is long enough that my guess is some of our customers would think it is not working.
Where are you located geographically? On our end, the response is less than 100ms by far on average. Our servers are in Dallas Texas, so if you’re geographically far away, there’d be a lot of network latency or something otherwise out of our control.
Our users are world wide though mostly US and Canada. But the times I am quoting are the times I am seeing here in Austin, Tx so just down the road from your servers.
Here is the code I am using:
var ravenClient = new RavenClient("https://HEX1:HEX2@app.getsentry.com/NUM1");
var sentryEvent = new SentryEvent((Exception)ExceptionObject);
sentryEvent.Tags.Add("version", GetVersion());
var result = await ravenClient.CaptureAsync(sentryEvent);
I replaced what I assume are values specific to my company / project with fake entires HEX1, HEX2, & NUM1, but the real URL I am using comes directly out of the C# code sample provided in Project Settings -> Data -> Error Tracking -> C# section of the dashboard. When I debug this code almost all of the time is spent on the last line doing the actual sending. I am using v2.2.0 of SharpRaven which appears to be the lastest version of that library. Any ideas what I am doing wrong?
Went and retested and the average times I am seeing are around 20 - 30 seconds actually, but the first time I tried this afternoon it was closer to 90 seconds while subsequent tries were the in the shorter 20 - 30 second range. I am not sure what is going on but whatever it is causes this process to crawl.
Ouch, that is definitely not something we’re seeing on our side.
Are you able to run some network tests and see if you just have a horrible connection to our servers by some odd chance? I’m curious what the ping latency is, and possible an mtr to debug. If it’s not the network latency, and it does turn out to be something in the C# library, that’ll be significantly harder since that library is community maintained. I can’t imagine something is that wrong though. 
I’m still fairly noobish on networking and the tools used to debug it. I looked up mtr and I think I know what you mean and can look in to that, but I first I want to show you something and see if this makes any sense to you. I ran Resharper’s (Visual Studio 3rd party tool) performance profiler and this is what it shows.
It looks like the offending code is not in SharpRaven itself but in process of getting the proxy url inside of HttpWebRequest. I am not all that familiar with this beyond very generically understanding what a proxy is. Based on this do you have any ideas? I am on Windows 7 btw.
I fixed the issue by adding the following line before calling the SharpRaven code
WebRequest.DefaultWebProxy = null;
I also found that you can go in to Internet Explorer Lan Settings and tell it not to Auto Detect the proxy settings. But going in to a computer in our office that I know is really close to a basic Windows 7 install I can see that it appears to be set by default. This means I probably need a programmatic way to solve this. I am not sure if our internal server which hosts our DNS/DHCP is causing this issue or not, but I am going to just assume a proxy is not required for our customers. This may be a bad assumption as I don’t know much about proxies but I am more comfortable with disabling proxies than having this released and having it take forever to send the error logs to Sentry. I probably should look in to creating a config setting to allow users to turn back on the use of proxies in case someone requires one.