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

101–110 of 125 posts

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

#101

Post by jpgvm »

mbrock wrote: post #81
qaq wrote: post #73

Earlier quoted context omitted.

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

Why isn't it intended use? And are there actual problems with it even if it isn't intended use?

It's not intended use because fsyncing every write to disk makes it inferior to every datastore designed to fsync every write. See here PostgreSQL.

For read performance if your dataset fits in memory PG is just as fast as Redis.

The main attraction of Redis is in-memory writes with async persistence. Trading durability and availability for the increased performance. If you give up this then there is precisely 0 reasons to choose Redis over PostgreSQL.

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

#103

Post by anarazel »

jpgvm wrote: post #101
mbrock wrote: post #81

Earlier quoted context omitted.

Why isn't it intended use? And are there actual problems with it even if it isn't intended use?

It's not intended use because fsyncing every write to disk makes it inferior to every datastore designed to fsync every write. See here PostgreSQL. For read performance if your dataset fits in memory PG is just as fast as Redis. The main attraction of Redis is in-memory writes with async persistence. Trading durability and availability for the increased performance. If you give up this then there is precisely 0 reaso…

> The main attraction of Redis is in-memory writes with async persistence.

FWIW, you can have that in postgres as well, cf. synchronous_commit = off

> Trading durability and availability for the increased performance. If you give up this then there is precisely 0 reasons to choose Redis over PostgreSQL.

As a PostgreSQL developer, I'd say that performance / latency / jitter can still be reasons to choose redis over postgres. The per-read overhead in redis is often a good bit lower than in postgres, and there's less variability in response times.

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

#104

Post by anarazel »

qaq wrote: post #73
calcifer wrote: post #70

Earlier quoted context omitted.

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

My experience is actually that you'll often get a lot worse performance with redis if you enable durability. The reason being that postgres can batch several connection's/session's transaction commit fsyncs together, which IIRC redis can't.

(Disclaimer: Postgres guy, so I'm likely not impartial)

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

#105

Post by Svenskunganka »

fweespeech wrote: post #74
Svenskunganka wrote: post #24

Earlier quoted context omitted.

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.

Have you even read the article? This was caused by Mongo running with a wrong flag, and the authors explicitly said that their backup script only contained ONE backup. That's bad engineering, not fault with Redis. Redis is extremely safe if you configure it correctly.

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

#106

Post by fishnchips »

vardump wrote: post #95
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.

The world is not only about CRUD apps with a database backend.

A surprisingly large part of the world is about CRUD apps. And among the non-CRUD apps a surprisingly large part of them is still CRUD.

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

#107

Post by valyala »

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.

There are a plenty of in-process 'databases' for Go starting from a simple built-in map and ending with something like https://github.com/boltdb/bolt or even https://github.com/hashicorp/go-memdb .

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

#108

Post by insertnickname »

nemothekid wrote: post #89
insertnickname wrote: post #36

Earlier quoted context omitted.

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…

> 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 FWIW, these cases don't come down to raw rq/s performance, but are more due to RAM usage.

In the iron.io blog post, they write that their CPU load was drastically reduced as well.

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

#109

Post by valyala »

amelius wrote: post #79
gummiruessel wrote: post #62

Earlier quoted context omitted.

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 ...

See the benchmarks https://www.techempower.com/benchmarks/#section=data-r12&hw=... .

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

#110

Post by ricardobeat »

StreamBright wrote: post #15

Any time I see a chart about web server performance without displaying the corresponding error rate and latency numbers I start to think that the author does not understand the performance aspect of HTTP services entirely.

Error rate? I believe when doing http benchmarks it is assumed to be zero.
Post reply on HN