High CPU Load When Using ConnectionKit about connectionkit HOT 13 CLOSED

Can you get me some samples during the high CPU usage, please? That's about the only thing we have to diagnose this.

from connectionkit.

Here are some captures by Instruments (I'm self-taught, so if that isn't what you mean by 'samples,' please correct me). One is a dispatch profile, and the other is a system trace. The code I used was about as basic as it gets - essentially a blank xcode project, and in the appdelegate (in applicationDidFinishLaunching) I get the contents of a directory on an ftp server and then upload a small jpg.

Dispatch - http://bit.ly/10X22PC

System profile - http://bit.ly/14f4O70

The system profile is pretty big (29 mb compressed, 650 mb uncompressed), and Instruments chokes a little to open it, but I think it at least shows that there is something strange going on with dispatching.

If you need anything else, I'd be more than happy to provide it.

from connectionkit.

After some more testing, the cpu load only spikes when using ftp (as opposed to sftp; havne't tested other protocols).

So when I do any kind of operation (get contents of directory, upload a file, etc.) with ftp, the problem occurs. But when I use identical code while switching everything to sftp, the problem disappears.

Unfortunately, I don't know the internals of ConnectionKit very well, but this distinction seems important. I'll hopefully get some time today to dive into it to see if there is any obvious problem, but I wouldn't bet on my skills.

from connectionkit.

Hi, sorry it's taken me a while to get back to this. Those instruments are appreciated, but what would be best for me right now is the simple Time Profiler one, if that's OK with you.

from connectionkit.

No worries at all. Here is the time profile: http://bit.ly/11FHGuo

from connectionkit.

Forgot to mention, here is the code that generated that profile (it's about as simple as it gets, because I was just testing something out):

NSURL   *destinationFile = [NSURL URLWithString:@"**Redacted**"];

NSURL   *file = [NSURL URLWithString:**Redacted**];
NSData *fileData = [NSData dataWithContentsOfURL:file];
CK2FileManager *fileManager = [[CK2FileManager alloc] init];
[fileManager setDelegate:(id)self];
[fileManager createFileAtURL:destinationFile contents:fileData withIntermediateDirectories:YES openingAttributes:nil progressBlock:^(NSUInteger bytesWritten, NSUInteger previousAttemptCount){

    NSLog(@"bytes - %li", (unsigned long)bytesWritten);
}completionHandler:^(NSError *error){

    if(error != nil){
        NSLog(@"error - %@",[error localizedDescription]);
    }  
}];

With the delegate method here:

- (void)fileManager:(CK2FileManager *)manager didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge{

NSURLCredential* credential;

credential = [NSURLCredential credentialWithUser:**Redacted**
                                        password:**Redacted**
                                     persistence:NSURLCredentialPersistenceNone];

[challenge.sender useCredential:credential forAuthenticationChallenge:challenge];
}

from connectionkit.

Think I'm starting to get a handle on this. libcurl hands us a timeout value which we're supposed to use for calling back into the library if no other events happen in that time. We schedule that timer with code like this:

dispatch_source_set_timer(timer, DISPATCH_TIME_NOW, self.timeout, self.timeout / 100);

Unfortunately, it looks like that DISPATCH_TIME_NOW setting is wrong, as it effectively tells GCD "call the timer immediately and then repeat at my timeout rate. This is actually part of the timer's event handler, so the timer is firing pretty much all the time! (and using lots of CPU in the process)

Time (ahem) then, to call in @samdeane. I think we want to readjust our code to be more along the lines of:

dispatch_source_set_timer(timer, dispatch_time(DISPATCH_TIME_NOW, self.timeout), self.timeout, self.timeout / 100);

so that the timer won't fire until self.timeout has elapsed. Sam, does that seem right to you? Perhaps we don't even want to make the timer repeat? In which case we should pass DISPATCH_TIME_FOREVER as the interval

from connectionkit.

Interesting. Is that why I see the nsurlconnectionloader thread persisting for no apparent reason after the ftp transaction is complete?

from connectionkit.

No, NSURLConnection's private thread is permanent and never dies. CK's FTP functionality does not use NSURLConnection anyway

from connectionkit.

Oh, ok. My bad. I'm pretty new to some of this stuff.

from connectionkit.

@ewrobinson Alright, give the latest v2.x-beta branch a go (make sure to update submodules too!). Should resolve the CPU issue.

from connectionkit.

After some prelim testing, it looks like the changes work perfectly. Thanks so much for the help!

from connectionkit.

Excellent!

from connectionkit.