Не пыжился я, это ты начал пузырить (https://www.opennet.ru/openforum/vsluhforumID3/118500.html#21) о том, о чём как выясняется представление имеешь поверхностное.

> а при наращивании числа ядер - закономерно _теряет_ это свое преимущество, упираясь во внутренние локи.

Вот ты думаешь, что ты один это понимаешь? Так вот слезь со стула и перестань страдать капитанством.

> Что твои измеризмы наглядно и демонстрируют - но ты видишь в них фигу, а калькулятор, конечно же, врет у меня.

Ты свои догадки за "наглядно демонстрируют" не выдавай. Твой калькулятор врёт, ещё и потому, что ты делаешь выводы там, где ты их делать не можешь - нет у тебя всей полноты информации о тесте.

> явный показатель что что-то пошло очень криво, и вместо предсказуемого результата за фиксированное время, не смотря на привязку к конкретным ядрам и локнутую память - хваленый мемкэш о чем-то задумался на время, на четыре порядка(!) большее чем обычно. И когда под реальной, а не высосанной из пальца нагрузкой, ВНЕЗАПНО он начнет так задумываться на каждый второй запрос - а, ну да, дЭффехтивный уже в другом месте руководит процессами.

Это твои нелепые догадки не более. То что при интенсивной конкуренции latency деградирует и без твоего капитанства известно, и это не только к memcached относится, но и к redis и к любому другому сетевому сервису, будь в нём один или много тредов, и естественно блокировки оказывают влияние и естественно у любой программы есть потолок насыщения. Но мы тут обсуждаем не это, а то почему redis - не может, а memcached - может.

>твои же измеризмы показали ясно - эффективность "масштабирования" непатченного мемкэша в пределах одного-единственного процессора - менее 50%. Думаю, хуже и ненадежнее сделать с редисом- надо будет постараться.

Всё так-же твой калькулятор тебя агрессивно наё...обманывает. Но ты не сдавайся, однажды ты заставишь его правильно считать.

>А когда ты начнешь те же костыли костылить в приложении (потому что, кто бы мог подумать, уперлись в network latency и все измеризмы с микросекундами пошли лесом, а еще, внезапно, понадобился фэйловер) - они от этого костылями быть перестанут, превратившись в изящнейшие подпорочки.

Ты и про network latency ничего не знаешь, так что не напрягайся.

>ага, согласно твоим же измеризмам, хватит 5-6. При условии, конечно, что не справится и один - а на микросекундные персентили пользователям вообще-то наплевать. При этом они сожрут таки 6 ядер, а не 20, и дадут более предсказуемый результат.

Не обманывай себя, даже с 10 redis'ами, ты будешь страдать и предсказуемости ты не увидишь (разве-что если заведёшь sparc m8 о 5GHz на каждое ядро под solaris с конкретной привязкой каждого redis'а на ядро).

>это решение опять каких-то пейсбукопроблем, а не моих. Кстати, намекающее, что кто-то в сетевую -то уперся. Ну и хрен с ними - это, повторяю, не мои проблемы, у меня совсем другая область применения мемкэшей - и там у них никаких явных преимуществ нет (были в простоте и предсказуемости поведения, но доломаны). А пейсбук у нас, к счастью, один.

Так и не лезь ты со своими микро. А для тех кто знает, что такое LLC и почему redis должен быть сложен в /dev/null, применение memcached оправданно, и применение seastar-memcached оправдано, когда требуется выжать ещё больше за те же деньги.

Ну и вникай в результаты теста родного для redislab - memtier_benchmark:
redis - https://paste.ubuntu.com/p/3DV8HfjpRg/
  
   AGGREGATED AVERAGE RESULTS (10 runs)
   =========================================================================
   Type         Ops/sec     Hits/sec   Misses/sec      Latency       KB/sec
   -------------------------------------------------------------------------
   Sets        21812.85          ---          ---     14.02310      3111.31
   Gets        43495.08     32279.00     11216.07     13.85290      4843.18
   Waits           0.00          ---          ---      0.00000          ---
   Totals      65307.92     32279.00     11216.07     13.90960      7954.49
  
   real    2m41.305s

memcached - https://paste.ubuntu.com/p/Pwqf8sdBVN/
  
   AGGREGATED AVERAGE RESULTS (10 runs)
   =========================================================================
   Type         Ops/sec     Hits/sec   Misses/sec      Latency       KB/sec
   -------------------------------------------------------------------------
   Sets       800396.40          ---          ---      1.07490    107131.09
   Gets      1596000.02   1596000.02         0.00      1.06220    234135.42
   Waits           0.00          ---          ---      0.00000          ---
   Totals    2396396.42   1596000.02         0.00      1.06670    341266.51
  
   real    0m36.168s