search

adib / google-toolbox-for-mac

Automatically exported from code.google.com/p/google-toolbox-for-mac
Apache License 2.0
0 stars 0 forks source link

GTMHTTPServer's memory usage is not optimal when receiving large chunks of data #18

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Create a simple server app using GTMHTTPServer
2. Sends some 1 MB of data
3. The app will have a peak memory usage of 1 GB.

What is the expected output? What do you see instead?
The memory usage should be low.

What version of the product are you using? On what operating system?
Mac OS X 10.5.

Please provide any additional information below.
The problem is that -[GTMHTTPServer dataAvailableNotification:] creates new 
instances of 
NSData/CFData in various places (incl. when appending data to HTTP message by 
calling CFHTTPMessageAppendBytes). When there are a succession of received 
notifications, autorelease 
pool may not be drained timely, and the accumulated NSData/CFData objects start 
to choke.

A proposed fix is attached as follows. By adding an autorelease pool and by 
draining it at various 
exit points in -[GTMHTTPServer dataAvailableNotification:], the memory usage is 
now brought 
under control.

(Side note: the server can still be extremely slow when receiving body whose 
size > 2 MB)

Original issue reported on code.google.com by lukh...@gmail.com on 14 Apr 2009 at 8:49

Attachments:

GoogleCodeExporter commented 9 years ago 
Thanks for the patch.

Since the server is meant mainly as an aid for doing unittests, we haven't 
really worried about its performance for 
things like this, but I'll look at getting the improvements in.  I also need to 
finish up some unittests for it, so I'll 
try to get some cycles for that soon.

Original comment by thoma...@gmail.com on 17 Apr 2009 at 2:23

GoogleCodeExporter commented 9 years ago 
Not a problem! I understand the design goal behind this simple but nifty 
utility. Interestingly, that's also how I 
found the issue—a program that tests my client-side code's ability to send 
large chunk of data ran extremely 
slow, and turned out the test itself consumed huge amount of memory, and hence 
the discovery.

Thanks for the good work!

Original comment by lukh...@gmail.com on 17 Apr 2009 at 4:32

GoogleCodeExporter commented 9 years ago 
Forgot to ask, do you have an easy way to do up a test consuming a large amount 
of data?

Original comment by thoma...@gmail.com on 30 Apr 2009 at 2:07

GoogleCodeExporter commented 9 years ago 
fix landing shortly.

Original comment by thoma...@gmail.com on 30 Apr 2009 at 12:56

GoogleCodeExporter commented 9 years ago 
Hi,

Please take a look at http://github.com/lukhnos/objectiveflickr/

Then use the Xcode project in 
LFWebAPIKit/Tests/StreamedBodySendingTest/StreamedBodySendingTest.xcodeproj, 
which can be built 
independently. Then profile the memory usage by running the app and fire the 
sample request. (Modify the 
testButtonAction: in AppDelegate.m to make the request data larger). When the 
size exceeds 2 MB, even 
Activity Monitor can tell it's choking with too much temp objects.

Glad to know that the fixing is landing. Much appreciated!

Original comment by lukh...@gmail.com on 30 Apr 2009 at 1:11