On Fri, Sep 29, 2017 at 6:35 AM, Arnaud MORIN <arnaud.mo...@gmail.com> wrote: > My objective is to be able to download and upload from glance/computes to > swift in a faster way. > I was thinking that if glance could parallelizes the connections to swift > for a single image (with chunks), it would be faster. > Am I wrong ? > Is there any other way I am not thinking of? > > Arnaud.
Lets take an example, image download as everyone wants their instances booting really quickly. We have a cold image. What happens now is Nova requests the image from Glance, glance-api requests the bits from Swift and streams it through to Nova. If you have caching enabled in Glance (which should be your first point of improvement to get you hot images quickly), the glance-api will tee that data to it's local cache, where the later requests will be served from. If your Swift and networking between Glance and Swift are scaled appropriately, I have hard time believing that you would get performance improvement by waiting Glance first caching all the segments, composing them back to an image and then sending that image over to Nova. Your really hot images will be delivered directly from Glance cache anyways easing the load on Swift. Then we look image upload. We're again on the same situation, currently we stream the image to Swift as soon as we start receiving the bits from the client. With your proposal to gain any benefit we would need to have Glance caching basically the first segment x the number of threads amount of data we are using before we initiate the upload to swift and the upload to glance would need to be able to keep up with the swift sink not just throttling the connections there. Based on the real world data we've seen so far user clients suffer rather slow connection to their Glance nodes than Glance throttling their transfers down due to Swift not keeping up. Now lets say we have 10 concurrent image operations per glance-api node which of 7 is actually interfacing with the swift. The proposed multi threading would put totally different scaling pressure to the Glance nodes just for example cope with all this short term caching that needs to happen. That needs either ridiculous amounts of memory or array of very fast disks. Do you have any data you can share that would show us getting the performance boost worth of the overhead cost? Just remember the connection between Glance and the client (that being user, nova, cinder...) is > > Le 28 sept. 2017 6:30 PM, "Erno Kuvaja" <ekuv...@redhat.com> a écrit : >> >> On Thu, Sep 28, 2017 at 4:27 PM, Arnaud MORIN <arnaud.mo...@gmail.com> >> wrote: >> > Hey all, >> > So I finally tested your pull requests, it does not work. >> > 1 - For uploads, swiftclient is not using threads when source is given >> > by >> > glance: >> > >> > https://github.com/openstack/python-swiftclient/blob/master/swiftclient/service.py#L1847 >> > >> > 2 - For downloads, when requesting the file from swift, it is >> > recomposing >> > the chunks into one big file. >> > >> > >> > So patch is not so easy. >> > >> > IMHO, for uploads, we should try to uploads chunks using multithreads. >> > Sounds doable. >> > For downloads, I need to dig a little bit more in glance store code to >> > be >> > sure, but maybe we can try to download the chunks separately and >> > recompose >> > them locally before sending it to the requester (compute / cli). >> > >> > Cheers, >> > >> >> So I'm still trying to understand (without success) why do we want to >> do this at all? >> >> - jokke >> >> > >> > On 6 September 2017 at 21:19, Arnaud MORIN <arnaud.mo...@gmail.com> >> > wrote: >> >> >> >> Hey, >> >> I would love to see that reviving! >> >> >> >> Cheers, >> >> Arnaud >> >> >> >> On 6 September 2017 at 21:00, Mikhail Fedosin <mfedo...@gmail.com> >> >> wrote: >> >>> >> >>> Hey! As you said it's not possible now. >> >>> >> >>> I implemented the support several years ago, bit unfortunately no one >> >>> wanted to review it: https://review.openstack.org/#/c/218993 >> >>> If you want, we can revive it. >> >>> >> >>> Best, >> >>> Mike >> >>> >> >>> On Wed, Sep 6, 2017 at 9:05 PM, Clay Gerrard <clay.gerr...@gmail.com> >> >>> wrote: >> >>>> >> >>>> I'm pretty sure that would only be possible with a code change in >> >>>> glance >> >>>> to move the consumption of the swiftclient abstraction up a layer >> >>>> from the >> >>>> client/connection objects to swiftclient's service objects [1]. I'm >> >>>> not >> >>>> sure if that'd be something that would make a lot of sense to the >> >>>> Image >> >>>> Service team. >> >>>> >> >>>> -Clay >> >>>> >> >>>> 1. >> >>>> https://docs.openstack.org/python-swiftclient/latest/service-api.html >> >>>> >> >>>> On Wed, Sep 6, 2017 at 9:02 AM, Arnaud MORIN <arnaud.mo...@gmail.com> >> >>>> wrote: >> >>>>> >> >>>>> Hi all, >> >>>>> >> >>>>> Is there any chance that glance can use the multiprocessing from >> >>>>> swiftclient library (equivalent of xxx-threads options from cli)? >> >>>>> If yes, how to enable it? >> >>>>> I did not find anything useful in the glance configuration options. >> >>>>> And looking at glance_store code make me think that it's not >> >>>>> possible... >> >>>>> Am I wrong? >> >>>>> >> >>>>> Regards, >> >>>>> Arnaud >> >>>>> >> >>>>> >> >>>>> >> >>>>> __________________________________________________________________________ >> >>>>> OpenStack Development Mailing List (not for usage questions) >> >>>>> Unsubscribe: >> >>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >>>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> __________________________________________________________________________ >> >>>> OpenStack Development Mailing List (not for usage questions) >> >>>> Unsubscribe: >> >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >>>> >> >>> >> >>> >> >>> >> >>> >> >>> __________________________________________________________________________ >> >>> OpenStack Development Mailing List (not for usage questions) >> >>> Unsubscribe: >> >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >>> >> >> >> > >> > >> > >> > __________________________________________________________________________ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
