Katello - speeding up dev environment?

I don’t know if this has been looked into before, but have we looked into speeding up our dev environment?

Switching assets_debug to false can really help with UI performance, but sometimes you are doing work that requires UI changes and you really do feel the slowness of our dev environment. Even with it turned to false, it does feel like there is room for improvement.

I realize a lot of slowness can be chalked up to a large tech stack, but It would even be nice to do some benchmarking on typical workflows to see if there are any pain points, even if there are no immediate solutions.

I put Katello in the title since I assume we have the slower dev environment, but obviously, any Foreman enhancements would help us as well. Curious to hear any thoughts or if anyone has any suggestions on where to start investigating.


I wasn’t aware of assets_debug til now. Would it be OK it make it the default for the forklift dev machine, and add something to the motd to tell people its on?

Without it, each page takes 15-20 seconds to load (when they load at all). This makes dev work slow, and makes the new contributor experience less pleasant.

I strongly agree in general that the dev environment has a few issues right now. The issues I’ve seen are:

  • slow page loads
  • pages that do not load until you restart your webpack + rails servers
  • postgres DB disconnection errors
  • browser console errors and warnings

New contributors don’t have enough experience with the dev environment to know which issues are their own doing, so it’s important to make things run as smoothly as possible with a fresh dev install.

1 Like

@beav good to hear I’m not alone having these concerns :slight_smile:

I’m not sure about default because you need this off to do front-end non-webpack development (someone correct me if I’m off about this). I would lean more towards documenting it well in our developer documentation.

Ideally, we can identify what the page loading pain points are when assets_debug is on and improve things if possible.

To start, we should probably find a way to benchmark what is taking so long. For instance, I’m not sure if things are slow server-side or client-side, or is it Rails, Angular, webpack, SQL, etc? If someone from @katello is willing to take a some time to walk through what happens on a typical page load with me and/or has any idea on how to benchmark parts of our stack, that would be really helpful.

Just to give an example that there is room for improvement in areas, I was playing around with benchmarking webpack one day and was able to shave a few seconds off with some small changes. I can dig this up and make a PR.

For the other “messy dev env” concerns like console errors and dropped connections, I suggest we make issues as you come across them and keeping track of them somewhere (this thread or a tracker perhaps), then try to work into team sprints.

1 Like

@John_Mitsch I put in https://github.com/theforeman/puppet-katello_devel/pull/174 which should help with the postgres DB errors at least.

For benchmarking, I usually just look at the network tab in the browser plus the rails log, but there is probably a better way.

1 Like

I was not quick enough when keying in issues and cannot edit my old post :turtle:.

Bug #24826: (dev env) lots of “[WDS] Disconnected!” errors in browser console - Katello - Foreman is for the “[WDS] Disconnected!” issue.

1 Like

We also didn’t merge the multi-threaded PR until just now. That probably also helps a lot:



Wow, this is a huge speedup. :rabbit2:

If you have an existing dev environment, the change can be applied like so:

edit ~/foreman/.env and add RAILS_STARTUP="puma -w 5 -p $PORT --preload" to the end of the file, then re-run foreman start.

Note that you’ll need to use pry-remote instead of pry when debugging.

Thanks @ekohl and @stbenjam for the PR and for the instructions above!

1 Like

I’ve noticed another thing that slows down the environment is Foreman’s notifications polling. Ostensibly there’s an environment variable to adjust the value, but I don’t think anyone’s gotten that to work?

It seems to work for me, but it seems something requires a restart
before using as I end up having to reboot to get the changes to ‘work’.
restarting spring itself doesn’t seem to do it. I’ve not really
debugged further.