rPman

Аналог linux-овму fusefs, но для windows - winfsp.dev
Но он на c++!

чтобы завести это на питоне, нужно писать прослойку, немного устаревшая статья но идея та же (в статье описаны обоа направления python -> c++ и c++ -> python)

если шансы выбора файла одинаковые и ты можешь переименовывать файлы, сделай имена файлов - числами
тогда код станет совсем простым

num=random.randint(1,10) # от 1 до 10 включительно
filename=str(num)+'.png' # просто пример имени файла 1.png

await asyncio.sleep(1.0 / MESSAGE_REPLY_RATE)
нужно добавлять в тело цикла, после tasks.append(task), добавив await

тебе ведь нужно не создавать новые task чаще чем указанная частота, вот и создавай их с интервалом.

На windows в устройствах должно присутствовать что то типа StereoMix (панель управления - звуки - запись). В этом случае его можно выбрать вручную как устройство по умолчанию, либо средствами pyaudio выбирать как источник звука.

Иначе средства еще есть (OBS как то звуки записывает) но сомневаюсь что этот функционал доступен из python.

забрось ты эти попытки симуляции поведения браузера
потратишь времени вагон, а потом разработчики сайта что то подправят и тебе снова анализировать код

запускай полноценный браузер, симулируй клики пользователя, способов миллион, от инжекта javascript на страницу нормально запущенного браузера и прередачи информации через http до полноценных библиотек типа selenium

Не уверен что данный код можно как то ускорить
Например можно сменить python на nuitka и компилировать бинарник из получаемого им c++ кода, вот такие простые вещи там однозначно могут быть быстрее, особенно если вручную ковырять
Как частный случая - написать критичный кусок кода на c++/c и вызывать его из питона, но сразу скажу что если по тупому заменить этот кусок на код си, никакого ускорения не получится, может даже ухудшение.

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

Поясни главную задачу, зачем у тебя исходный массив в виде двумерного числового, когда к примеру подошел какой-нибудь битмап (не уверен что это было бы быстрее но попробовать)? Почему надо генерировать итоговый массив таким? куда пойдут эти 3 числа, это описания RGB colors? а потом они все будут инициализироваться?

Если данные обрабатываются отдельно, то самая быстрая реализация - записывать в файл в своем формате (даже если это будет построчно сериализованные json), обязательный flush после записи (кеш кстати можно отключить). Индекс строить в оперативной памяти в виде словаря (key->смещение в файле+размер или сами данные, если влезают). При перезапуске приложения после сбоя, файл перечитывается, индекс в памяти заполняется заново. Этот вариант подходит для случаев, когда параллельная аналитика уменьшает объем данных в этом файле, перенося их в базу данных (в этом случае нужно параллельно обновлять индекс в памяти основного приложения и при его перезапуске учитывать что именно читать из файла а что нет), один из способов реализации уменьшения размера файлов - хранить его кусками от времени, удаляя старые (при этом нужные данные повторно отправлять в систему, в общем дальше от задачи).

Решение с таким лог-файлом (или несколькими, например по одному на процесс/поток/ноду, тогда не понадобится синхронизация записи) и индексом в оперативной памяти будет давать считанные миллисекунды на операцию (упираться все будет в iops диска), если совсем труба, исключай файловую систему и пиши прямо в блочное устройство (выгадаешь еще 3х-10х ускорения)

Если хочется базу данных - бери что то типа mysql с отключенными транзакциями (myisam), и очень грамотно составленными индексами и партицированием (может даже самодельным). Большее количество задержек вносят именно индексы.

Почти наверняка решение у тебя в итоге будет смешанное. Данные принимает приложение в оперативную память, записывая в лог-файл, а запросы на чтение (поиск по ключу) дублируются в базу данных (в памяти держать только последние данные, грубо говоря то что не успел перенести в базу данных сервис аналитики)

p.s. когда то давно я писал что то подобное, диск был медленный hdd но так как с него не было чтений, только записи на случай сбоя, а все данные были в оперативной памяти, скорость была огромной, десяток тысяч операций на очень слабом тогда железе

Что не получается то?
у тебя 2 пути, реверсить логику сайта либо работать с итоговым результатом прямо в браузере, симулируя клики и движения мыши.

Второй способ проще но кушает ресурсы (для параллельных запросов несколько браузеров запускать), инструментов тьма, от штатного браузера и его отладочной консоли (тупо туда код пишешь) до готовых проектов по управлению браузера типа selenium

500кб очень маленький объем, загружаешь и парсишь локально в своем скрипте весь файл, затем полученный массив в цикле собираешь во временный, сохраняя его в файл при достижении какого то лимита, например по количеству объектов (можно точнее по размеру json но это медленнее)

Это нормально.
И да, много это не 2-3 уровня а сотни и тысячи.

Да, у программистов обычно зуд на такие вещи, видишь повторяющийся код или логические конструкции и пытаешься их заменить на какое то их описание и код который по этому описанию делает всю логику.

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

Все способы хороши, да и тупой while sleep и более умный готовый event loop с асинхронными библиотеками.

Часто все завязано на способе проверки, если хватит http запроса то да, приложение из 4 строчек сможет решить задачу

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

p.s. бывает информацию о новых постах можно получать по websocket (сам пост обычно тем же http reast забирают но сайты могут выдавать сообщение клиентам через сокеты), соответственно пилишь клиент вебсокет который вместо периодических опросов будет максимально оперативно принимать сообщение от сервера

работу двух не моих сервисов

собственно все проблемы тут.

не твои сервисы, значит если их разработчик не продумал каких то механизмов взаимодействия друг с другом, хотя бы в пределах одной машины или в полуручном режиме (например участие пользователя тут экспорт и импорт), то тебе нужны с обоих сторон промежуточные инструменты, которые будут
* проводить взаимодействие
* совершать доставку
* мониторить проблемы

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

Плюс к этому еще мониторинг/уведомление о проблемах, если операция периодическая и совершается в автоматическом режиме, нужно сообщать о не завершенности ответственному лицу максимально оперативно и подробно... фраза - 'произошла ошибка 134' - неправильное сообщение, верное - 'обновление данных о сотрудниках не завершено по причине обнаружении дублирующих значений фио и день рождение Василий Иванович Пересменкин 13.02.00 для разных сотрудников', и в идеале по каждой ошибке предлагать какое то решение.

Защищать данные локально можно только средствами ОС (например права доступа, запускать приложение от прав соответствующего пользователя), это достаточно успешно реализовано на android/macos, для получения доступа к данным там понадобится рут/взлом загрузчика, что сразу уменьшает список таких пользователей на пару порядков

Полностью защитить локальные данные от получения к ним доступа невозможно, можно только усложнить - увеличить стоимость взлома (например обфускация алгоритмов и ключей шифрования критичных данных) и делать это лучше не на python (инструменты обфускации заточены обычно на c/c++)

Совершенно непонятно, как именно отрабатывает асинхронный сервер asyncio с вашим thread pool, я так понимаю это скрывается в дебрях класса объекта test_pb2_grpc? Нужно больше информации.

если к правильно настроенному 10-поточному серверу попытаться одновременно сделать больше 10 подключений, то все лишние будут откладываться в очередь (длина которой отдельный разговор, но при ее превышении сервер должен возвращать ошибки) и копиться там, т.е. с какой бы скоростью запросы к серверу не шли бы, отрабатывать они должны именно так - 10 запросов, каждый по 1 секунде, т.е. 10 запросов в секунду.

Для начала смотри логи и временные метки ответов клиента и запуска sleep на сервере (добавь строчку вывода в лог - sleep запущен/завершен с отладочным идентификатором запроса клиента, который добавь в http запрос), тогда ты будешь видеть время жизни каждого подключения клиента, сколько он висел в очереди asyncio и когда завершился на сервере, возможно тут что то прояснится.

Тут будет что то типа такого - первые 10 запросов (в течении первых 0.2 секунды) запустятся на обработку и завершатся каждый ровно через 1 сек, все последующие тупо будут складываться в очередь, по завершению очередного запроса, т.е. каждый следующий исполненный запрос будет завершаться через 0.02..0.2 секунды,группами, (при условии что запросы равномерны по времени), в порядке отправки этих запросов.

Вести отладку многопоточных приложений напрямую сложно (ведь пауза вносит изменения в структуру и порядок запросов), только тщательным логированием