I'm banging my head here trying to figure out why there is a three to four second overheard for when an NSURLConnection object is created with a POST based NSMutableURLRequest. The overhead which I speak of, is after an NSURLConnection gets fired off, watching Apache access logs, I see the request come in substantially longer after invoking the request. On any other platform, I'd troubleshoot the latency that it takes to resolve DNS before going further. I shouldn't exclude the iPhone in this case as well. Has anyone else noticed similar behavior?
Thanks.
Sounds plausible that DNS is your bottleneck. Try making the request by address instead of name - at least for debugging.
Is DNS a known bottleneck for the iPhone. I've noticed this as well on my 3G connection. Did you workaround the problem by using the address instead of the hostname?
Related
Question
When sending a large http request (e.g. 100MB) to Spring Cloud Gateway, does it read the complete request into memory before forwarding it to the downstream service?
Assumption/Guess
From the memory consumption and timing, it seems to work this way but I cannot find any information about this in the documentation. Can anyone confirm if the assumption is correct or not?
Are there workarounds/solutions?
If the assumption is correct: Is it possible to make the Spring Cloud Gateway "stream" the request immediately after the route has been determined (e.g. after reading the headers)? Because reading the complete request into memory can quickly turn into a bottleneck when multiple "big" requests are coming in at the same time. Or are there some other recommended workarounds for this issue?
Thanks for the fast response and hint spencergibb!
Actually in our case it was the RetryFilter which was causing the effect that we were observing. After deactivation the streaming is working fine and the memory constraint is even mentioned in the documentation of the RetryFilter.
According to documentation I expected that the filter would only be applied to GET requests on default. But maybe this was a misunderstanding. Removing the filter definitely solved the memory issues for us.
I'm struggling with Kamailio as a simple dispatcher for FreeSwitch. This is my configuration so far: http://pastebin.com/nBPSpe6S
Connecting an iPhone and an Android makes the calls between them timeout.
Connecting one of the phones and my laptops makes calls between them produce the error "Too many hops".
With all of them I'm able to call in to the Freeswitch, for listening to voicemail, hold music etc.
So I guess it's still NAT problems or similar?
Can anyone spot the error, missing thing or something else that is wrong with the config?
P.S. Adding phones, laptops etc. directly to FreeSwitch, without Kamailio, makes everything works.
"Too many hops" is just that - too many hops. A SIP messages is being routed around in a bad way. In many cases in Kamailio, this is because DNS and Kamailio doesn't have the same view of the world. Kamailio doesn't know which domains it's authoritative for (the alias= configuration parameter) and forwards using DNS. DNS points back to the same Kamailio.
Your configuration lacks both alias= and IP addresses kamailio should listen to. Now, your configuration doesn't really use the alias, so I don't see that problem here. Since you are not showing the dispatcher table it's hard to figure out. I suggest you add a couple of calls to xlog() to see what's going on and figure out why a message is looping around. Good luck!
Our web service has a "ping" function which is great for testing if the web service is available or not (I don't really care if the internet connection is available, right?) and I know how to test this condition, but how do I go about implementing this in my application? As in where do I test?
If there is no connection, the app doesn't crash of course, it just returns an empty table view or set of views. Should I put the ping before each request and generate an exception or error message when the ping fails? The web service request + response itself can take longer than the transmission of the actual data (latency I guess it would be) so I worry that implementing a Ping before each request might almost double the time it takes to perform each request. Or, should I be continually ping-ing and making sure there is a connection? What is the best practice?
Or should I even worry about it at all?
I was able to use the Reachability library as seen in the answer to How to check for an active Internet connection on iOS or OSX? . You can extend the library to include not only hostReachable but wsReachable with a little bit of work that is probably obvious to all.
iOS can provide you with callbacks once the network connectivity changes (e.g. from airplane mode to cell only to wifi and back). So you get notified whenever the network state changes and you don't need to keep pinging the server and can display proper online/offline messages.
Have a look at the SCNetworkReachabilitySetCallback method in the NetworkReachability.h header.
Uploads from my app are too slow, and I'd like to gather some real data as to where the time is being spent.
By way of example, here are a few stages a request goes through:
Initial radio connection (significant source of latency in EDGE)
DNS lookup (if not cached)
SSL/TLS handshake.
HTTP request upload, including data.
Server processing time.
HTTP response download.
I can address most of these (e.g. by powering up the radio earlier via a dummy request, establishing a dummy HTTP 1.1 connection, etc.), but I'd like to know which ones are actually contributing to network slowness, on actual devices, with my actual data, using actual cell towers.
If I were using WiFi, I could track a bunch of these with Wireshark and some synchronized clocks, but I need cellular data.
Is there any good way to get this detailed breakdown, short of having to (gak!) use very low level socket functions to reproduce my vanilla http request?
Ok, the method I would use is not easy, but it does work. Maybe you're already tried this, but bear with me.
I get a time-stamped log of the sending time of each message, the time each message is received, and the time it is acted upon. If this involves multiple processes or threads, I have each one generate a log, and then merge them into a common timeline.
Then I plot out the timeline. (A tool would be nice, but I did it by hand.)
What I look for is things like 1) messages re-transmitted due to timeouts, 2) delays between the time a message is received and the time it's acted upon.
Usually, this identifies problems that I can fix in the code I can control. This improves things, but then I do it all over again, because chances are pretty good that I missed something the last time.
The result was that a system of asynchronous message-passing can be made to run quite fast, once preventable sources of delay have been eliminated.
There is a tendency in posting questions about performance to look for magic fixes to improve the situation. But, the real magic fix is to refine your diagnostic technique so it tells you what to fix, because it will be different from anyone else's.
An easy solution to this would be once the application get's fired, make a Long Polling connection with the server (you can choose when this connection need's to establish prior hand, and when to disconnect), but that is a kind of a hack if you want to avoid all the sniffing of packets with less api exposure iOS provides.
I was recently approached by my management with an interesting problem - where I am pretty sure I am telling my bosses the correct information but I really want to make sure I am telling them the correct stuff.
I am being asked to develop some software that has this function:
An application at one location is constantly processing real-time data every second and only generates data if the underlying data has changed in any way.
On the event that the data has changed send the results to another box over a network
Maintains a persistent connection between the both machines, altering the remote box if for some reason the network connection went down
From what I understand, I imagine that I need to do some reading on doing some sort of TCP/IP socket-level stuff. That way if the connection is dropped the remote location will be aware that the data it has received may be stale.
However management seems to be very convinced that this can be accomplished using SOAP. I was under the impression that SOAP is more or less a way for a client to initiate a procedure from a server and get some results via the HTTP protocol. Am I wrong in assuming this? I haven't been able to find much information on how SOAP might be able to solve a problem like this.
I feel like a lot of people around my office are using SOAP as a buzzword and that has generated a bit of confusion over what SOAP actually is - and is capable of.
Any thoughts on how to accomplish this task would be appreciated!
I think SOAP is the wrong tool. SOAP is a spec for exchanging structured data. For your problem, the simplest thing would be to write a program to just transfer data and figure out if the other end is alive. Sockets are a good way to go. There are lots of socket programming tutorials on the net. Pick your language, and ask Mr. Google. Write a couple of demo programs to teach yourself how it works. Ask if you have more specific questions.
For the problem, you'll need a sender and a receiver. The sender sends data when it gets it, the receiver waits for data and hands it off when it arrives. Get that working first. Next, add in heartbeats; a message that says "I'm alive", sent periodically. Get that working next. You'll need to be determine the exact behavior you want -- should both sides send heartbeats to the other end, the maximum time you are willing to wait for a heartbeat, and what action you take should heartbeats stop arriving. The network connection can drop, the other end can crash, the other end can hang, and perhaps there are other conditions you should think about (e.g., what if the real time data is nonsense?). Figure out how to handle each condition, and code up the error handling. Test it out, and serve with a side of documentation.
SOAP certainly won't tell you when the data source goes down, though you could use "heartbeats" to add that.
Probably you are right and they are just repeating a buzz word, and don't actually know much about what SOAP is or does or have any real argument for why it ought to be used here.