Штука забавная, но за такую цену бесполезная.
У всех есть смартфоны (на анродиде у многих :)), программа RaceChorono большую часть указанных вещей умеет делать даже в бесплатной версии, а полная стоит 1000р. В полной, она умеет писать видео, и потом накладывать на него настаиваемые виджеты, а так же умеет писать лог с OBD адаптера. Кстати, китайский ODB адаптер стоит в районе 10-15$. Так что в итоге, имеющийся телефон + 30$ на программу и адаптер позволяют писать и анализировать кучу данных.
Не совсем так: воркер получил порцию юзеров, для которых надо поработать. Он взял из кэша данные и держит в локальной переменной. Значит данные не умрут по он их не отпустит. Параллельный поток воркера тоже смог взять данные из кэша и так далее, пока все юзеры не обработаны. А дальше, именно как мне надо: все юзеры по данным статьям обработаны, и пусть данные умирают при первой же сборке.
Да, но любое количество читателей могут встать в очередь на EnterWriteLock и после моей первой записи войти туда и опять начать дёргать базу. А это нам не нужно.
Давайте я подробнее опишу для чего я сделал именно такую реализацию, может появятся идеи как лучше сделать.
У меня в базе хранится список лучших статей за день (грубо говоря 100 значений типа long). Также у меня есть 100500 юзеров (ориентир именно на 100к, хотя реально поменьше сейчас). Итоговый список лучших статей для каждого юзера уникальный, то есть его надо генерить на основании общего списка и некоторых данных по юзеру. Для распределения работы я использую шину (RabbitMQ).
Загружаю из базы все ид юзеров и пачками по 100 отправляю их на шину (то есть в одном сообщении лежит 100 ид юзеров), а также ключ для списка лучших статей.
В обработчике, я поднимаю из базы список лучших статей, поднимаю данные по каждому юзеру, нахожу какие конкретно статьи нужно отправить данному юзеру и отправляю ему письмо.
Описанный выше кэш, я сделал, чтобы в рамках одного воркера не нужно было хотя бы каждый раз загружать список лучших статей. Они поднимутся один раз, при обработке первого пакета и будут висеть.
Более хорошего, чем WeakReference способа очистки я сходу не придумал, т.к. воркеры без состояния, они не могут знать были все данные отправлены или нет и не знают когда надо очистить кэш.
Второй вариант у меня был просто по времени, но показалось как-то не красиво.
Нет смысла использовать ConcurrentDictionary, т.к. мне всё равно нужно блокировать всю коллекцию для очищения мёртвых ссылок.
WeakReference принимает только class и на практике мне не нужно кэшировать структуры. Что int кэшировать что ли? Свои структуры я использую крайне редко, только когда это продиктовано ограничениями по производительности (нужно часто и по многу создавать экземпляры).
Полностью согласен, именно это я и предлагаю. У меня правда зарядник не за 30, а чуток подороже, но сути это не меняет. Я сразу предложил, просто сделать пару полных циклов и сразу будет видна настоящая ёмкость.
Просто ваш уровень паранойи ниже, чем мой :) Вот примеры для развития паранойи:
— Вы видели исходный код реализации HTTS, который работает у вас?
— Если даже видели, вы полностью его понимаете на столько, чтобы увидеть, что закладок нет?
— Если даже код совсем верный, вы полностью понимаете математику шифрования, что увидеть, что в ней нет закладок, и нет возможности быстрой дешифровки без ключа?
— Ваши телефоны, которые являются конечными устройствами, точно не могу передавать в apple приватные ключи? а по запросу FBI? Вполне возможно хранить некоторое время шифрованный трафик, а при необходимости получить ключи с телефона. Да, они должны генерироваться всё время новые. А вы в курсе, что в известных библиотеках уже находили ошибки, из-за которых имея несколько текущих ключей, можно было прогнозировать следующие и угадывать старые (потому что ключ сильно зависел от времени). Таким образом телефону даже не нужно хранить все ключи, что он генерил.
Короче это большая тема. Я предпочитаю думать, что я ничем таким не занимаюсь и не интересен спец службам. Так спокойнее всего.
А вы не слышали о скандале, который лет 10 назад был вокруг PGP, именно потому что это была открытая технология, которая позволяла всё что хочешь шифровать и спецслужбы потом не могли прочитать? Вроде бы в итоге в суде отстояли, что как open source её можно распространять, а так хотели совсем запретить.
SSH и всё остальное, это ваши личные возможности как частного пользователя. А вот для получения лицензии на услуги связи или для лицензировании аппарата для связи, он должен поддерживать дешифровку всего что передаёт.
Так что, в принципе, вы можете написать программу или найти готовую, которая будет всё шифровать и иметь безопасный канал. Но используя стандартные возможности телефона, о которых говорится в статье, вы доступны для слежки.
По поводу «официально заявления». Я не большой специалист, но думаю юристы apple смогли написать верную формулировку, иначе бы этого заявления просто не было.
Данные из этих сервисов не могут быть расшифрованы Apple и соответственно не передаются органам
Это откровенно враньё. Любой оператор связи и производитель устройств для связи вам скажет: чтобы пройти лицензирование, он должен иметь возможность просмотреть ВСЕ сообщения, которые через него проходят и обязан дать доступ спец службам по запросу.
Более того, не знаю как в США, а у нас если вы сами дома изготовите подобное устройство и вас с ним поймают, то вы будете отвечать по уголовному кодексу, т.к. незаконно изготовили и применяли спецсредство (тоже самое как скрытые камеры и т.п.)
Так что это всё лапша, которую маркетологи вешают на уши наивным юзерам.
А теперь фанатики apple могут менять минусовать, но это не отменит глобальной слежки за вами :)
Вот ещё вопрос: если у вас так всё круто и вы имеете доступ к прорывной технологии батарей. Почему бы тогда не сделать батарею стандартного размера, но ёмкостью около 4000мАч? Судя по параметрам текущей батареи это возможно.
И это был бы действительно крутой продукт, который не уродует телефон и продлевает его жизнь на 70%.
Конечно причины могут быть разные, но скорее всего, вам пришлось сделать батарею больше, чтобы она реально была хотя бы чуть-чуть больше родной батареи по ёмкости и пользователи не сдавали её в магазин через пару дней :)
Можете дать ссылку на какое-нибудь описание технологии, что за тип ячеек и т.п.?
Всегда интересно: почему такой гигант как самсунг не использует новый тип ячеек? Варианты ответов:
— их не существует
— они не стабильны и ответственная компания не хочет их включать в свои продукты
— они имеют очень малое время жизни
ну и т.п.
Дело в том, что я уже давно слежу за всем, что связано с литиевыми батареями. И в теории и на практике (занимаюсь моделизмом и использую разные батареи). Пока что все «новые» технологии, на поверку оказываются обычными LiPo, с теми же характеристиками что и раньше.
А по вашему выходит, что допустим родной аккум имеет толщину 4мм, добавив 10%, вы увеличили ёмкость более чем на 100%. То есть почти в два раза повысили плотность энергии. Это мировой рекорд и прорыв в технологии аккумуляторов какой-то. Никому не известный правда… :)
То есть, толщина оригинального телефона 7.9мм. А с вашим чудо-аккумулятором 8.3. Вы хотите сказать, что добавив всего 0.4мм к толщине смогли удвоить ёмкость? Очень смахивает на чудесные китайские флешки на 64гига за 1 бакс, которые только в свойствах системы эти 64гб показывали, а реально там было памяти на 1-2 гига.
Если дадите аккум на тест, готов провести проверку с помощью хоббийного зарядного устройства: полный разряд, полный заряд, чтобы проверить фактическую ёмкость батареи.
По мне так, тут есть ещё одна, но очень большая разница:
Когда файлы в облаке, они висят как раз больших, мощных серверах, с широкими каналами. И доступ к этим файлам после авторизации есть из любого места с интернетом. А в данном случае, все данные висят в частных хранилищах. Вполне вероятна ситуация, как с торрентами: когда часть файлов недоступна, либо скорость очень низкая, потому что плохой/загруженный канал там где твои файлы (включая твой дом).
Ну и верно пишут: чтобы работал бекап, диск должен быть минимум на 2ТБ, а скорее всего на 3-4, чтобы побольше копий можно было разместить.
А что поток будет делать пока не получит объект? У вас что, ещё и каждый поток должен уметь несколько раз попробовать? На мой взгляд это очень не типично для пулов. Пул должен либо вернуть существующий объект, либо создать новый, либо бросить исключение, если по какой-то причине невозможно вернуть объект (кончилась память, достигнут жёсткий лимит на кол-во объектов).
Повторюсь: для данной задачи, синхронизация с блокировками будет тривиальной в реализации, полностью надёжной/корректной, и почти никак не скажется на производительности реального приложения.
Я считаю, что не нужно усложнять. Это из серии микрооптимизаций, вместо X /2 писать X >> 1 :)
При этом, сами по себе синхронные примитивы вроде ConcurrentDictionary мне очень нравятся, они особенно хороши, когда много потоков пишет одновременно. Тогда есть очень большой выигрыш. Если же, пишет 1-2 потока, то обычный Dictionary + ReaderWriterLockSlim работает никак не хуже, а логика работы опять же оказывается проще.
У вас в коде есть race condition. Т.к. фактическое добавление/удаление объектов не атомарно с изменением счётчика. Так сходу, ничего особо криминального из побочных эффектов назвать не могу. Но как минимум могут быть ложные срабатывания ограничителя: то есть объект в пул ужу вернули, а счётчик ещё не обновился и другой поток не сможет получить экземпляр.
Lock-free это всё круто, но надо ещё учитывать реальную частоту, с которой будут идти обращения к пулу. Вот в вашем, примере идёт работа с сокетами. Любое обращение к сети в 1000 и более раз медленнее, чем время переключения потоков/синхронизации. Так что, если написать такой же пул с обычным List и помечать какой свободен, а какой занят, то реальная производительность приложения вряд ли будет отличаться хотя бы на 1%.
Хотя при этом, конечно, синтетический тест lock-free пул будет быстрее.
1.5 Это полезная мощность, которую БП могут отдать. А берут из розетки они в соответствии со своей эффективность. При пиковой загрузке, она обычно не выше 80%, а то и ниже. Ну и как я отметил: это верхняя планка, просто чтобы оценить возможные затраты. Конечно в реальности, может быть и в 2-3 раза меньше.
У всех есть смартфоны (на анродиде у многих :)), программа RaceChorono большую часть указанных вещей умеет делать даже в бесплатной версии, а полная стоит 1000р. В полной, она умеет писать видео, и потом накладывать на него настаиваемые виджеты, а так же умеет писать лог с OBD адаптера. Кстати, китайский ODB адаптер стоит в районе 10-15$. Так что в итоге, имеющийся телефон + 30$ на программу и адаптер позволяют писать и анализировать кучу данных.
У меня в базе хранится список лучших статей за день (грубо говоря 100 значений типа long). Также у меня есть 100500 юзеров (ориентир именно на 100к, хотя реально поменьше сейчас). Итоговый список лучших статей для каждого юзера уникальный, то есть его надо генерить на основании общего списка и некоторых данных по юзеру. Для распределения работы я использую шину (RabbitMQ).
Загружаю из базы все ид юзеров и пачками по 100 отправляю их на шину (то есть в одном сообщении лежит 100 ид юзеров), а также ключ для списка лучших статей.
В обработчике, я поднимаю из базы список лучших статей, поднимаю данные по каждому юзеру, нахожу какие конкретно статьи нужно отправить данному юзеру и отправляю ему письмо.
Описанный выше кэш, я сделал, чтобы в рамках одного воркера не нужно было хотя бы каждый раз загружать список лучших статей. Они поднимутся один раз, при обработке первого пакета и будут висеть.
Более хорошего, чем WeakReference способа очистки я сходу не придумал, т.к. воркеры без состояния, они не могут знать были все данные отправлены или нет и не знают когда надо очистить кэш.
Второй вариант у меня был просто по времени, но показалось как-то не красиво.
WeakReference принимает только class и на практике мне не нужно кэшировать структуры. Что int кэшировать что ли? Свои структуры я использую крайне редко, только когда это продиктовано ограничениями по производительности (нужно часто и по многу создавать экземпляры).
— Вы видели исходный код реализации HTTS, который работает у вас?
— Если даже видели, вы полностью его понимаете на столько, чтобы увидеть, что закладок нет?
— Если даже код совсем верный, вы полностью понимаете математику шифрования, что увидеть, что в ней нет закладок, и нет возможности быстрой дешифровки без ключа?
— Ваши телефоны, которые являются конечными устройствами, точно не могу передавать в apple приватные ключи? а по запросу FBI? Вполне возможно хранить некоторое время шифрованный трафик, а при необходимости получить ключи с телефона. Да, они должны генерироваться всё время новые. А вы в курсе, что в известных библиотеках уже находили ошибки, из-за которых имея несколько текущих ключей, можно было прогнозировать следующие и угадывать старые (потому что ключ сильно зависел от времени). Таким образом телефону даже не нужно хранить все ключи, что он генерил.
Короче это большая тема. Я предпочитаю думать, что я ничем таким не занимаюсь и не интересен спец службам. Так спокойнее всего.
SSH и всё остальное, это ваши личные возможности как частного пользователя. А вот для получения лицензии на услуги связи или для лицензировании аппарата для связи, он должен поддерживать дешифровку всего что передаёт.
Так что, в принципе, вы можете написать программу или найти готовую, которая будет всё шифровать и иметь безопасный канал. Но используя стандартные возможности телефона, о которых говорится в статье, вы доступны для слежки.
По поводу «официально заявления». Я не большой специалист, но думаю юристы apple смогли написать верную формулировку, иначе бы этого заявления просто не было.
Это откровенно враньё. Любой оператор связи и производитель устройств для связи вам скажет: чтобы пройти лицензирование, он должен иметь возможность просмотреть ВСЕ сообщения, которые через него проходят и обязан дать доступ спец службам по запросу.
Более того, не знаю как в США, а у нас если вы сами дома изготовите подобное устройство и вас с ним поймают, то вы будете отвечать по уголовному кодексу, т.к. незаконно изготовили и применяли спецсредство (тоже самое как скрытые камеры и т.п.)
Так что это всё лапша, которую маркетологи вешают на уши наивным юзерам.
А теперь фанатики apple могут менять минусовать, но это не отменит глобальной слежки за вами :)
И это был бы действительно крутой продукт, который не уродует телефон и продлевает его жизнь на 70%.
Конечно причины могут быть разные, но скорее всего, вам пришлось сделать батарею больше, чтобы она реально была хотя бы чуть-чуть больше родной батареи по ёмкости и пользователи не сдавали её в магазин через пару дней :)
Всегда интересно: почему такой гигант как самсунг не использует новый тип ячеек? Варианты ответов:
— их не существует
— они не стабильны и ответственная компания не хочет их включать в свои продукты
— они имеют очень малое время жизни
ну и т.п.
Дело в том, что я уже давно слежу за всем, что связано с литиевыми батареями. И в теории и на практике (занимаюсь моделизмом и использую разные батареи). Пока что все «новые» технологии, на поверку оказываются обычными LiPo, с теми же характеристиками что и раньше.
А по вашему выходит, что допустим родной аккум имеет толщину 4мм, добавив 10%, вы увеличили ёмкость более чем на 100%. То есть почти в два раза повысили плотность энергии. Это мировой рекорд и прорыв в технологии аккумуляторов какой-то. Никому не известный правда… :)
Если дадите аккум на тест, готов провести проверку с помощью хоббийного зарядного устройства: полный разряд, полный заряд, чтобы проверить фактическую ёмкость батареи.
Когда файлы в облаке, они висят как раз больших, мощных серверах, с широкими каналами. И доступ к этим файлам после авторизации есть из любого места с интернетом. А в данном случае, все данные висят в частных хранилищах. Вполне вероятна ситуация, как с торрентами: когда часть файлов недоступна, либо скорость очень низкая, потому что плохой/загруженный канал там где твои файлы (включая твой дом).
Ну и верно пишут: чтобы работал бекап, диск должен быть минимум на 2ТБ, а скорее всего на 3-4, чтобы побольше копий можно было разместить.
Повторюсь: для данной задачи, синхронизация с блокировками будет тривиальной в реализации, полностью надёжной/корректной, и почти никак не скажется на производительности реального приложения.
Я считаю, что не нужно усложнять. Это из серии микрооптимизаций, вместо X /2 писать X >> 1 :)
При этом, сами по себе синхронные примитивы вроде ConcurrentDictionary мне очень нравятся, они особенно хороши, когда много потоков пишет одновременно. Тогда есть очень большой выигрыш. Если же, пишет 1-2 потока, то обычный Dictionary + ReaderWriterLockSlim работает никак не хуже, а логика работы опять же оказывается проще.
Lock-free это всё круто, но надо ещё учитывать реальную частоту, с которой будут идти обращения к пулу. Вот в вашем, примере идёт работа с сокетами. Любое обращение к сети в 1000 и более раз медленнее, чем время переключения потоков/синхронизации. Так что, если написать такой же пул с обычным List и помечать какой свободен, а какой занят, то реальная производительность приложения вряд ли будет отличаться хотя бы на 1%.
Хотя при этом, конечно, синтетический тест lock-free пул будет быстрее.