Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

atlassian.com

Post reply on HN
Print view View original

251–260 of 305 posts

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

#251

Post by NicoJuicy »

BillinghamJ wrote: post #191
NicoJuicy wrote: post #189

Earlier quoted context omitted.

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)

Ah nice, I didn't realise you meant application proxies/gateways. Network ones are so quick due to their ASICs etc! I personally would still say 50ms is super, super slow for an application gateway - a well designed one using e.g. nginx/openresty, lambda@edge, or simply writing another application server etc can easily do that job with an addition of If it is e.g. making a DB request to check auth, I would highlight…

Ocelot - localhost => 40-50 ms on a workstation.

Gateways can add a lot of functionality. Even Graphql can be used as a gateway.

It's not all "dumb forwarding" and I would be very surprised that you find any sub ms benchmarks.

Amazon has a one million dollar award if you get the page to load under 10 ms. So that's what you are expecting by default on a saas in your previous comment.

It's still unrealistic.

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

#252

Post by confluence_perf »

texasbigdata wrote: post #238
confluence_perf wrote: post #153

Earlier quoted context omitted.

Thank you for coming back and clarifying. Do you happen to have links to any public testing results of other tools, or guidance to this specificity - would love to use them to build a case internally Most of what we've seen online are nowhere near this level of detail (X-ms for Y-%ile for Z-type of load) (edit: clarified request)

Not to be a jerk, but you guys don’t allow others to take your performance metrics, but you’re publicly soliciting performance data from other products at the same time? I’m assuming you’re taking it for granted they don’t have a ToS that bans you from doing this. Sorry if that’s pointed, but it’s sort of meant to be incredulous (but hopefully not offensive).

Not offended - as an employee I have no specific insight into the actual headline term in the ToS - honestly I'm planning on tracking down someone in legal to help clarify this, since it seems like it currently as written (and currently as interpreted in worst case) unecessarily impedes me from doing my job.

I would never encourage anyone to violate a ToS of another product and apologize for anyone that was considering doing it due to my ask.

I think these are other possibilities: 1) (as stated) other products don't have such ToS 2) other products may have published their own metrics and made them available for consumption 3) from a more legal in depth standpoint, maybe other companies have such ToS terms but have clarified them to some point that makes them more clear about when they apply and when they don't

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

#253

Post by texasbigdata »

confluence_perf wrote: post #252
texasbigdata wrote: post #238

Earlier quoted context omitted.

Not to be a jerk, but you guys don’t allow others to take your performance metrics, but you’re publicly soliciting performance data from other products at the same time? I’m assuming you’re taking it for granted they don’t have a ToS that bans you from doing this. Sorry if that’s pointed, but it’s sort of meant to be incredulous (but hopefully not offensive).

Not offended - as an employee I have no specific insight into the actual headline term in the ToS - honestly I'm planning on tracking down someone in legal to help clarify this, since it seems like it currently as written (and currently as interpreted in worst case) unecessarily impedes me from doing my job. I would never encourage anyone to violate a ToS of another product and apologize for anyone that was consideri…

Sorry you have to work on this thread on vacation dude (or girl). This thread has been an absolute beat down and you’ve treated it with utmost professionalism when it’s pretty clear you’re new to the team. It is Saturday night after all.

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

#254

Post by confluence_perf »

texasbigdata wrote: post #253
confluence_perf wrote: post #252

Earlier quoted context omitted.

Not offended - as an employee I have no specific insight into the actual headline term in the ToS - honestly I'm planning on tracking down someone in legal to help clarify this, since it seems like it currently as written (and currently as interpreted in worst case) unecessarily impedes me from doing my job. I would never encourage anyone to violate a ToS of another product and apologize for anyone that was consideri…

Sorry you have to work on this thread on vacation dude (or girl). This thread has been an absolute beat down and you’ve treated it with utmost professionalism when it’s pretty clear you’re new to the team. It is Saturday night after all.

I appreciate the well wishes, honestly it means a lot - good guess too, I am in the US (maybe you knew, but most of Confluence Cloud is based out of the West Coast offices).

I don't know what the overlap is between Atlassian users and IT admins though - my previous job was on the vSphere UI and if you happen to know about the death of the Flash based client, this is not too far off.

Hopefully users stay willing to engage with us so we can improve the product as fast as possible.

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

#255

Post by andrewflnr »

confluence_perf wrote: post #41
burnthrow wrote: post #35

Earlier quoted context omitted.

Come on, everything is slow and you know it.

We have certainly heard from some customers that agree that 'everything' is slow, but we've also heard from other customers saying they have no problems. We would love to fix "everything", and we have some longer term projects focused on this -> However, "everything" fixes seem to be a more incremental boost and also take longer time to complete. If you have any feedback about "specific" items that are the most frust…

Jira obviously has systemic performance problems that a few users have fast enough computers or networks to push through. There will be no shortcut to "targeted fixes" for "greater gains".

Persistently asking for particular workflows, as you've been doing throughout this thread, shows a failure to understand the scope of the problem. In fact it makes me wonder if your paycheck depends on not understanding it. It sure seems like someone's does.

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

#256

Post by ZephyrBlu »

fphhotchips wrote: post #214
BillinghamJ wrote: post #138

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…

Do you have evidence that what you're asking for is possible? I'd be interested to see websites that hit the benchmark that you're aiming for. I just tested a HN profile page (famously one of the lightest weight non-static websites) and it takes between 300ms and 600ms to load. I'm not saying that Jira can't improve, but if HN isn't hitting 250ms then I think telling the Jira guys that nothing less than <200ms is the…

200ms for user interactions is different to a 200ms page load.

A 200ms page load is incredibly fast.

Still, I tested your profile page on Google PageSpeed and it came out at a 300ms load time.

https://developers.google.com/speed/pagespeed/insights/?url=...

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

#257

Post by uuuugh »

Judgmentality wrote: post #224
hadrien01 wrote: post #221

Earlier quoted context omitted.

They use the on-premises version, which is much faster: https://jira.atlassian.com/secure/Dashboard.jspa

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.

What the guy above said is not true. Jira Cloud uses Jira Cloud to manage their projects.

https://www.youtube.com/watch?v=hY91A_4Mbts

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

#258

Post by confluence_perf »

uuuugh wrote: post #257
Judgmentality wrote: post #224

Earlier quoted context omitted.

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.

What the guy above said is not true. Jira Cloud uses Jira Cloud to manage their projects. https://www.youtube.com/watch?v=hY91A_4Mbts

Both right

a) the public facing jira.atlassian.com is Server/DC instance - but this instance is only used for customer/outside world facing tickets (I think)

b) internally for our own development we use a few (several?) cloud instances -> but I can only speak to those I interact with (Conf Cloud and Jira Cloud primarily).

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

#260

Post by samb1729 »

dalrympm wrote: post #22

I'm curious, I'm a Cloud customer and I can tell you that the service is incredibly slow even for a small scale setup (2 Jira Projects and 3 Confluence Workspaces). There's an insane amount of network requests seemingly for mouse tracking. By telling everyone here, that Atlassian Cloud products are insufferably slow, am I violating the ToS? I was actually thinking about doing a write up on the issues I've had but thi…

Atlassian products in general spray out a huge number of requests to dozens of hostnames for even the most basic of actions. It scares me to think how their organisation is structured internally given the outwardly visible result.

If you’d like to see it for yourself, run Little Snitch in alert mode and try to sign into bitbucket.org - it’s almost comical how many hoops your browser jumps through.

Post reply on HN