28 ms·

Sorry to hear it's been a frustrating experience. I'm a PM for Confluence Cloud and we're always trying to make it better. Would you be willing to share more sp

Sorry to hear it's been a frustrating experience. I'm a PM for Confluence Cloud and we're always trying to make it better. Would you be willing to share more specifics, such as: - Pages with content X are the slowest - Trying to do A/B/C is annoyingly slow - etc ? (edit: looks like HN is severely limiting my reply rate so apologies for delays) We're trying to focus on frustrating pages/experiences rather than number of network calls and such, because while the latter is correlated, the former (frustrating slow experiences) is really the bar and the higher priority. In terms of the ToS I'm not from legal so can't say (still looking into it), but have definitely had conversations with users on public forums about performance issues, and afaik no one has been accused of violating their ToS. (edit: since I can't reply due to HN limits I'll try to add some stuff in this edit) ------- @plorkyeran "target things that are easier to fix than those with highest impact" -> this is a good point and something we're trying to do. Engineers know the former (easier to fix) pretty readily, but identifying "highest impact" requires some work, so I'm (as a PM) always trying to find out. It's of course some combination of these two (low hanging fruit, high impact items) that forms the priority list. ------ @igetspam (moved followup into a reply to trigger notification) ------@core-questions "perf to take over company for 6mo-1yr" I'm not in the position to make that level of decisions, but can certainly pass the feedback up the chain. The perf team is trying their best though, so any info anyone can provide us can help us apply our resources in the right place

Slackwise 6y ago
> I'm a PM for Confluence Cloud and we're always trying to make it better. Can you guys please make Ctrl-S save and not exit editing? My muscle memory is costing me 10+ seconds of load times every time I type a paragraph and reflexively save, getting dumped back to the view mode of a document. The slow load times exacerbate the problem tremendously. I honestly don't know a single product that treats Ctrl/Cmd-S as "Save and Exit" so this is just a baffling UI/UX design decision.
- confluence_perf 6y ago
  Hi Slackwise, This is interesting -> I don't think Ctrl+S should be exiting editing in any form, can you describe this a little bit further? When you hit this is it: a) moving to Preview (you can see the changes you made, but in preview mode not page view mode (the page tree won't be visible) b) browser returns to the 'view page' (page tree visible), but your changes are not published (you may see a tag at the top "UNPUBLISHED CHANGES") c) something else (please describe) Second question: what does the browser's forward/back buttons display after the 'ctrl+S' result?
  - Slackwise 6y ago
    This isn't the cloud offering, but on-prem. I assume they're the same. The about page says "Confluence 6.15.2". When I click "Edit" to edit a page, via `/pages/editpage.action?pageId=`, and hit Ctrl-S, it takes me back to the view mode rendered via `/display/SPACE/Page+Title`. Absolutely infuriating and wastes an incredible amount of time. I can't get over my muscle memory. The "Save" button in the bottom-right does the same and appears to be what the hotkey activates. No mention of it being a "Save and Quit Editing". Hovering over the button says "Save your page (Ctrl-S)".
    - confluence_perf 6y ago
      Thanks for mentioning that -> honestly I keep forgetting to ask because I work on the Cloud side. I will see if I can find some server folks to ask around, but obviously can't promise any movement.
still_grokking 6y ago
>I'm a PM for Confluence Cloud and we're always trying to make it better. That's the problem. It's beyond repair since many, many years. You can only make it worse. Ditch it! Throw it away, and rewrite from scratch. If you don't bungle it again (here lies the risk, as we're still talking about Atlassian) you'll have a better product then ever in one year.
igetspam 6y ago
Know what would be great? Markdown support. The WYSIYG is full of bad assumptions and has been forever. In the beginning, we could at least opt out but that's long gone. I actively encourage companies I consult for to use anything but confluence because it seems to be designed specifically for the lowest common denominator with no allowance for people who work faster with a keyboard.
- rhencke 6y ago
  How does this relate to the performance issues being discussed?
  - freedomben 6y ago
    Not GP, but I'd say because it's heavy, and if you didn't have to use it (as there are alternative methods) then you don't pay the performance penalty.
  - runlevel1 6y ago
    In the case of Confluence specifically, it makes the cost of experimentation a lot steeper. Confluence's WYSIWYG editor will often make changes that can't be reversed with "undo" -- especially those involving indentation. Copy-paste frequently screws up its formatting as well. So if you don't want to risk losing lots of work, you have to make many smaller changes. With each change taking a few seconds, it adds up quickly. If it was markdown or some extended set of it, that wouldn't be a problem.
    - confluence_perf 6y ago
      We're trying to collect and fix such occurrences, so if you have something with specific repro steps please send them to me and I'll make sure they get to the right team.
      - runlevel1 6y ago
        The WYSIWYG editor makes it extremely difficult to give repro steps because formatting information is hidden from the user and is not perfectly preserved during copy-paste. More generally, the issues I see reported only ever seem to be fixed in the Cloud version. I currently have to use the Data Center version. Why go through the trouble of reporting an issue I'll never see fixed involving a feature that I loathe using?
ratww 6y ago
> Trying to do A/B/C is annoyingly slow - etc ? [...] We're trying to focus on frustrating pages/experiences rather than number of network calls It's not really a problem with a certain page or a certain action: it's a systemic issue, that can only be solved with a systemic change. This has come up before here in HN [1]. From my point of view, ignoring the issue around number of calls/performance and all feedback regarding it is the root cause for the slowness. [1] https://news.ycombinator.com/item?id=24818907 https://news.ycombinator.com/item?id=24818907
- confluence_perf 6y ago
  Hi ratww, Thank you for reiterating this point, and I'll try to shed some light on this. We actually are working on systemic changes to try to make this lighter/better but I can't talk about specifics until the feature is available. On the other hand, any level of specificity is great, for example: 1) full page loads are slower and more annoying than Transitions (or, vice versa) 2) loading Home page is slower and more annoying than Search Results (or, vice versa) 3) waiting for the editor to load is more annoying than X/Y/Z 4) etc.... Even systemic changes require individual work for applying to these different views, so any level of specific feedback would be helpful. (also it looks like HN is limiting my reply rate so apologies for any slowness)
  - AnHonestComment 6y ago
    Your post comes across as patronizing and ignoring the feedback to your company. I think less of your company for these posts.
  - deleted 6y ago
    [deleted]
  - skrap 6y ago
    If you want to make performance a feature, you need to (in order!) * define a metric * measure it automatically with every commit * define a success threshold * make changes to get yourself under the threshold * prohibit further changes which bring you above the threshold Just do it like that for pretty much every view in the system.
plorkyeran 6y ago
Literally everything? I don't think I could give an example of something which isn't frustratingly slow in Jira. It doesn't need targeted fixes to specific things; if I successfully made a list of the ten biggest offenders and they were all magically fixed tomorrow I don't think it'd appreciably change the experience of using Jira because the next 90 would still be awful. When faced with long-tail performance problems, it's often better to target the things which are easier to fix rather than the highest impact fixes. Making 20 relatively low-impact things faster can easily be better than improving 10 individually high impact things.
- pluc 6y ago
  It seriously makes you wonder whether they even use it internally, because not acknowledging or fixing those issues while pretending you have a fast system doesn't make sense.
  - marmaduke 6y ago
    Yep, and from a demo of YouTrack (from JetBrains), I got the opposite impression: it’s streamlined just the way a developer would want, keyboard shortcuts and all.
    - dmitriid 6y ago
      Youtrack still somtimes comes up some very weird shortcuts :) https://youtrack.jetbrains.com/issue/JT-19706 https://youtrack.jetbrains.com/issue/JT-19706
  - hadrien01 6y ago
    They use the on-premises version, which is much faster: https://jira.atlassian.com/secure/Dashboard.jspa https://jira.atlassian.com/secure/Dashboard.jspa
    - Judgmentality 6y ago
      If that's true, the fact that they aren't dogfooding their own product makes me 100% confident they will fail. I'm actually going to look into shorting Atlassian now.
core-questions 6y ago
> Would you be willing to share more specifics, You've got to be kidding me. Have you used your own product? Going from my carefully tuned Server install to cloud Jira or Confluence is a night-and-day difference. The Cloud product is virtually unusable in comparison for any heavy Jira user. You don't need "specifics", you need your performance engineering team to literally take over the entire company for 6 months to a year. No new features - nobody fucking needs them, the features 99% of your users use have been in the product for 5+ years already. Whatever you're PM'ing, cancel it, it's a waste of time in comparison to making the product not suck. The biggest source of losing users to some other product is going to be the sheer pain of continuing to use Atlassian.... Just make it usable. Halve the number of requests. Cache more things client-side. Do more server-side pre-processing so that a round-trip is not needed when I click on a menu. I'm not looking forward to when I am forced to migrate my users to a more expensive and less performant experience. I and hundreds of thousands of other administrators will be experiencing months of user complaints because of the forced migration as it is; this is Atlassian's real chance to make it suck less in time.
runlevel1 6y ago
Navigation is sluggish across the board in both Confluence and Jira. Not just the Cloud service, the self-hosted versions are also painfully slow no matter what resources you throw at them. That makes the other UX issues worse because the feedback loop has so much lag.
- ratww 6y ago
  > Navigation is sluggish across the board in both Confluence and Jira. Also in Bitbucket. It used to be super fast, but recent changes made it very slow. My team loves the integration with JIRA but we're considering going to Github because of the slowness.
  - NickNameNick 6y ago
    Do it. Jira's git integration is really poor anyway. Even redmine is better, where git commits that mention the issue get thier own column in the UI, and they ALL show up there, not just the ones with the comment annotation.
- coredog64 6y ago
  Good news about the self-hosted version being slow: Pretty soon you won’t be able to run self-hosted Atlassian products.
  - runlevel1 6y ago
    Their Data Center version will still be available.[1] That's what we're currently on. Data Center includes a few performance-related features like being able to run multiple frontends. I think we're running 4 instances right now. It's still really slow, even when nobody else is using it. [1]: https://www.atlassian.com/blog/jira-software/server-vs-data-center-whats-right https://www.atlassian.com/blog/jira-software/server-vs-data-...
- lukeschlather 6y ago
  I know Jira has always had scaling issues. I used to work for a very large company in the early 2010s that had, I think 5 separate Jira instances. But they were I think dealing with on the order of ten thousand daily active users per instance.
TomVDB 6y ago
If you honestly need details and specifics when Confluence has always been a slow mess to the point of being unusable, then maybe Atlassian needs a PM in charge of performance metrics first and foremost?
saagarjha 6y ago
If you’re being rate limited, try emailing the moderators at hn@ycombinator.com and they might be able to help you.
keithnz 6y ago
this "trying to show concern" is just fake. Atlassian have a ticket tracking system for their problems. They just ignore so much of the big hard problems, they close tickets with hundreds and hundreds of people on it explaining a multitude of core problems. Coming on HN is just trying to spin it for PR purposes is just not going to work, thread after thread on HN just shows that many many people have been BURNT by Atlassian products. However, I will say, Confluence has improved, but so many things still suck about it, including it being sluggish, and a search that seems really brain dead.
michaelt 6y ago
I did a test for you just now. I have 100Mbps internet, 32GB RAM, 4ghz i7 processor and suchlike. To make it easy for Jira, I'm doing this at a weekend, late at night, during the new years holiday so the servers shouldn't be busy. On a cloud-based classic software project (which has less than 200 issues) opening a link to an issue it takes 4.8 seconds for the page to complete rendering and the progress bar at the top of the screen to disappear. Opening a Kanban board with 11 issues displayed? 4.2 seconds for the page to load. Click an issue on the board? 2.5 seconds for the details to pop up. Close that task details modal - literally just closing a window? 200 milliseconds. Not to load a page - just to close a modal! In case I'm being hard on cloud Jira by insisting on using a classic project, I also checked with a 'Next-gen software project' with less than 2000 issues. I click a link to view a particular comment on an issue. 4.8 seconds until the issue, comment and buttons have all loaded. I choose to view a board? 9.9 seconds from entering the URL to the page load completing. I'm viewing the board and I want to view a single issue's page. I click the issue and the details modal pops up - and just as I click on the link to the details, the link moves because the epic details have loaded, and been put to the left of the link I was going for, causing me to click the wrong thing. So this slow loading is a nontrivial usability problem. View a single issue, then click the projects dropdown menu. The time, to display a drop-down menu with three items? 200 milliseconds. This is what people mean when they say the performance problems are everywhere - viewing issues, viewing boards, viewing comments, opening dropdowns, closing modals? It's all slow. And if you imagine a backlog grooming meeting that involves a lot of switching back and forth between pages and updating tickets? You get to wait through a great many of these several-second pageloads.
- davb 6y ago
  That tallies with the experience I had using Jira cloud a few years ago. It sounds like it's still a great case study in how not to architect an issue tracker.
- confluence_perf 6y ago
  Hi michaelt, Thank you for the numbers -> I agree these are slow, and I can guarantee you that the Jira team is working on it (though I can't talk about details). These numbers are definitely outside of the goals. I appreciate the call out of "page to complete rendering and the progress bar at the top of the screen to disappear" and "until the issue, comment and buttons have all loaded". In a dream world of course, everything would load in < 1s (everything drawn, everything interactive), but working our way down to that will take time. We're currently looking at each use case to understand the '(a) paint faster vs (b) interactive faster' tradeoff and trying to decide which cases the user has a better experience with (a) or (b). In Confluence this is clearer in some places than in others, but in Jira it's less clear I think (I work on Confluence, I probably shouldn't speak for Jira specifics). It always comes down to a limitation of resources though, which is why we're always hoping to get as specific feedback as possible.
miken123 6y ago
> Would you be willing to share more specifics That's something you could easily figure out yourself. E.g., just grabbing some random JIRA: https://hibernate.atlassian.net/jira/software/c/projects/HV/issues/?filter=allissues https://hibernate.atlassian.net/jira/software/c/projects/HV/... Opening an issue in that tracker takes 24 seconds for me. Twenty-four.
- throw_jirauser 6y ago
  31.2 seconds, on a not great internet connection (cell)
- NickNameNick 6y ago
  wow - clicking on an issue in that tracker was terrible. after 3-4 seconds I thought it had finished loading, but then the UI pulled a bunch more stuff in, and it didn't finish loading the image in the issue description - the most important part of the page - until 24.87s. On 100Mb fiber...
- deathweasel 6y ago
  9s to load that page. 3s just for `jira/software/c/projects/HV/issues/?filter=allissues`, which is 194 lines of HTML (with some scripts) but the bulk of the 3s is just content loading. Wow.
- jiggawatts 6y ago
  Scroll up and down in the list. They polyfill text! That's just absurd. To add a data point, I get 26 seconds on gigabit fibre that is 3 ms network latency away from "hibernate.atlassian.net".
- rswail 6y ago
  Average of 15s for me, including watching the issue sidebar show a bunch of fields, with "5 more fields" and then refresh and remove that option. I started using JIRA in 2008. It was faster then. If this is what the "cloud" version is going to be, then we will be looking for alternatives, even though we're an Aussie company and I would like to be supportive. As for Confluence, the wiki is just ok. The editor is clumsy and occasionally I have to go into raw HTML just to get highlighting, bolding etc to work. If Atlassian is going all-in on cloud, then it needs to realize that cloud isn't "run our software, but not on-prem". Just like MYOB had to learn, it needs to be rewritten so that the web front end is streamlined and cached separately to the underlying API.
jiggawatts 6y ago
The topic of poor Jira performance came up yesterday, and I did some quick benchmarking of Jira cloud using the best-case scenario for performance: A tiny amount of data, no complex permissions, a commonly used form, no web proxy, no plugins, same geo region as the servers (Sydney), gigabit fibre internet(!), etc... I spun up a free-tier account and created an empty issue. No data. No history. Nothing in any form fields. As blank as possible. The only positive aspect is that most of the traffic is coming from a CDN that enables: Gzip, IPv6, HTTP/2, AES-GCM, and TLS 1.3. That's the basics taken care of. Despite this, reloading the page with a warm cache took a whopping 5.5 seconds. There's an animated progress bar for the empty form! This required 1.2 MB of uncacheable content to be transferred. With the cache disabled (or cold), a total of 27.5 MB across 151 files taking 33 seconds is required to display the page. This takes over 5 MB of network traffic after compression. (Note that some corporate web proxies strip compression, so you can't rely on it working!) For reference, it takes 1.6 seconds on the same computer to start Excel, and 8 seconds to load Visual Studio 2019 (including opening a project). That's four times faster than opening an issue ticket with a cold cache! Meanwhile, the total text displayed on the screen is less than 1 KB, which means that the page has transfer-to-content efficiency ratio exceeding 1000-to-1. This isn't the animated menu of a computer game, it's a web form! To render the page, a total of 4.35 seconds of CPU time was required on a gaming desktop PC to with a 3.80 GHz CPU. Having 6-cores doesn't seem to help performance, so don't assume upcoming higher-core CPUs will help in any way. A developer on an ultraportable laptop running on battery over a WiFi link with a bad corporate proxy server in a different geo-region would likely get a much worse experience. Typically they might get as little as 1.5 GHz and 20 Mbps effective bandwidth, so I can see why people are complaining that Jira page loads are taking 10+ seconds! In perfectly normal circumstances your customers are likely seeing load times approaching a solid minute. PS: I do development, and I've avoided Atlassian products primarily because there's been a consistent theme to all discussions related to Atlassian, especially Jira: It's slow. Stop asking your customers if they're running plugins, or what configuration they're using. Start asking yourself what you've done wrong, terribly, terribly wrong.
- alexott 6y ago
  And if you are on battery only, with Wi-Fi over tethering, try to find relevant issues to solve problems of your customer... Or trying to file new Jira on the same setup... It’s so painful
deleted 6y ago
[deleted]
Macha 6y ago
It's hard to name a single action I can take in JIRA which does not feel unacceptably slow. However, these are the actions that cause the most issues for me due to being used most often (JIRA datacenter, MBP 2019 with i7 + 32gb ram): 1. Viewing a board. This can take 10+ seconds to load. 2. Dragging an issue from one column to another. This greys out the board, rendering it unreadable and unusable for 5-ish seconds. 3. Editing a field. I get a little spinner before it applies for 2-3s for even the simplest edits like adding a label. 4. Interacting with any board that crosses multiple projects. A single project board is bad enough, as in point 1, but we have a 5 project board that takes 20+ seconds. Actually, I found an action that's pretty ok: Search results are fast, even if clicking into any of them is not. I'm not sure why rendering a board is so different performance wise.
- confluence_perf 6y ago
  Thank you so much for the details! This is very helpful. I will pass this along to my Jira Perf colleagues (there's multiple of them, since they know Perf is such a big issue). Just to clarify on Search though, which search are you talking about: a) quick search (top bar) b) issue search (the one with the basic/JQL switcher) c) something else Trying to narrow down the latter "even if clicking into any of them is not" part to understand which view that is
  - Macha 6y ago
    Doesn't Quick Search lead into issue search when you press enter? I think I mean issue search. By clicking into them, I mean actually loading the issues is slow.
  - texasbigdata 6y ago
    Do you guys not use the tool? How is this news to you? Couldn’t you self generate this issue list by just sitting in a locked room for 45 minutes and writing down everything you know already doesn’t work?
pacamara619 6y ago
Is this bait?
tbodt 6y ago
I would say the right place for the performance team to apply resources is looking for bugs or missed optimizations that affect everything or nearly everything on the site. Everything is uniformly slow, so there must be a lot of this.
xtracto 6y ago
> Would you be willing to share more specifics, such as: - Pages with content X are the slowest - Trying to do A/B/C is annoyingly slow - etc ? I would... but Atlassian TOS prohibit me from doing so :(
dmitriid 6y ago
I think this answer from two months ago should give all the insight you ever want: https://news.ycombinator.com/item?id=24818907 https://news.ycombinator.com/item?id=24818907 And the first answer to your comment in this thread profiling performance for an empty page with almost no data on a small project should give you even more data than you ever would want. And this one for an empty project: https://news.ycombinator.com/item?id=25616069 https://news.ycombinator.com/item?id=25616069 However, having personally experienced "upgrades to Jira and Confluence experiences" over the past few years, I can safely say: no one at Atlassian gives two craps about this. All the talk about "We are definitely working on generalized efforts to make 'most/all/everything' faster" is just that: talk. There's exactly zero priority given to performance issues in lieu of flashy visual upgrades which only make the actual experience worse. > We're trying to focus on frustrating pages/experiences rather than number of network calls and such, because while the latter is correlated, the former (frustrating slow experiences) is really the bar and the higher priority. Exactly: you aren't even trying to understand what people are telling you. These metrics you ask for and then dismiss entirely are the primary, core, systemic reason for frustrating slow experiences that you pretend are "high priority". No, frustrating slow experiences have not been a high priority for years (if ever). If you need to do 200 requests and load 27.5 MB of data to display an empty page, therein lies your problem. You, and other PMs at Atlassian fail to understand these basic things, and yet we get platitudes like "performance is our top priority". It is not. You're good at hiding information and buttons behind multiple layers of clicks, each of which needs another 200 requests and 5-15 seconds to execute. Oh. You're also good at adding useless crap like this: https://grumpy.website/post/0TcOcOFgL https://grumpy.website/post/0TcOcOFgL while making sure that your software is nigh unusable: https://twitter.com/dmitriid/status/888415958821416960 https://twitter.com/dmitriid/status/888415958821416960 I imagine all performance tickets get dismissed because no one can see the description even on a 5k monitor
X-Istence 6y ago
Other commenters have hit on this already, but the worst one that bites me all of the time is this one: 1. I click a link to an issue 2. I need to do something on that issue, so I attempt to click on a particular section to go make a modification 3. Bam, some background script has loaded, some new piece of content was shoved in, and what I clicked wasn't the thing I was expecting to click Also, certain interactions within JIRA take far too many steps, and each one takes far too long to load, so it makes me dislike JIRA even more. Project managers love JIRA, but engineers don't, because each time you make us wait we are less inclined to deal with the software that PM's need us to use so they know how things are going, so instead we get more meetings. If JIRA were fast, we could cut down on meetings. Please make JIRA fast.
- CuriousSkeptic 6y ago
  > Project managers love JIRA, but engineers don't I think this is the core issue. It is simply not designed to be useful for developers, it’s designed for managing developers. It’s the same issue with time reporting tools. The UI for entering data is just there because it needs to, but it’s not the central selling point of the software. The UX for the data entry is just not designed to solve any problems besides accepting the data required for the reports that are the real product.
dalrympm 6y ago
@confluence_perf The Cloud applications provide multiple avenues for providing feedback directly in the user interface. Some/many of them are quite invasive (as in part of the screen is taken over with a "rate your experience editing this document"). I have used these avenues to provide feedback many many times over the years with my #1 response always being "focus on the performance". None of those ever get a response and I don't see what reiterating them in a HN post is going to solve. You have the data, please do something with it.

Slackwise 6y ago

> I'm a PM for Confluence Cloud and we're always trying to make it better. Can you guys please make Ctrl-S save and not exit editing? My muscle memory is costing me 10+ seconds of load times every time I type a paragraph and reflexively save, getting dumped back to the view mode of a document. The slow load times exacerbate the problem tremendously. I honestly don't know a single product that treats Ctrl/Cmd-S as "Save and Exit" so this is just a baffling UI/UX design decision.

confluence_perf 6y ago
Hi Slackwise, This is interesting -> I don't think Ctrl+S should be exiting editing in any form, can you describe this a little bit further? When you hit this is it: a) moving to Preview (you can see the changes you made, but in preview mode not page view mode (the page tree won't be visible) b) browser returns to the 'view page' (page tree visible), but your changes are not published (you may see a tag at the top "UNPUBLISHED CHANGES") c) something else (please describe) Second question: what does the browser's forward/back buttons display after the 'ctrl+S' result?
- Slackwise 6y ago
  This isn't the cloud offering, but on-prem. I assume they're the same. The about page says "Confluence 6.15.2". When I click "Edit" to edit a page, via `/pages/editpage.action?pageId=`, and hit Ctrl-S, it takes me back to the view mode rendered via `/display/SPACE/Page+Title`. Absolutely infuriating and wastes an incredible amount of time. I can't get over my muscle memory. The "Save" button in the bottom-right does the same and appears to be what the hotkey activates. No mention of it being a "Save and Quit Editing". Hovering over the button says "Save your page (Ctrl-S)".
  - confluence_perf 6y ago
    Thanks for mentioning that -> honestly I keep forgetting to ask because I work on the Cloud side. I will see if I can find some server folks to ask around, but obviously can't promise any movement.

still_grokking 6y ago

>I'm a PM for Confluence Cloud and we're always trying to make it better. That's the problem. It's beyond repair since many, many years. You can only make it worse. Ditch it! Throw it away, and rewrite from scratch. If you don't bungle it again (here lies the risk, as we're still talking about Atlassian) you'll have a better product then ever in one year.

igetspam 6y ago

Know what would be great? Markdown support. The WYSIYG is full of bad assumptions and has been forever. In the beginning, we could at least opt out but that's long gone. I actively encourage companies I consult for to use anything but confluence because it seems to be designed specifically for the lowest common denominator with no allowance for people who work faster with a keyboard.

rhencke 6y ago
How does this relate to the performance issues being discussed?
- freedomben 6y ago
  Not GP, but I'd say because it's heavy, and if you didn't have to use it (as there are alternative methods) then you don't pay the performance penalty.
- runlevel1 6y ago
  In the case of Confluence specifically, it makes the cost of experimentation a lot steeper. Confluence's WYSIWYG editor will often make changes that can't be reversed with "undo" -- especially those involving indentation. Copy-paste frequently screws up its formatting as well. So if you don't want to risk losing lots of work, you have to make many smaller changes. With each change taking a few seconds, it adds up quickly. If it was markdown or some extended set of it, that wouldn't be a problem.
  - confluence_perf 6y ago
    We're trying to collect and fix such occurrences, so if you have something with specific repro steps please send them to me and I'll make sure they get to the right team.
    - runlevel1 6y ago
      The WYSIWYG editor makes it extremely difficult to give repro steps because formatting information is hidden from the user and is not perfectly preserved during copy-paste. More generally, the issues I see reported only ever seem to be fixed in the Cloud version. I currently have to use the Data Center version. Why go through the trouble of reporting an issue I'll never see fixed involving a feature that I loathe using?

ratww 6y ago

> Trying to do A/B/C is annoyingly slow - etc ? [...] We're trying to focus on frustrating pages/experiences rather than number of network calls It's not really a problem with a certain page or a certain action: it's a systemic issue, that can only be solved with a systemic change. This has come up before here in HN [1]. From my point of view, ignoring the issue around number of calls/performance and all feedback regarding it is the root cause for the slowness. [1] https://news.ycombinator.com/item?id=24818907 https://news.ycombinator.com/item?id=24818907

confluence_perf 6y ago
Hi ratww, Thank you for reiterating this point, and I'll try to shed some light on this. We actually are working on systemic changes to try to make this lighter/better but I can't talk about specifics until the feature is available. On the other hand, any level of specificity is great, for example: 1) full page loads are slower and more annoying than Transitions (or, vice versa) 2) loading Home page is slower and more annoying than Search Results (or, vice versa) 3) waiting for the editor to load is more annoying than X/Y/Z 4) etc.... Even systemic changes require individual work for applying to these different views, so any level of specific feedback would be helpful. (also it looks like HN is limiting my reply rate so apologies for any slowness)
- AnHonestComment 6y ago
  Your post comes across as patronizing and ignoring the feedback to your company. I think less of your company for these posts.
- deleted 6y ago
  [deleted]
- skrap 6y ago
  If you want to make performance a feature, you need to (in order!) * define a metric * measure it automatically with every commit * define a success threshold * make changes to get yourself under the threshold * prohibit further changes which bring you above the threshold Just do it like that for pretty much every view in the system.

plorkyeran 6y ago

Literally everything? I don't think I could give an example of something which isn't frustratingly slow in Jira. It doesn't need targeted fixes to specific things; if I successfully made a list of the ten biggest offenders and they were all magically fixed tomorrow I don't think it'd appreciably change the experience of using Jira because the next 90 would still be awful. When faced with long-tail performance problems, it's often better to target the things which are easier to fix rather than the highest impact fixes. Making 20 relatively low-impact things faster can easily be better than improving 10 individually high impact things.

pluc 6y ago
It seriously makes you wonder whether they even use it internally, because not acknowledging or fixing those issues while pretending you have a fast system doesn't make sense.
- marmaduke 6y ago
  Yep, and from a demo of YouTrack (from JetBrains), I got the opposite impression: it’s streamlined just the way a developer would want, keyboard shortcuts and all.
  - dmitriid 6y ago
    Youtrack still somtimes comes up some very weird shortcuts :) https://youtrack.jetbrains.com/issue/JT-19706 https://youtrack.jetbrains.com/issue/JT-19706
- hadrien01 6y ago
  They use the on-premises version, which is much faster: https://jira.atlassian.com/secure/Dashboard.jspa https://jira.atlassian.com/secure/Dashboard.jspa
  - Judgmentality 6y ago
    If that's true, the fact that they aren't dogfooding their own product makes me 100% confident they will fail. I'm actually going to look into shorting Atlassian now.

core-questions 6y ago

> Would you be willing to share more specifics, You've got to be kidding me. Have you used your own product? Going from my carefully tuned Server install to cloud Jira or Confluence is a night-and-day difference. The Cloud product is virtually unusable in comparison for any heavy Jira user. You don't need "specifics", you need your performance engineering team to literally take over the entire company for 6 months to a year. No new features - nobody fucking needs them, the features 99% of your users use have been in the product for 5+ years already. Whatever you're PM'ing, cancel it, it's a waste of time in comparison to making the product not suck. The biggest source of losing users to some other product is going to be the sheer pain of continuing to use Atlassian.... Just make it usable. Halve the number of requests. Cache more things client-side. Do more server-side pre-processing so that a round-trip is not needed when I click on a menu. I'm not looking forward to when I am forced to migrate my users to a more expensive and less performant experience. I and hundreds of thousands of other administrators will be experiencing months of user complaints because of the forced migration as it is; this is Atlassian's real chance to make it suck less in time.

runlevel1 6y ago

Navigation is sluggish across the board in both Confluence and Jira. Not just the Cloud service, the self-hosted versions are also painfully slow no matter what resources you throw at them. That makes the other UX issues worse because the feedback loop has so much lag.

ratww 6y ago
> Navigation is sluggish across the board in both Confluence and Jira. Also in Bitbucket. It used to be super fast, but recent changes made it very slow. My team loves the integration with JIRA but we're considering going to Github because of the slowness.
- NickNameNick 6y ago
  Do it. Jira's git integration is really poor anyway. Even redmine is better, where git commits that mention the issue get thier own column in the UI, and they ALL show up there, not just the ones with the comment annotation.
coredog64 6y ago
Good news about the self-hosted version being slow: Pretty soon you won’t be able to run self-hosted Atlassian products.
- runlevel1 6y ago
  Their Data Center version will still be available.[1] That's what we're currently on. Data Center includes a few performance-related features like being able to run multiple frontends. I think we're running 4 instances right now. It's still really slow, even when nobody else is using it. [1]: https://www.atlassian.com/blog/jira-software/server-vs-data-center-whats-right https://www.atlassian.com/blog/jira-software/server-vs-data-...
lukeschlather 6y ago
I know Jira has always had scaling issues. I used to work for a very large company in the early 2010s that had, I think 5 separate Jira instances. But they were I think dealing with on the order of ten thousand daily active users per instance.

TomVDB 6y ago

If you honestly need details and specifics when Confluence has always been a slow mess to the point of being unusable, then maybe Atlassian needs a PM in charge of performance metrics first and foremost?

saagarjha 6y ago

If you’re being rate limited, try emailing the moderators at hn@ycombinator.com and they might be able to help you.

keithnz 6y ago

this "trying to show concern" is just fake. Atlassian have a ticket tracking system for their problems. They just ignore so much of the big hard problems, they close tickets with hundreds and hundreds of people on it explaining a multitude of core problems. Coming on HN is just trying to spin it for PR purposes is just not going to work, thread after thread on HN just shows that many many people have been BURNT by Atlassian products. However, I will say, Confluence has improved, but so many things still suck about it, including it being sluggish, and a search that seems really brain dead.

michaelt 6y ago

I did a test for you just now. I have 100Mbps internet, 32GB RAM, 4ghz i7 processor and suchlike. To make it easy for Jira, I'm doing this at a weekend, late at night, during the new years holiday so the servers shouldn't be busy. On a cloud-based classic software project (which has less than 200 issues) opening a link to an issue it takes 4.8 seconds for the page to complete rendering and the progress bar at the top of the screen to disappear. Opening a Kanban board with 11 issues displayed? 4.2 seconds for the page to load. Click an issue on the board? 2.5 seconds for the details to pop up. Close that task details modal - literally just closing a window? 200 milliseconds. Not to load a page - just to close a modal! In case I'm being hard on cloud Jira by insisting on using a classic project, I also checked with a 'Next-gen software project' with less than 2000 issues. I click a link to view a particular comment on an issue. 4.8 seconds until the issue, comment and buttons have all loaded. I choose to view a board? 9.9 seconds from entering the URL to the page load completing. I'm viewing the board and I want to view a single issue's page. I click the issue and the details modal pops up - and just as I click on the link to the details, the link moves because the epic details have loaded, and been put to the left of the link I was going for, causing me to click the wrong thing. So this slow loading is a nontrivial usability problem. View a single issue, then click the projects dropdown menu. The time, to display a drop-down menu with three items? 200 milliseconds. This is what people mean when they say the performance problems are everywhere - viewing issues, viewing boards, viewing comments, opening dropdowns, closing modals? It's all slow. And if you imagine a backlog grooming meeting that involves a lot of switching back and forth between pages and updating tickets? You get to wait through a great many of these several-second pageloads.

davb 6y ago
That tallies with the experience I had using Jira cloud a few years ago. It sounds like it's still a great case study in how not to architect an issue tracker.
confluence_perf 6y ago
Hi michaelt, Thank you for the numbers -> I agree these are slow, and I can guarantee you that the Jira team is working on it (though I can't talk about details). These numbers are definitely outside of the goals. I appreciate the call out of "page to complete rendering and the progress bar at the top of the screen to disappear" and "until the issue, comment and buttons have all loaded". In a dream world of course, everything would load in < 1s (everything drawn, everything interactive), but working our way down to that will take time. We're currently looking at each use case to understand the '(a) paint faster vs (b) interactive faster' tradeoff and trying to decide which cases the user has a better experience with (a) or (b). In Confluence this is clearer in some places than in others, but in Jira it's less clear I think (I work on Confluence, I probably shouldn't speak for Jira specifics). It always comes down to a limitation of resources though, which is why we're always hoping to get as specific feedback as possible.

miken123 6y ago

> Would you be willing to share more specifics That's something you could easily figure out yourself. E.g., just grabbing some random JIRA: https://hibernate.atlassian.net/jira/software/c/projects/HV/issues/?filter=allissues https://hibernate.atlassian.net/jira/software/c/projects/HV/... Opening an issue in that tracker takes 24 seconds for me. Twenty-four.

throw_jirauser 6y ago
31.2 seconds, on a not great internet connection (cell)
NickNameNick 6y ago
wow - clicking on an issue in that tracker was terrible. after 3-4 seconds I thought it had finished loading, but then the UI pulled a bunch more stuff in, and it didn't finish loading the image in the issue description - the most important part of the page - until 24.87s. On 100Mb fiber...
deathweasel 6y ago
9s to load that page. 3s just for `jira/software/c/projects/HV/issues/?filter=allissues`, which is 194 lines of HTML (with some scripts) but the bulk of the 3s is just content loading. Wow.
jiggawatts 6y ago
Scroll up and down in the list. They polyfill text! That's just absurd. To add a data point, I get 26 seconds on gigabit fibre that is 3 ms network latency away from "hibernate.atlassian.net".
rswail 6y ago
Average of 15s for me, including watching the issue sidebar show a bunch of fields, with "5 more fields" and then refresh and remove that option. I started using JIRA in 2008. It was faster then. If this is what the "cloud" version is going to be, then we will be looking for alternatives, even though we're an Aussie company and I would like to be supportive. As for Confluence, the wiki is just ok. The editor is clumsy and occasionally I have to go into raw HTML just to get highlighting, bolding etc to work. If Atlassian is going all-in on cloud, then it needs to realize that cloud isn't "run our software, but not on-prem". Just like MYOB had to learn, it needs to be rewritten so that the web front end is streamlined and cached separately to the underlying API.

jiggawatts 6y ago

The topic of poor Jira performance came up yesterday, and I did some quick benchmarking of Jira cloud using the best-case scenario for performance: A tiny amount of data, no complex permissions, a commonly used form, no web proxy, no plugins, same geo region as the servers (Sydney), gigabit fibre internet(!), etc... I spun up a free-tier account and created an empty issue. No data. No history. Nothing in any form fields. As blank as possible. The only positive aspect is that most of the traffic is coming from a CDN that enables: Gzip, IPv6, HTTP/2, AES-GCM, and TLS 1.3. That's the basics taken care of. Despite this, reloading the page with a warm cache took a whopping 5.5 seconds. There's an animated progress bar for the empty form! This required 1.2 MB of uncacheable content to be transferred. With the cache disabled (or cold), a total of 27.5 MB across 151 files taking 33 seconds is required to display the page. This takes over 5 MB of network traffic after compression. (Note that some corporate web proxies strip compression, so you can't rely on it working!) For reference, it takes 1.6 seconds on the same computer to start Excel, and 8 seconds to load Visual Studio 2019 (including opening a project). That's four times faster than opening an issue ticket with a cold cache! Meanwhile, the total text displayed on the screen is less than 1 KB, which means that the page has transfer-to-content efficiency ratio exceeding 1000-to-1. This isn't the animated menu of a computer game, it's a web form! To render the page, a total of 4.35 seconds of CPU time was required on a gaming desktop PC to with a 3.80 GHz CPU. Having 6-cores doesn't seem to help performance, so don't assume upcoming higher-core CPUs will help in any way. A developer on an ultraportable laptop running on battery over a WiFi link with a bad corporate proxy server in a different geo-region would likely get a much worse experience. Typically they might get as little as 1.5 GHz and 20 Mbps effective bandwidth, so I can see why people are complaining that Jira page loads are taking 10+ seconds! In perfectly normal circumstances your customers are likely seeing load times approaching a solid minute. PS: I do development, and I've avoided Atlassian products primarily because there's been a consistent theme to all discussions related to Atlassian, especially Jira: It's slow. Stop asking your customers if they're running plugins, or what configuration they're using. Start asking yourself what you've done wrong, terribly, terribly wrong.

alexott 6y ago
And if you are on battery only, with Wi-Fi over tethering, try to find relevant issues to solve problems of your customer... Or trying to file new Jira on the same setup... It’s so painful

deleted 6y ago

[deleted]

Macha 6y ago

It's hard to name a single action I can take in JIRA which does not feel unacceptably slow. However, these are the actions that cause the most issues for me due to being used most often (JIRA datacenter, MBP 2019 with i7 + 32gb ram): 1. Viewing a board. This can take 10+ seconds to load. 2. Dragging an issue from one column to another. This greys out the board, rendering it unreadable and unusable for 5-ish seconds. 3. Editing a field. I get a little spinner before it applies for 2-3s for even the simplest edits like adding a label. 4. Interacting with any board that crosses multiple projects. A single project board is bad enough, as in point 1, but we have a 5 project board that takes 20+ seconds. Actually, I found an action that's pretty ok: Search results are fast, even if clicking into any of them is not. I'm not sure why rendering a board is so different performance wise.

confluence_perf 6y ago
Thank you so much for the details! This is very helpful. I will pass this along to my Jira Perf colleagues (there's multiple of them, since they know Perf is such a big issue). Just to clarify on Search though, which search are you talking about: a) quick search (top bar) b) issue search (the one with the basic/JQL switcher) c) something else Trying to narrow down the latter "even if clicking into any of them is not" part to understand which view that is
- Macha 6y ago
  Doesn't Quick Search lead into issue search when you press enter? I think I mean issue search. By clicking into them, I mean actually loading the issues is slow.
- texasbigdata 6y ago
  Do you guys not use the tool? How is this news to you? Couldn’t you self generate this issue list by just sitting in a locked room for 45 minutes and writing down everything you know already doesn’t work?

pacamara619 6y ago

Is this bait?

tbodt 6y ago

I would say the right place for the performance team to apply resources is looking for bugs or missed optimizations that affect everything or nearly everything on the site. Everything is uniformly slow, so there must be a lot of this.

xtracto 6y ago

> Would you be willing to share more specifics, such as: - Pages with content X are the slowest - Trying to do A/B/C is annoyingly slow - etc ? I would... but Atlassian TOS prohibit me from doing so :(

dmitriid 6y ago

I think this answer from two months ago should give all the insight you ever want: https://news.ycombinator.com/item?id=24818907 https://news.ycombinator.com/item?id=24818907 And the first answer to your comment in this thread profiling performance for an empty page with almost no data on a small project should give you even more data than you ever would want. And this one for an empty project: https://news.ycombinator.com/item?id=25616069 https://news.ycombinator.com/item?id=25616069 However, having personally experienced "upgrades to Jira and Confluence experiences" over the past few years, I can safely say: no one at Atlassian gives two craps about this. All the talk about "We are definitely working on generalized efforts to make 'most/all/everything' faster" is just that: talk. There's exactly zero priority given to performance issues in lieu of flashy visual upgrades which only make the actual experience worse. > We're trying to focus on frustrating pages/experiences rather than number of network calls and such, because while the latter is correlated, the former (frustrating slow experiences) is really the bar and the higher priority. Exactly: you aren't even trying to understand what people are telling you. These metrics you ask for and then dismiss entirely are the primary, core, systemic reason for frustrating slow experiences that you pretend are "high priority". No, frustrating slow experiences have not been a high priority for years (if ever). If you need to do 200 requests and load 27.5 MB of data to display an empty page, therein lies your problem. You, and other PMs at Atlassian fail to understand these basic things, and yet we get platitudes like "performance is our top priority". It is not. You're good at hiding information and buttons behind multiple layers of clicks, each of which needs another 200 requests and 5-15 seconds to execute. Oh. You're also good at adding useless crap like this: https://grumpy.website/post/0TcOcOFgL https://grumpy.website/post/0TcOcOFgL while making sure that your software is nigh unusable: https://twitter.com/dmitriid/status/888415958821416960 https://twitter.com/dmitriid/status/888415958821416960 I imagine all performance tickets get dismissed because no one can see the description even on a 5k monitor

X-Istence 6y ago

Other commenters have hit on this already, but the worst one that bites me all of the time is this one: 1. I click a link to an issue 2. I need to do something on that issue, so I attempt to click on a particular section to go make a modification 3. Bam, some background script has loaded, some new piece of content was shoved in, and what I clicked wasn't the thing I was expecting to click Also, certain interactions within JIRA take far too many steps, and each one takes far too long to load, so it makes me dislike JIRA even more. Project managers love JIRA, but engineers don't, because each time you make us wait we are less inclined to deal with the software that PM's need us to use so they know how things are going, so instead we get more meetings. If JIRA were fast, we could cut down on meetings. Please make JIRA fast.

CuriousSkeptic 6y ago
> Project managers love JIRA, but engineers don't I think this is the core issue. It is simply not designed to be useful for developers, it’s designed for managing developers. It’s the same issue with time reporting tools. The UI for entering data is just there because it needs to, but it’s not the central selling point of the software. The UX for the data entry is just not designed to solve any problems besides accepting the data required for the reports that are the real product.

dalrympm 6y ago

@confluence_perf The Cloud applications provide multiple avenues for providing feedback directly in the user interface. Some/many of them are quite invasive (as in part of the screen is taken over with a "rate your experience editing this document"). I have used these avenues to provide feedback many many times over the years with my #1 response always being "focus on the performance". None of those ever get a response and I don't see what reiterating them in a HN post is going to solve. You have the data, please do something with it.