Very slow. Why by default in a new app?

[frederikhors]

This is extremely slow and it is a pity this is a default in a new Gobuffalo app (until performances increase...).

Can I understand why this is the default?

If I comment default lines in app.go Buffalo is much faster!

// app.Use(popmw.Transaction(models.DB))

Beego and others doesn't have transaction manager like this by default.

Is this also like Rails ActiveRecord behaviour?

I'm using just this code for some perf tests using in a new project just one resolver:

var player models.Player
if err := models.DB.Last(&player); err != nil {
  return &player, fmt.Errorf("no selected player")
}
return &player, nil

[mclark4386]

It's the default, IIRC, because a) rails has ActiveRecord going by default and part of the inspiration for buffalo is rails and b) most web app need a db component and pop is the one that mark built specifically for buffalo. Please feel free to use --skip-pop in the app creation or to skip the middleware for handlers/actions/routes/groups you don't need/want it for! ( https://gobuffalo.io/en/docs/middleware#skipping-middleware )

[stanislas-m]

This is extremely slow and it is a pity this is a default in a new Gobuffalo app (until performances increase...).

You can't say something like that without providing some numbers. Very slow is subjective and means nothing. :)

[frederikhors]

You can't say something like that without providing some numbers. Very slow is subjective and means nothing. :)

You're right. I don't have time now for pushing projects, but:

buffalo new appName:

• add new Player model
• add new controller with the code in first post (I will paste below)
• migrate db
• use vegeta (https://github.com/tsenart/vegeta)
• results:
• • disable all but popmw-transaction: mean 30ms
• • disable all in main file (including popmw-transaction): mean 9/10ms

Same code and same db (pq) with beego new appName: results w/ vegeta: mean 3ms

var player models.Player
if err := models.DB.Last(&player); err != nil {
  return &player, fmt.Errorf("no selected player")
}
return &player, nil

[u007]

@frederikhors ive the same issue, i dont recommend using pop transaction middleware. in many of my cases, connection did not close properly and causing db connection to go beyond my cloud server provided

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment. Otherwise, this will be closed in 7 days.

[sio4]

First, this issue is interesting. Performance is one of the important factors for developers even though not all developers are working on a performance-sensitive application (but still they are looking for that) and sometimes productivity with reliability "out of the box" could be better for (maybe) many developers.

Anyway, the interesting part is the following:

If I comment default lines in app.go Buffalo is much faster!

// app.Use(popmw.Transaction(models.DB))

In the Buffalo way, in other simple words the controller generated by buffalo g controller or buffalo g resource, the code cannot run without the above line since they use tx, ok := c.Value("tx").(*pop.Connection). If the middleware is disabled, there is no tx in the context and the controller will return an error. So the above description is odd to me.

After reading the original post and the additional reprod steps further, it seems like I found the reason. The controller uses models.DB directly without using transaction, regardless if the middleware is enabled or not, so the middleware actually does nothing for the Last() even when it is enabled, but just made an additional empty transaction (with locking). So what happened on your test was using two connections (with locking) for every single request.

var player models.Player
if err := models.DB.Last(&player); err != nil {
  return &player, fmt.Errorf("no selected player")
}
return &player, nil

The concept of pop middleware is great. It provides database transactions transparently, so developers can just focus on the business logic then the transaction commit or rollback will be done by the middleware automatically. Also, the middleware provides timing information on the log, which is also useful.

By the way, one of my recent questions regarding Pop in my mind was how can we have better visibility on connection pool usage/management so I feel like this issue is a good input for developing the question. Also, another question was how to prevent a transaction for a non-database-related request or how to reduce the duration of a transaction.

I will keep this issue in mind once I started on the work. (I will close this issue once I open separate issues for those)

[sio4]

Oh, it looks like #28 is clearly explaining the situation of the performance issue that happened when using models.DB directly while pop middleware is enabled.