Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Iris: Fast back-end web framework for Go

iris-go.com

Post reply on HN
Print view View original

71–80 of 125 posts

Re: Iris: Fast back-end web framework for Go

#71

Post by benbjohnson »

Bombthecat wrote: post #18
mappu wrote: post #3

The performance comes from using https://github.com/valyala/fasthttp instead of the stdlib net/http. From this project's FAQ: >Why creating yet another http package instead of optimizing net/http? Because net/http API limits many optimization opportunities.

And then you got your database and you speed is comparable to the rest of the world :) What I think could work is a pure in memory database with server combination. Something like redis for websites.

I've been using a local key/value store as my backing database and it works great. Primary key access is usually less than 1µs and net/http is typically my bottleneck.

That being said, unless you're getting a massive number of requests, using a specialized HTTP library seems like overkill.

Re: Iris: Fast back-end web framework for Go

#72

Post by fulafel »

andkenneth wrote: post #35
oneloop wrote: post #23

Could someone clarify: why is Go faster than say Python? And if the answer is just that it's a lower level language and therefore has less overhead, why not just use C?

Go has high level constructs like python, C# or Java. However, it compiles down to machine code directly, like C. This is much faster than C# or Java, which compile to an intermediate interface (CLR and java bytecode respectively, which then run in a VM), and miles ahead of Python, which interprets from the source every single time the program is run. The closest language to go would probably be C++, and the language…

Compiling Python down to machine code and eliminating the VM interpreter loop does not speed it up dramatically (iirc ~30%), it has been tried. It's largely because Python is a dynamically typed language with a lot of runtime dispatch, and Go is a statically typed language with less runtime dispatch.

Re: Iris: Fast back-end web framework for Go

#73

Post by qaq »

calcifer wrote: post #70
qaq wrote: post #61

Earlier quoted context omitted.

"it has data persistence reliability on par with Postgres" if we pretend transactions do not exist and postgres is running in some non-default config then maybe, but we don't need to pretend.

Redis has transactions as well.

yes and if you set appendonly yes appendfsync always you will get about +/- PG write performance without all the features Now I know 0 production projects using these Redis settings and I would argue it's not intended use of Redis same way as running PG with fsync = off is not generally what you want to use

Re: Iris: Fast back-end web framework for Go

#74

Post by fweespeech »

Svenskunganka wrote: post #24
Bombthecat wrote: post #18

Earlier quoted context omitted.

And then you got your database and you speed is comparable to the rest of the world :) What I think could work is a pure in memory database with server combination. Something like redis for websites.

I use Redis as the primary and only database. This results in quite large savings in terms of server infrastructure since memory has never been cheaper than it is today and the minimal amount of resources Redis consume in relation to the massive amount of throughput it provides. Additionally, it has data persistence reliability on par with Postgres and other battle-tested databases[0], so couldn't be happier about th…

https://muut.com/blog/news/april-2014-service-failure.html

https://muut.com/blog/technology/redis-as-primary-datastore-...

Counter point of a real world implementation where they tried to make it the primary data store.

Re: Iris: Fast back-end web framework for Go

#75

Post by jerf »

scandinavian wrote: post #33
insertnickname wrote: post #26

Earlier quoted context omitted.

Go actually lets you work at a quite high level, much like C# or Java (and the performance is in the same ballpark). I think a better question to ask is: why is Python so slow?

Python is not slow, cPython is slow. PyPy is pretty fast.

PyPy is pretty fast... for a Python runtime. It's not "fast" without qualifiers. The only 1990s-style dynamic language runtime that's fast-without-qualifiers is LuaJIT.

Re: Iris: Fast back-end web framework for Go

#76

Post by SEJeff »

oneloop wrote: post #53
insertnickname wrote: post #26

Earlier quoted context omitted.

Go actually lets you work at a quite high level, much like C# or Java (and the performance is in the same ballpark). I think a better question to ask is: why is Python so slow?

Ok, so why is Python so slow (comparatively)? I had understood that must of the speed-critical tasks in python were done by wrappers of lower-level C code. Example: numpy. Is this not correct?

FWIW: There is a new set of async / await bits in CPython 3.5 that are allowing some really interesting new performance profiles.

http://magic.io/blog/uvloop-blazing-fast-python-networking/

This is almost exactly on par with golang's net/http for a simple echo server, yet it is written in python.

Re: Iris: Fast back-end web framework for Go

#77

Post by stirner »

spriggan3 wrote: post #30
stirner wrote: post #9

Not only is this page riddled with typos that lead me to doubt the quality of the code, the concept of a framework is fundamentally complex and at odds with the goals of Go.

> Not only is this page riddled with typos I'd argue that at least the author tried to write a real documentation, which 95% of Go library authors don't do. > the concept of a framework is fundamentally complex and at odds with the goals of Go The famous "You don't need that with Go ™ ". It's more like Gophers hate the word "framework","dependency injection" and "orm". It's hardly a framework, it's a router and a mid…

I didn't mean to hate, shame, or mock anyone. I would rather that programmers who create complex antipatterns stay in other languages that encourage them, and if light critique has that side effect, so be it.

Re: Iris: Fast back-end web framework for Go

#78

Post by andybak »

insertnickname wrote: post #36
andybak wrote: post #32

Earlier quoted context omitted.

Alex Gaynor had an interesting take on this - https://speakerdeck.com/alex/why-python-ruby-and-javascript-... From what I remember - even leaving aside core language speed - the idioms of certain languages lead people to write slow data structures and algorithms. You can write (much) faster Python but it might start to look un-Pythonic. But of course there is the counter-argument - if your web framework is your bottl…

There are tons of blog posts about companies that have switched from Ruby or Python to Go and have been able to massively scale down their amount of servers while handling the same load. Here's one example: https://www.iron.io/how-we-went-from-30-servers-to-2-go/ I don't think it's weird that the web server could be a bottleneck in a web application (even if it is a database-driven app, as most are). Of course, if yo…

I suppose 'weird' wasn't the right word but the vast majority of web development probably isn't constrained by the performance of the language.

> if you're making an internal CRUD app that two people are going to use

I know you're exaggerating for comic effect but still. You can run sites that have millions of visits a day on a $20/month VPS and still not have to worry about performance - unless you're doing something completely resistant to caching. I don't personally know anyone that has to handle more traffic than that but if you believed the general chatter on HN then that segment of the market doesn't even exist. Going from 30 servers to 2? I might be able to cut my overall hosting bill by a few hundred dollars a year but it's not top of my list of concerns.

Re: Iris: Fast back-end web framework for Go

#79

Post by amelius »

gummiruessel wrote: post #62
mappu wrote: post #3

The performance comes from using https://github.com/valyala/fasthttp instead of the stdlib net/http. From this project's FAQ: >Why creating yet another http package instead of optimizing net/http? Because net/http API limits many optimization opportunities.

It's worth noting that fasthttp doesn't support HTTP/2.0. According to the README, there are plans for it in the future.

Hmm, thus not so fast after all ...
Post reply on HN