4 ms·

Would you be able to post some ballpark figures, please?

Abishek_Muthian 9y ago
Actually, there is not any measurable difference. Our architecture is completely state-less and when compared with equivalent load there's no difference at all. I guess, default network throughput bottle-neck itself is higher than the random memory cache bottle-neck in my case. There was no impact on the latency either. Fearing automatic update by AWS resulting in performance issue, we rushed to update all our serves and gladly there weren't any performance impact. I don't think not every one has been fortunate, there's still lot of variables reg performance impact of KPTI. This user here using PHP server mentioning 50% performance - https://twitter.com/timgostony/status/948682862844248065 https://twitter.com/timgostony/status/948682862844248065 and of-course OP issue is being covered here.
- bartread 9y ago
  Thanks - this is what's worrying me: the result of patching seems to be all over the map, and it's somewhat hard to predict. My biggest worry is SQL Server, so our plan is to fix a performance issue we isolated recently before we patch - I'd like that system running optimally before we take the hit.
  - Abishek_Muthian 9y ago
    Judging from our MongoDB instance, I'm optimistic that your SQL server wouldn't face much impact either. Even Redhat tests put the risk at modest. But for something like Redis, the case could be different. If you are on a cloud provider, do check that automatic update is not scheduled; if so it's better to update manually to follow up with mitigation if necessary.
    - dijit 9y ago
      This is almost entirely subjective and workload dependent. We know that the biggest performance factor in both of these patches (spectre, meltdown) is the kernel boundary. So saying something along the lines of "Redis is more affected than Mongo" is.. odd. MongoDB (I HOPE) will save files more frequently than redis, since redis is primarily in in-memory DB with some lazy IO access (depending on configuration). So if you have a lot of small network calls to redis (which, is a kernel boundary event.) then it will be more impacted than a mongodb which takes only a few very large requests. My gut is that the opposite would be true for the same workloads on both, MongoDB needs its files to return data, redis doesn't. Even the vfs-cache is in kernel "space", so if your entire data sat in vfs cache it wouldn't help. But that's my gut, and your exact usage may not mirror the 1:1 of this scenario.
- justin66 9y ago
  > Actually, there is not any measurable difference. That doesn't strike you as a little odd?
  - discoursism 9y ago
    It's the same result as Google apparently observed across their fleet. It doesn't seem like it should be that odd.
lukeschlather 9y ago
I would agree that so far there doesn't appear to be any measurable difference for a typical web application. We have some heavy postgres data crunching jobs that might be affected but based on the examination I've done so far I'm inclined to say those weren't affected either.

Actually, there is not any measurable difference. Our architecture is completely state-less and when compared with equivalent load there's no difference at all. I guess, default network throughput bottle-neck itself is higher than the random memory cache bottle-neck in my case. There was no impact on the latency either. Fearing automatic update by AWS resulting in performance issue, we rushed to update all our serves and gladly there weren't any performance impact. I don't think not every one has been fortunate, there's still lot of variables reg performance impact of KPTI. This user here using PHP server mentioning 50% performance - https://twitter.com/timgostony/status/948682862844248065 https://twitter.com/timgostony/status/948682862844248065 and of-course OP issue is being covered here.

bartread 9y ago
Thanks - this is what's worrying me: the result of patching seems to be all over the map, and it's somewhat hard to predict. My biggest worry is SQL Server, so our plan is to fix a performance issue we isolated recently before we patch - I'd like that system running optimally before we take the hit.
- Abishek_Muthian 9y ago
  Judging from our MongoDB instance, I'm optimistic that your SQL server wouldn't face much impact either. Even Redhat tests put the risk at modest. But for something like Redis, the case could be different. If you are on a cloud provider, do check that automatic update is not scheduled; if so it's better to update manually to follow up with mitigation if necessary.
  - dijit 9y ago
    This is almost entirely subjective and workload dependent. We know that the biggest performance factor in both of these patches (spectre, meltdown) is the kernel boundary. So saying something along the lines of "Redis is more affected than Mongo" is.. odd. MongoDB (I HOPE) will save files more frequently than redis, since redis is primarily in in-memory DB with some lazy IO access (depending on configuration). So if you have a lot of small network calls to redis (which, is a kernel boundary event.) then it will be more impacted than a mongodb which takes only a few very large requests. My gut is that the opposite would be true for the same workloads on both, MongoDB needs its files to return data, redis doesn't. Even the vfs-cache is in kernel "space", so if your entire data sat in vfs cache it wouldn't help. But that's my gut, and your exact usage may not mirror the 1:1 of this scenario.
justin66 9y ago
> Actually, there is not any measurable difference. That doesn't strike you as a little odd?
- discoursism 9y ago
  It's the same result as Google apparently observed across their fleet. It doesn't seem like it should be that odd.

lukeschlather 9y ago

I would agree that so far there doesn't appear to be any measurable difference for a typical web application. We have some heavy postgres data crunching jobs that might be affected but based on the examination I've done so far I'm inclined to say those weren't affected either.