Возможно, проблема в вычитывании результатов, которые присылает Redis - т.к. его подключение это последовательная TCP сессия - в каком порядке запросы отправлены - в таком порядке ответы придут обратно, никаких идентификаторов у ответов нет. Соответственно, если что-то не было вычитано или вычитали лишнего - все запросы этого подключения дальше будут с кривыми данными. Еще я видел ситуации, когда один и тот-же ключ использовали под разные типы данных или клали одно а пытались вычитать другое, помогала типизация ключей на клиенте. Или это были одинарные ошибки?
Если одинарные ошибки и дальше соединение работает корректно, то похоже библиотека неправильно возвращала результат в вызывающий, тут ничего не скажу, не знаком с асинхронностью в PHP.
По поводу 100% загрузки ноды запросами по одному ключу, а это не могла быть библиотека с каким-нибудь бесконечным retry в случае неудачи? Во всяком случае, я бы попробовал отследить источник проблем, имхо, это либо вызывающий код или библиотека.
Лучшее решение все-таки Parallel.For/Parallel.ForEach так как никаких замыканий практически не создается.
2-3КБ которые аллоцируются на Parallel - это внутренние таски/структуры, необходимые для метода. Например, в вашем тесте можно поменять количество хэндлеров-заданий с 10 на 400 и получить уже совсем другую картину:
| Method | Mean | Error | StdDev | Median | Ratio | RatioSD | Gen 0 | Gen 1 | Allocated |
|---------------- |-----------:|----------:|-----------:|-----------:|------:|--------:|-----------:|---------:|----------:|
| AutoClosure | 132.774 ms | 9.6346 ms | 28.4079 ms | 137.038 ms | 1.00 | 0.00 | 10500.0000 | 750.0000 | 64 MB |
| ParallelFor | 7.057 ms | 0.1364 ms | 0.1912 ms | 7.142 ms | 0.07 | 0.01 | 421.8750 | - | 3 MB |
| ParallelForeach | 7.415 ms | 0.0224 ms | 0.0209 ms | 7.418 ms | 0.08 | 0.01 | 453.1250 | - | 3 MB |
| SelfClosure | 102.784 ms | 2.4890 ms | 7.2998 ms | 105.092 ms | 0.81 | 0.19 | 4500.0000 | 333.3333 | 27 MB |
Кстати, перфоманс AutoClosure/SelfClosure такой низкий из-за слишком маленьких заданий - рантайм тратит больше времени на шедулинг чем на сами задания, где-то был доклад или статья по этому поводу.
Возможно я чего-то не понимаю, но в итоге получается какая-то странная реализация стратегии! Обычно у нас есть несколько реализаций стратегии, и мы передаем нужную стратегию в объект.
А в вашем примере Engine.GetFromWarehouse() это service locator почти в чистом виде.
Лучше уж сразу использовать DI в таком случае и уже на стороне контейнера настраивать логику инъекции двигателя.
Спасибо за статью.
А можете поподробней рассказать чем радиация для микросхем опасна? Знакомый сказал, что транзисторы теряют свои свойства от накапливающийся дозы/активации
п.с. роботы не столько сами активируются, сколько набирают на себя радиоактивной пыли/частиц.
Возможно, проблема в вычитывании результатов, которые присылает Redis - т.к. его подключение это последовательная TCP сессия - в каком порядке запросы отправлены - в таком порядке ответы придут обратно, никаких идентификаторов у ответов нет. Соответственно, если что-то не было вычитано или вычитали лишнего - все запросы этого подключения дальше будут с кривыми данными. Еще я видел ситуации, когда один и тот-же ключ использовали под разные типы данных или клали одно а пытались вычитать другое, помогала типизация ключей на клиенте. Или это были одинарные ошибки?
Если одинарные ошибки и дальше соединение работает корректно, то похоже библиотека неправильно возвращала результат в вызывающий, тут ничего не скажу, не знаком с асинхронностью в PHP.
По поводу 100% загрузки ноды запросами по одному ключу, а это не могла быть библиотека с каким-нибудь бесконечным retry в случае неудачи? Во всяком случае, я бы попробовал отследить источник проблем, имхо, это либо вызывающий код или библиотека.
Лучшее решение все-таки Parallel.For/Parallel.ForEach так как никаких замыканий практически не создается.
2-3КБ которые аллоцируются на Parallel - это внутренние таски/структуры, необходимые для метода. Например, в вашем тесте можно поменять количество хэндлеров-заданий с 10 на 400 и получить уже совсем другую картину:
Кстати, перфоманс AutoClosure/SelfClosure такой низкий из-за слишком маленьких заданий - рантайм тратит больше времени на шедулинг чем на сами задания, где-то был доклад или статья по этому поводу.
Да, DI и service locator часто используют вместе, не буду спорить. В примере на стороне ioc-контейнера будет как раз стоять фабрика/стратегия.
А в вашем примере Engine.GetFromWarehouse() это service locator почти в чистом виде.
Лучше уж сразу использовать DI в таком случае и уже на стороне контейнера настраивать логику инъекции двигателя.
А можете поподробней рассказать чем радиация для микросхем опасна? Знакомый сказал, что транзисторы теряют свои свойства от накапливающийся дозы/активации
п.с. роботы не столько сами активируются, сколько набирают на себя радиоактивной пыли/частиц.