Re: [openstack-dev] Reasoning behind my vote on the Go topic

[Michael Barton]

On Thu, Jun 9, 2016 at 2:49 PM, Clint Byrum  wrote:
>
> Agreed it isn't done in uvloop. But it is done in libuv and the uvloop
> devs agree it should be done. So this is the kind of thing where the
> community can invest in python + C to help solve problems thought only
> solvable by other languages.


I mean, if someone wants to figure out a file server in python that can
compete in any way with a go version, I'm totally down for rewriting swift
to target some other python-based architecture.

But personally, my desire to try to build a universe where such a thing is
possible is pretty low.  Because I've been fighting with it for years, and
go already works great and there's nothing wrong with it.

- Mike
__
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

Re: [openstack-dev] Reasoning behind my vote on the Go topic

[Michael Barton]

On Thu, Jun 9, 2016 at 9:58 AM, Ben Meyer  wrote:

>
> uvloop (first commit 2015-11-01) is newer than Swift's hummingbird
> (2015-04-20, based on
>
> https://github.com/openstack/swift/commit/a0e300df180f7f4ca64fc1eaf3601a1a73fc68cb
> and github network graph) so it would not have been part of the
> consideration.
>

And it still wouldn't be, since it doesn't solve the problem.

- Mike
__
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

Re: [openstack-dev] Why doesn't Swift cache object data?

[Michael Barton]

On Thu, Jun 25, 2015 at 7:35 PM, 杨苏立 Yang Su Li yangs...@gmail.com wrote:

 I guess that is an excellent answer on why does swift explicitly disable
 object data caching at the page cache level. But my question is a bit
 different Why doesn't swift use memcached to cache object data? Not that
 it is a bit different than implementing it yourself at the proxy server.
 All you need to do is to write a middleware to talk to the memcached
 cluster, and swift already does that for account info etc.


What's the logical difference between having object data in memory on a
memcache server and having it in page cache on an object server?  It's
architecturally similar, just memcache is fast and Swift is slow.

I've always thought we should just make Swift fast enough that a separate
caching layer isn't necessary.  We're mostly serving static files, and
nobody puts a cache in front of nginx.  (If you're from the future and
you're using EC, feel free to re-evaluate)

-- Mike
__
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

Re: [openstack-dev] [swift] Go! Swift!

[Michael Barton]

On Thu, May 7, 2015 at 7:05 PM, Adam Lawson alaw...@aqorn.com wrote:

 Chuck (and/or others who understand tor have experienced the limits of
 Python)

 I found this comment of yours incredibly intriguing: we are running out
 of incremental improvements that can be made with Python.

 Given your work with Swift thus far, what sort of limitations have you
 discovered that had to do specifically with the fact we're using Python? I
 haven't run into real-life limitations specific to a particular language
 before (I usually run into issues with my approach rather than limitations
 with the language itself) so i find this to be a fascinating (and perhaps
 accidental) consideration.



Well, Swift is sort of different from provisioning services like most
Openstack projects.  We handle hundreds of times as many requests as big
Nova installations, and the backend servers like this one handle some
multiplier on top of that.  Our users care a lot about performance because
it affects things like their page load times.

Then Python turns out to be kind of a bad choice for writing a
high-performance file server.  It's slow.  Its concurrency model really
punishes you for having workloads that mix disk and network i/o and CPU.
Swift's mix of worker processes, eventlet, and thread pools mostly works
but it's complicated and inefficient.  Blocking disk operations and
CPU-heavy tasks are still prone to either locking up event loops or
thrashing the GIL.

Python 3 and pypy would both make some aspects of that better, but not fix
it (yet).

- Mike
__
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