[email protected] wrote:
>>> At least on the client side, we don't need streaming for files or
>>> manifests.  Why is this enabled serverside?  Does the depot still print
>> I'm not sure what you mean about the "why".
> 
> I'm asking why you set 'response.stream' to True for the manfiest_0 and
> file_0 cases.  I'm assuming you had a reason for doing so.
> 
>>> functionality to guard against corruption until we have manifest
>>> signing.  Does setting streaming to True have any performance impact on
>>> pkg client performance?
>> In theory, it should be better.  We may not be able to tell a difference 
>> with an Apache proxy in front.
> 
> Did you make any measurements one way or the other?
> 
>> In retrospect, manifest probably isn't is a prime candidate for 
>> streaming, but I believe file is given the cherrypy admonition about 
>> "pages which take many minutes to produce."
>>
>> Also, I would think it would make sense to stream files, since we 
>> wouldn't want the server to buffer an entire 1GB file before sending it 
>> out; it should just send the file as it reads it (streaming).
> 
> http://www.cherrypy.org/wiki/ReturnVsYield
> 
> I agree that server memory usage is a concern; but the manifest_0 and
> file_0 routines call serve_file() instead of yield.  The serve_file code

Returning serve_file() instead of yield is fine as long as serve_file() 
yields or returns a generator object.

> looks like it only yields when processing multipart/byterange requests.
> It's not clear to me why we're setting response.stream to True in these
> cases, if our code isn't actually calling yield.  I'm assuming that the
> internal CherryPY routine knows how to do the right thing, regardless.
> Are you saying that assumption is incorrect?

It's supposed to stream the response if you set response.stream: True. 
However, there is some question whether this is working properly:

http://www.cherrypy.org/ticket/696

 From what I can tell though, it should be streaming the response since 
serve_file() returns a file object, which the wsgi server then calls 
encode() on.  Encode then sees that response.stream is True, and begins 
yielding the body in chunks.

However, when I just tested this, it doesn't appear to ever give a 206 
response.  So, I can only hope that bug is resolved soon.

As far as "recommendations"; the cherrypy folks don't recommend using 
cherrypy for serving files as Apache, etc. is far better at doing it.

Cheers,
-- 
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

Reply via email to