DEV Community: Ben Potter

Achieving low latency remote development

Ben Potter — Mon, 14 Mar 2022 13:17:21 +0000

Remote IDEs bring speed and productivity benefits to software teams. Server-class machines lead to faster performance and reduced cycle time between changing code and seeing the result. For developers, this means faster onboarding and less time troubleshooting environments.

However, it’s important to make remote IDEs feel as fast, if not faster, than local machines. In this post, we’ll cover latency.

Latency hinders flow

As demonstrated by a typing latency simulator, delays immediately impact your productivity. Even with powerful servers, a reliable connection is just as important.

In this post, we’ll refer to “latency” as the connection delay between the developer (client) and workspace (server), and not operations inside the workplace itself (compiles, builds, tests) as those are unaffected by the user’s internet speed.

Let’s take a look at how we can tune remote workspaces to have the “snappy” experience we know and love.

Optimize your infrastructure

First, we recommend using servers close in proximity to your developers! 🌎

At Coder, we have a distributed engineering team. Our developers can pick between servers in the United States, United Kingdom, Spain, Australia for the optimal experience. If engineers join from another location, we can quickly deploy another workspace provider in that region to support them.

If you are using a managed development platform, this is not something you can control. If geolocation and network speeds are important to you, self-hosting with your workspaces is advised. You can use software such as Coder, Gitpod, or a homegrown solution.

Use remote IDEs, when possible

If you’re developing through a virtual desktop solution (e.g VDI, RDP, VNC), the overhead from streaming an entire desktop environment will often result in additional latency.

Whenever possible, we recommend using native IDEs (web-based or desktop). With VS Code and JetBrains remote development extensions, you can develop directly on remote workspaces with low latency.

If you still need to access desktop-only apps, you can still use your virtual desktop to complement your IDE, potentially all through the same workspace.

If you need fast remote desktop access, Parsec is an emerging tool to keep an eye on. At the time of writing, it only supports Windows and macOS hosts.

Use direct connections, whenever possible

Reducing proxies and network hops provides users a snappier and more reliable experience, which is why we went through the effort of implementing a peer-to-peer network architecture in Coder. As a result, we have achieved a 68% latency reduction, as measured by our workspace ping utility (61.23ms to 29.92ms) for our internal developer workspaces.

While your own performance improvement may vary depending on your network topology, in general, reducing the number of network hops and the physical distance between your computer and the server will reduce your perceptible latency.

Improving SSH responsiveness

For those who prefer to use vim/terminals development, mosh is a great tool for reducing perceived latency in SSH connections.

Mosh particularly comes in handy if you are on a limited internet connection, or if you’re far away from the data center.

What about offline mode?

You may find yourself in cases where you’d like to access your workspace without a stable internet connection, such as on an airplane.

We plan to cover this in a dedicated blog post, but our general recommendation is to define your remote workspaces with non-proprietary tools. With Dockerfiles, devcontainers, or standard VM images, you can optionally run your environments on local machines for an, albeit slower, offline development experience. Once an internet connection is restored, you can sync files back to your remote workspace.

Coder: self-hosted developer workspaces

If you’re serious about moving software development to your infrastructure, we’d love to chat. You can also install Coder for free and try it yourself.

Faster JetBrains IDEs with shared indexes

Ben Potter — Sun, 02 Jan 2022 21:53:11 +0000

If you develop with IntelliJ IDEA, PyCharm, GoLand, or other JetBrains IDEs, it’s likely you’ve waited for “indexing” to complete after opening a project. While this may be annoying, it’s necessary for IntelliJ and other heavy-weight IDEs to have features such as code search, highlighting, refactoring, and code completion.

Waiting for an IDE to finish indexing a project might not be a big problem for many workflows. After the first load, indexes are cached and subsequent runs are faster. However, indexing time can be a huge blocker for developers, especially in these cases:

large projects (monorepos, many dependencies, monolithic applications)
running old/slow machines (indexing is CPU-intensive)
ephemeral developer workspaces (containers, remote IDEs)

In this post, we’ll cover how shared indexes can significantly reduce IDE load times, share some examples, and a one-line command to generate these for your project. (Historically, shared indexes have been difficult to set up)

First, how indexing works

Indexing works by traversing the project’s codebase to create a “virtual map” of classes, methods, and objects for future lookups. After the index is generated, it is cached on your device for later use.

Indexing a codebase will likely take the longest the first time you open it on your machine. When the codebase changes, such as pulling code or switching branches, your indexes will “update,” but significantly faster than the first time.

Shared indexes ⚡

Shared indexes make it possible to host pre-generated indexes for others to download, significantly improving loading speeds across your team. These remote indexes work in conjunction with local indexing to ensure your IDE always has up-to-date information on the codebase.

GIF: Loading the code-server project in WebStorm

Generating shared indexes for your project

JetBrains has a guide for creating shared indexes, but it involves many steps, including downloading custom tooling and uploading indexes to a CDN. It also lacks instructions for automating this process, to generate indexes in CI, for example.

Using a Docker container to generate shared indexes makes it simple to try locally or automate with cron/CI:

cd your_large_codebase/

# generate shared indexes
docker run -it --rm \
  -v "$(pwd)":/var/project \
  -v "$HOME"/indexes-output:/shared-index \
  -e INDEXES_CDN_URL=https://cdn.myserver.com/project \
    -u "$(id -u):$(id -g)" \
  bencdr/indexer:idea-2021.3

After generating indexes, you can upload the output folder to your CDN, or a local server. You can also use shared indexes without a CDN by using a network share or even your local filesystem for testing. Check out my GitHub repo for details:

bpmct / jetbrains-indexer

Generate & package JetBrains shared indexes with a Docker container.

Benchmarking shared indexes

I tested indexing time for some popular projects on my 2019 MacBook Pro. To benchmark your own projects, File → Invalidate Caches in your IDE will allow you to opt in/out of downloading shared indexes to simulate first launching your project.

Project	Language(s)	Local indexing 🐌	With shared indexes ⚡	Improvement %
kubernetes/kubernetes	Go	2m 40s	22s	727%
cdr/code-server	Typescript	2m 30s	34s	441%
Coder internal monorepo	Go & Typescript	3m 20s	32s	625%
jetbrains/intellij-community	Java	6m 30s	2m 15s	288%

These times were averaged across two test runs. Your mileage will vary depending on network speeds, device performance, etc.

Remote development & shared indexes

Recently, JetBrains released remote development support, making it simple to develop from powerful, remote workspaces. On-demand workspaces have a lot of benefits, such as faster onboarding and better reproducibility. However, first-time indexing happens much more frequently, since, after all, workspaces are meant to be ephemeral.

Shared indexes work with Coder, our remote development platform. Coder supports all JetBrains IDEs locally, or via the web browser. If you don’t want to host a CDN for shared indexes, you can include them in the workspace image, so everything loads in a snap ⚡

If you’d like to learn more about Coder, you can request a demo or try it for free.