Live data from Hacker News

Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

atlassian.com

181–190 of 305 posts

Re: Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

#181

Earlier quoted context omitted.

> In a dream world of course, everything would load in It's important you understand that "everything loading in That is not "a dream world" - not even close. A well built tool like this, meeting standard expectations (i.e. table stakes), would hit You should be targeting This is why people are saying the company needs to make a major shift on this - you're not just out of the ballpark of table stakes here, you're ba…

> A "dream world" would be more like 10ms. A gateway solely adds 50 ms. So I'm not really sure where you get your numbers/benchmarks from... They are unrealistic

What gateways have you been using?! That's a long, long way off on the modern internet. Assuming you mean gateways as in the lines you'd see on a traceroute, more typical might be ~2-5ms on a home router, ~0.5-1.0ms upstream.

Re: Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

#182
I have yet to use a JIRA or Confluence system that isn't almost insufferably slow while also suffering from a terrible UX. They seem to be the IBM of project management and documentation in the software world, though.

Also for users not acting in the capacity of a representative for their employers who purchase or install JIRA/Confluence it is perfectly fine to discuss performance issues such as the above. The law isn't as dumb as some seem to think.

Re: Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

#183

Earlier quoted context omitted.

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.

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 usi…

> 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?

I find the same issue with Nessus Professional. They too are trying to funnel everyone into using tenable.io (SaaS nessus scanner). And they also are very resistant in doing much of any changes (other than removing the API) from their onprem solution. But tenable.io keeps getting regular updates.

Worse yet, when you talk to anybody there, the first thing is "Why arent you using tenable.io ?" My response every time is, "Has it been fedramped YET?".. Of course it hasn't. Not entirely sure they even plan on doing that.

For maintaining data integrity and preserving a secure environment, these companies are demanding that we open our networks and store our critical data somewhere we really don't have access to.

Re: Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

#184

Earlier quoted context omitted.

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, e…

Hopefully this demonstrates that the anti-performance-discussion ToS clause is harmful not only to your customers but to you as well. You're getting useful information here only because some people are willing to openly violate it.

Not to mention the reputational damage from people asking "why the hell is this in the contract in the first place?"

It says they're so afraid of the quality of their product they'd rather litigate their customers than fix their product.

Re: Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

#185
I don't want to sound mean, but before discussing performance issues, can we talk about how completely unusable all of Atlassian's products are? I mean this sincerely. I feel bad saying it because I know there are lots of people probably on this site that worked on them. But I literally often have no idea how to proceed when using these products. That's something that hasn't happened to me since before I was a teenager.

As 2 random examples, I've used both Confluence and Crucible in the last month. In Confluence, when I log in I see everything that anyone in my (1,000+ people) organization worked on most recently. People I've never even heard of show up as having edited some random document that doesn't concern me. Meanwhile, I can find no way to list all articles that I created. There's a small list of things I edited or looked at in the last 30 days, but no way to say, "just show me everything I created."

Meanwhile, in Crucible, I literally can't figure out how to do anything. I'm reading through the changes to some source code and adding comments, and after an hour of doing that, it still says I've completed 0% of my review. WTF? And when I start my own code review, every god damned time, it tells me, "You're about to start a review with no reviewers." It then offers me 2 choices: Abandon the review or cancel. I get what "abandon" does. What does cancel do? Cancel the review? Cancel abandoning the review? Why is there no button right there to add reviewers? That's what I most want to do! (And there are no reviewers yet because it literally has not yet given me the option to add them previously in the work flow. WTF?)

You can talk about performance all you want. I won't bother until the products actually perform some useful function. As of now, as far as I can tell, they don't.

Re: Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

#187

Earlier quoted context omitted.

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…

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, e…

I hate to pile on a thread where you're already taking a lot of flack, but this point is really important to the future of Atlassian:

> In a dream world of course, everything would load in As a contractor, I have more or less walked out of or refused interviews on discovering Atlassian toolset was in use. It's not because I hate your tooling (it is visually nice and very featureful), it's because the culture that delivered this software is antithetical to anything I look for in a software project I want to use or contribute to. How can I possibly do my job to any degree of satisfaction when I'm tracking work in a tool that requires 15 seconds between mouse clicks? That is the reality of Jira, and as a result I refuse to use it, or work for people who find that acceptable, because it's a "broken window" that tells me much more about the target environment than merely something about suboptimal bug trackers.

Your page budget should be 100ms max, given all your tools actually do are track a couple of text fields in a pleasing style. Whoever the architecture astronauts are at Atlassian that created the current mess, flush them out, no seat is too senior -- this is an existential issue for your business.

Re: Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

#188

Earlier quoted context omitted.

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…

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, e…

"'(a) paint faster vs (b) interactive faster'"

It is only a tradeoff if you're at the Pareto optimality frontier [1] for those two things.

I seriously doubt that you are. You should absolutely be able to have more of both.

I would recommend to you personally two things: Open the debugger, and load a page with an issue on it in any environment. Look at the timeline of incoming resources, not just for how long the total takes but also all the other times. You will learn a lot if you haven't done this yet. It will be much more informative than anything we can tell you.

Second, once an issue is loaded, right click on almost anything in the page (description, title, whatever) and select "Inspect Element". Look at how many layers deep you are in the HTML.

I also find it useful to Save the Web Page (Complete) once it's all done rendering, then load it from disk with the network tab loaded in the debugger. It can give a quick & dirty read on how much time it takes just to render the page, separate from all network and server-side code issues.

I have a bit of a pet theory that a lot of modern slowdown on the web is simply how much of the web is literally dozens and dozens of DOM layers deep in containers that are all technically resizeable (even though it is always going to have one element in it, or could be fixed in some other simple way), so the browser layout engine is stressed to the limit because of all the nested O(n) & O(n log n) stuff going on. (It must not be a true O(n^2) because our pages would never load at all, but even the well-optimized browser engines can just be drowned in nodes.) I don't have enough front-end experience to be sure, but both times I took a static snapshot of a page for some local UI I had access to that was straight-up 2+ seconds to render from disk, I was able to go in and just start slicing away at the tags to get a page that was virtually identical (not quite, but close enough) that rendered in a small fraction of a second, just with HTML changes.

My guess is that fixing the network issues will be a nightmare, because the 5 Whys analysis probably lands you at Conway's Law around #4 or #5. But, assuming you also have a client-side rendering issue (I don't use JIRA Cloud (yet) but I can vouch that the server product does), you may be able to get some traction just by peeling away an engineer to take a snapshot of the page and see what it takes to produce a page that looks (nearly) identical but renders more quickly. That will not itself be a "solution" but it'll probably provide a lot of insight.

[1]: https://news.ycombinator.com/item?id=22889975

Re: Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

#189

Earlier quoted context omitted.

> A "dream world" would be more like 10ms. A gateway solely adds 50 ms. So I'm not really sure where you get your numbers/benchmarks from... They are unrealistic

What gateways have you been using?! That's a long, long way off on the modern internet. Assuming you mean gateways as in the lines you'd see on a traceroute, more typical might be ~2-5ms on a home router, ~0.5-1.0ms upstream.

Lol, wasn't expecting that :p

Ocelot would be a better example of an gateway https://github.com/ThreeMammals/Ocelot

Used for scaling up web traffic or creating bff's ( backends for frontends)

Re: Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

#190
post #85

This is not surprising: anyone who’s used Atlassian products knows that quality has been job number 97 for years. That doesn’t happen by accident – someone’s made the decision that they’ll make sales anyway and cut the QA budget. One of the most obvious examples: they have multiple WYSIWYG editor implementations which aren’t compatible. When you format something in Jira it’ll look fine in the preview and then render…

This is even worse than the crazy slowness.

I spend 10 minutes to make a detailed bug report, just to have it fall apart after submitting. How does that happen in a software made to show bug reports?

Just use standard markdown instead of your own bullcrap formatting that doesn't ever seem to work.

Post reply on HN