The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Присылайте удачные настройки в раздел примеров файлов конфигурации на WIKI.opennet.ru.
. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." +/
Сообщение от пох. (?), 23-Сен-19, 17:41 
> Твои проблемы

твои - ты же пыжился тут кому-то что-то втереть.

> Мне это не нужно, уже давно всё измерено и взвешено. И миллисекунды складываются в секунды.

узнаю, узнаю дЭффехтивных менеджеров. Они вообще не складываются.

> Не доверяй ты своему потолочному калькулятору, он у тебя врёт.

он у меня не врет - а ты не умеешь даже собственные данные оценивать. (впрочем, пейсбуковцы плакались о той же проблеме)
> memcached даже c -t 1 вывозит в 2,6 раза больше с в 2,6 раза меньшей latency:

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

> Это не интересно и совершенно не имеет смысла это изучать, т.к. известно, что программа
> выполняется в ОС с вытесняющей многозадачностью.

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

> Уясни наконец, что redis масштабируется через костыли.

спасибо, что бы я без тебя делал.

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

> И там где справится один memcached, не нужно разводить 10-20 редисов.

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

При этом они сожрут таки 6 ядер, а не 20, и дадут более предсказуемый результат.

> есть memcached на стеройдах - на seastar с dpdk.

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

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..., opennews, 18-Сен-19, 22:35  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру