That's better, but that still leaves 53% reduction in performance. We don't see that, and it's hard to understand where it would come from. 0.2 msec still looks big. Our total RTT for a read is a bit over 0.3 msec, for data that comes from cache, which is 95% of it. We're using a generic Dell server with Ubuntu 22.04, i.e. kernel 5.15. I do see a big slowdown from krb5p, but that's not so surprising. krb5p: 3:25 krb5: 1:38 sys: 1:29 I guess it's possible that their server is so much more efficient that the sec=sys performance is a lot faster, and so the difference is greater. From: Olga Kornievskaia <aglo@xxxxxxxxx> Sent: Tuesday, February 14, 2023 9:53 AM To: Charles Hedrick <hedrick@xxxxxxxxxxx> Cc: Wang Yugui <wangyugui@xxxxxxxxxxxx>; linux-nfs@xxxxxxxxxxxxxxx <linux-nfs@xxxxxxxxxxxxxxx> Subject: Re: question about the performance impact of sec=krb5 On Mon, Feb 13, 2023 at 1:53 PM Olga Kornievskaia <aglo@xxxxxxxxx> wrote: > > On Mon, Feb 13, 2023 at 1:02 PM Charles Hedrick <hedrick@xxxxxxxxxxx> wrote: > > > > those numbers seem implausible. > > > > I just tried my standard quick NFS test on the same file system with sec=sys and sec=krb5. It untar's a file with 80,000 files in it, of a size typical for our users. > > > > krb5: 1:38 > > sys: 1:29 > > > > I did the test only once. Since the server is in use, it should really be tried multiple times. > > > > krb5i and krb5p have to work on all the contents. I haven't looked at the protocol details, but krb5 with no suffix should only have to work on headers. 3.2 msec increase in latency would be a disaster, which we would certainly have noticed. (Almost all of our NFS activity uses krb5.) > > > > It is particularly implausible that latency would increase by 3.2 msec for krb5, 0.6 msec for krb5i and 1.6 for krb5p. krb5 encrypts only security info. krb5p encrypts everything. Perhaps they mean 0.32 msec? We'd even notice that, but at least it would be consistent with krb5i and krb5p. > > Actually they really did mean 3.2. Here's another reference that > produces similar numbers : > https://www.netapp.com/media/19384-tr-4616.pdf . Why krb5 perf gets > higher latency then the rest is bizarre and should have been looked at > before publication. Nevermind. After some investigation, it turns out the public report has a typo, it should have been 0.2ms. Hopefully they'll fix it. > > From: Wang Yugui <wangyugui@xxxxxxxxxxxx> > > Sent: Sunday, February 12, 2023 1:01 AM > > To: linux-nfs@xxxxxxxxxxxxxxx <linux-nfs@xxxxxxxxxxxxxxx> > > Subject: question about the performance impact of sec=krb5 > > > > Hi, > > > > question about the performance of sec=krb5. > > > > https://learn.microsoft.com/en-us/azure/azure-netapp-files/performance-impact-kerberos > > Performance impact of krb5: > > Average IOPS decreased by 53% > > Average throughput decreased by 53% > > Average latency increased by 3.2 ms > > > > and then in 'man 5 nfs' > > sec=krb5 provides cryptographic proof of a user's identity in each RPC request. > > > > Is there a option of better performance to check krb5 only when mount.nfs4, > > not when file acess? > > > > Best Regards > > Wang Yugui (wangyugui@xxxxxxxxxxxx) > > 2023/02/12 > >
