• ConcurrentDictionary в роли кэша
    0
    Как-то даже в голову не приходило. Попробовал сейчас прикрутить — как-то не ложиться совсем AsyncEnumerator на задачу. А в целом, хоть и не знаком с SyncGate, думаю, что один локер чтения/записи Рихтера вряд ли окажется сильно лучше другого похожего локера Рихтера. Но интереса ради всё равно попробую.
  • ConcurrentDictionary в роли кэша
    0
    Нет смысла при 80%. Объект исследования — эффективность параллельных операций записи/чтения в коллекции, а не необходимость использования словаря. На практике большинство операций — чтение по ключу. Однако только ими обходиться утопчино. Можно представлять кэш в виде нескольких коллекций, заточнных под конкретную операцию, как вы предлагаете. Даже иногда нужно. Но это требует затрат на синхронизацию, повышает сложность и не всгегда таким образом можно покрыть 100% случаев.
  • ConcurrentDictionary в роли кэша
    0
    Измерялся не сам Dictionary, а его применение в качестве кэша таблиц-справочников. Для них, к сожалению, приходится использовать итератор — тут и поиск нужен, и запрос всех значений. Например, для того чтобы отобразить все элементы для редактирования — нам нужен запрос всех значений. Поиск может понадобиться, например, для фильтра по ParentId. А удаление устаревших это несколько в другую степь — здесь именно справочник, синхронизированный с таблицей в БД.
  • ConcurrentDictionary в роли кэша
    0
    Ну вроде по хорошему так и должно быть, не в 3 раза конечно, но профит должен быть. Собственно по слиму мой основной вывод — я не умею его готовить. Либо его оптимально использовать в каких-то сложных ситуациях. Возможно, кто-то найдёт в исходниках соль проблемы. Но он в любом случае по своей сути не будет быстрее ConcurrentDictionary. Да и OneManyResourceLock наверняка пооптимальнее.
  • ConcurrentDictionary в роли кэша
    0
    dictionary.FirstOrDefault(..) например, или dictionary.Values.ToArray(). Такие операции будут отрабатывать значительно дольше нежели просто чтение данных по ключу. Собственно на графике нарисовано — насколько дольше. Вот таблица с полными данными — yadi.sk/d/n5ycSsDf0O3Sf (в статье ссылка тоже есть).
  • ConcurrentDictionary в роли кэша
    0
    Я имел в виду, что если с такой прорвой данных будут активно работать, то ConcurrentDictionary хотя бы не зависнет в локе намертво, поскольку ему не требуется блокировка для чтения. А насчёт интовского ограничения длины, разумеется, с вами согласен. И не менее согласен насчёт подзатыльников.
  • ConcurrentDictionary в роли кэша
    0
    Да, это главный недостаток подхода с кэшем словарей в целом.
    У нас запись в кэш происходит только после успешного завершения транзакции. Это решает проблему с незавершёнными транзакциями, но не решает проблему того, что порядок выполнения транзакций и порядок записи в кэш могут различаться.
    На текущий момент для нас это проблемой не является — то, что кэшируется, редактируется довольно редко. Пока что можем позволить себе такую волность — релиз ещё не выпускали (делаем новую версию продукта). Но что-то делать с этим будем обязательно. Как вариант могу предложить решение с синхронизацией записи в кэш в соответствии с временем завершения транзакции.
  • ConcurrentDictionary в роли кэша
    +1
    Для отдельного элемента — да. Благодаря линкед-листам ConcurrentDictionary позволяет использовать итератор без блокировки (т.е. одновременно с записью). Эту же задачу, в целом, решает и CopyOnWrite.
    А слабые ссылки позволяют избегать утечек при реализации, т.е. прямого отношения к задаче не имеют.
  • ConcurrentDictionary в роли кэша
    0
    А этих ребят (MemoryCache, ObjectCache) я тоже пробовал — не вписываются в задачу, там и контракт не удобный и время работы не ахти. Всё же их основное назначение обеспечение времени жизни элементов кэша.
  • ConcurrentDictionary в роли кэша
    0
    Здесь растёт доля не всех операций чтений, а только по значению. Операций чтения здесь фиксированно 20%, указанная доля по поси X — доля чтения по значению, то что остаётся — чтение по ключу. Околонулевое время при 0% чтения по значению объясняется малым количеством операций в тесте — получается что запись/чтение по ключу отрабатывает мгновенно. Если увеличить количество операций — увидим ту же картину, но с большими числами, соответственно в нуле будет не 0 по Y, а некое число побольше.
  • ConcurrentDictionary в роли кэша
    0
    Согласен. Такие средства нужны для относительно компактных словарей. А большим данным — большие решения. И, да, без заточки решения под себя, тоже считаю, в этом случае не обойтись.
  • ConcurrentDictionary в роли кэша
    –1
    Не измерял, но теоретически ConcurrentDictionary как-то работать будет. А вот словари с блокировкой помрут я думаю. В принципе это уже несколько иная задача и надо использовать другие средства — не думаю, что гонять итератор по много-гигабайтному словарю хорошая идея.
  • ConcurrentDictionary в роли кэша
    0
    Там измеряли сами блокировки чтения и записи по отдельности. И они естественно проиграли простому как репа монитору. Здесь же чтение и записть происходит одновременно, что позволяет ReaderWriterLocker'у получить преимущество над монитором.
  • ConcurrentDictionary в роли кэша
    –1
    В статье рассматривались только стандартные решения для .NET. Ссылку на исходники я выложил — можно реализовать свой обработчик операций и протестировать. Если речь о проектировании нашего сервера — это офтопик, не хочу вступать в холивары. На данный момент по ряду причин нам больше подходит то решение, которое реализовано.
  • ConcurrentDictionary в роли кэша
    0
    Насколько я знаю, у него как киллер-фича (в отличие от простого ReaderWriterLock) декларировалось то, что по умолчанию выключена поддержка рекурсии, что вроде как должно издержки снижать. Но что-то у меня не получилось с ним подружиться — возможно профит заметен если использовать собственно рекурсию или апгрейды ридера на райтер (которые вроде как тоже улучшались).
  • ConcurrentDictionary в роли кэша
    0
    Вы о LockRecursionPolicy? В приведённых тестах — дефолтная. Пробовал и NoRecursion и SupportsRecursion — разницы нет, в принципе рекурсия то и не используется.
  • Диспетчерская программа АТ-Наблюдатель и отличительные особенности диспетчерских систем для крупных автопарков
    0
    Коллега, а что означает опция «заморозить расположение» на самом первом скриншоте?

    Еще хочу обратить внимание, что при количестве автомобилей даже 10 (не говоря уже о 200) пользователю очень пригодился бы групповой отчет по топливу. Сейчас, при попытке построить отчет по нескольким автомобилям, АТ-Наблюдатьель кричит на пользователя:
    image
    Не гуманно…

    P.S.: Может быть Вы предложите ссылку на демо-версию?
  • Тест-обзор ГЛОНАСС/GPS приемников 2012
    0
    Обратите внимание на результаты Ublox, который тестировался в режиме «только ГЛОНАСС».
  • Тест-обзор ГЛОНАСС/GPS приемников 2012
    0
    Цель указана в моем комментарии повыше. Действительно, отличия не значительные, но лидеров выявить нам удалось.
  • Тест-обзор ГЛОНАСС/GPS приемников 2012
    +1
    Спасибо за ваши комментарии. Так сложилось, что наших заказчиков интересует не «истинное положение вещей» без учета фильтра Калмана, а что бы «машинки через дома не летали». Поэтому и проводили реальную обкатку и выводы делали операясь на повторяемые аномалии на треке на скольких приборах.
  • Тест-обзор ГЛОНАСС/GPS приемников 2012
    0
    Спасибо за замечания и советы. Изначально тестирование делалось для себя и поэтому не фотографировали антенны и как все установлено. Потом, когда собрали все и проанализировали, решили поделиться информацией на Хабре.

    На идентичных скриншотах видны треки с одной поездки одного автомобиля с сколькими трекерами. Мы специально отобрали именно нехорошие участки треков, т.к. 99% времени все ОК. Ваши сомнения очень уместны и для принятия решения советую проводить такое сравнение в своих условиях эксплуатации. Еще разные прошивки чипов могут влиять на результат в сложных условиях, так что возможно чере месяц рейтинг уже изменится.