I wanted to give some feedback about the new cryoSPARC v5 beta user interface and would be curious how others experienced it. Our upgrade process went quite smoothly, and we had no issues with jobs or performance, which is great!
However, I noticed that the new cryoSPARC v5 user interface appears to be slower compared to v4.7. Of course, I don’t have benchmarks to validate this, and this is more of a “how snappy does it feel”.
I frequently run into the issue that I have to reload the website after creating a new job (cloning or “new job” does not matter). If I don’t reload the website, it can take minutes until the job appears in the workspace. The same applies to clearing or deleting a job, it takes quite a while until it updates in the workspace unless I reload the website. I observed this behaviour in Safari as well as Chrome. My working computer is M3 Max MacBook, so not the slowest machine. The database is on a Zen 4 Threadripper workstation with Gen5 Nvme SSD that is rougly 65% filled.
Besides feeling slower, the power consumption of my MacBook also went significantly up. The cryoSPARC web server was never really power saver-friendly, but now I observe that I can utilize 40-50% of my MacBook CPU for extended periods of time.
As a last point, would it be possible to implement a toggle or CLI command that allows us to change whether the new dashboard or the previous event log is shown by default when opening a job on per user level? Although I like the new dashboard, for some jobs the event log is faster to get the important information by just scrolling a bit, and it is easier to use when no bigger display is available.
We also experience some of the glitchiness you describe, where cards get stuck when deleted or don’t display without reload, or page gets hung on dashboard when you’ve moved on etc. Interesting to hear about power consumption change
Hi @OleUns , thanks for your feedback! What you described is definitely unexpected behaviour and has not been reported by any other private beta (and now public beta) users, so we’d like to get to the bottom of this.
As with all CryoSPARC releases, our goal is to deliver feature and performance improvements, not regressions. A great deal of work was done on the application to improve data loading and overall performance, alongside a rebuilt backend system that forms the core of CryoSPARC’s software architecture. Although everything you interact with in the application is accessed through a browser (or client), there are two distinct components that could be responsible for underlying performance issues:
The application code, logic, and interactive elements that make up the interface (running on your local machine via the browser).
The software component (API) running on the system where CryoSPARC is installed, which manages tasks such as job orchestration and writing information to the database. The application communicates with this component over the network.
What you’ve described—glitches, slowness, or delays when performing actions such as creating, cloning, and deleting jobs (even across different browsers)—suggests that there may be an issue related to the network or the software side of your particular installation.
To help us better understand what may be going wrong, it would be useful to inspect the logs. Could you please email us the tgz file created by the command cryosparcm snaplogs? I’ll send you the email address in a private message.
In addition, could you please describe how you are connecting to CryoSPARC? For example, are you using SSH port forwarding, a custom URL set up by your institution, or a direct IP:port connection?
Regarding power consumption and CPU utilization on the machine running the browser interface: this is not something that other users have reported, nor something we have encountered before. It would be very helpful if you could provide more details about which pages you are on or which actions you are performing when this occurs so that we can attempt to reproduce the behaviour.
Of course. The cryoSPARC master is running on an Ubuntu 24.04.04 LTS workstation with 512GB RAM, AMD Threadripper 7965W, and a 2TB Gen5 NVMe SSD on which the database is stored. The cryoSPARC projects are stored on 8-bay QNAP file servers without SSD caching. The master, almost all workers, and the file server are connected to each other via 10 GB networking in a local network. The 10GB networking is isolated from the institutional network and communicates with the institutional/global network with a router. We access the cryoSPARC interface using Tailscale and IP:port connections. Importantly, there is no Tailscale involved in the connection between master/worker/file servers. My MacBook is connected either via Ethernet or WiFi, I tested both, and it did not make a big difference.
Your suggestion that networking could be an issue got me thinking. Tailscale introduces additional latency, especially during the initial handshake of around 1.8ms, until it settles at around 0.3ms (measured with ping). In comparison, accessing the workstations within the network only has a latency of 0.1ms regardless of whether it’s the first or 10th ping. I then tested if using cryoSPARC on the master using localhost:port or from another workstation using the IP:port would fix the issue, and in my brief testing, cryoSPARC felt much more responsive. It might be that v5 is more latency sensitive than v4.7, which then causes trouble when you have to use a VPN.
It does not always happen, and I have not identified a reproducible pattern yet. But I will keep an eye open and report once I figure it out.
Same issue here. Expanded jobs can no longer be closed at seemingly random timepoints. When this happens, the browser session becomes effectively useless. Refreshing the page only fixes the issue in a minority of cases. The only thing that reproducibly solves the issue for me is starting a new tab window in my browser. I’ve experienced this now so many times now that I’ve created a keyboard shortcut to duplicate the current browser tab to resolve the issue with minimal effort.
OS: Windows 11
Browser: Chrome
Edit: That’s not to say that I don’t love the overhaul and the introduction of the “Dashboard“. It is truly fantastic!