поясни как именно работают 50 человек с файлами, причем как сейчас работают и саму изначальную задачу, чтобы не пытаться решать проблему, появившуюся из неверной попытки это решить.
если мелких файлов много
вот тут кроется 99% проблем, из-за удаленности сервера от пользователей никакой протокол тебе не поможет, все упирается в физику скорости света и высокие пинги. Сервер буквально должен стоять максимально близко к пользователям, тогда и nfs/smb протоколы будут отлично работать.
я тут уже советовал решение, которое может помочь, если каждый пользователь работает монопольно на запись только со своим каталогом и может быть сверху общий readonly архив (можно это расширить через какой-то интерфейс отключения диска после работы чтобы к нему подключиться мог другой человек). Через использование протоколов раздачи блочных устройств по сети (nbd, iscsi), так как в этом случае кеширование критичных мест в файловой системе значительно повышает скорость работы именно с мелкими файлами, вплоть до максимума пропускной способности (зависит от процессора сервера)
Настоятельно рекомендую не мучиться с googl drive и аналогами, а поднять свой next cloud или даже самодельный аналог (зачем неудобный браузерный интерфейс если можно webdav сделать) на более дешевых vps-ках или даже облачных (осторожнее там может быть дорого)
я зайду на поисковик lowendstock, и выберу, с ценами от 8$ в год за 50гб, vps-ку, настрою сеть ipv6 (либо vpn через ipv4 по желанию и ограничениям скорости этих микрохостеров) и настрою по вышеописанной в ответе nbd
Сайты, предлагающие поиграть в кости либо дают не 0.5 вероятности выиграть (забирают комиссию тем или иным способом, делая матожидание выигрыша меньше) либо каждый следующий бросок кубика вычисляют в зависимости от твоей ставки и накопленного выигрыша таким образом, чтобы выиграло казино.
Если же участники играют по честному то основная стратегия - маргентейл, манипуляции ставками (удвоение при проигрыше), в этом случае сливает игрок с меньшими суммами в кармане.
нет там все очевидно, на каждое собщение об обновлении в канале код библиотеки запрашивает это новое сообщение достаточно тяжелой командой MessageRange указывая начальное и конечное сообщение одно и то же, при превышении лимита запросов сервер просто не обрабатывает его
i7-3770k - 2071 single thread (6448 overal)
i5-12400f - 3550 single thread (19735 overal)
В принципе ускорение значительное, почти в 2 раза в худшем (на node редко пишут мультитредовые приложения а значит надо смотреть single thread) и еще порядка 10-30% можно выжать в среднем за счет скоростной ram, но за это придется платить.
ну в принципе смотри из моего ответа табличку видеокарт с ценами, выбирай сверху вниз, пока не наткнешься на доступную цену (цены из сибирского региона, dns, возможно у тебя будут другие)
эм! это команда консоли curl, вводить в консоль вашей ОС или вашего сервера
настоятельно рекомендую linux, там curl стандартно распространяется через репозитарии, для windows придется качать и устанавливать
curl это инструмент 'тестирования', на практике обычно разработчики выполняют запрос в своем приложении (кстати есть одноименная библиотека libcurl и биндинги по до все языки)
p.s. ты спалила свой client_secret, после экспериментов рекомендую сменить
По поводу Restart=always я читал что после определенного количества перезапусков, служба все же останавливается, и это правильно, где то в дебрях systemd есть этот параметр.
Правильное решение, оберни запуск своего бота в отдельное приложение/скрипт (десяток строк) которое будет в бесконечном цикле перезапускать упавшее приложение, да еще и отправлять сообщения владельцу о слишком частых падениях
просто мельком полистал что такое trustwave я так понимаю он у тебя установлен, вполне возможно что отредактировав код, он у тебя стал похож на эту уязвимость, тебе даже написали в какой строке какого конфига это правило описано.
Гугл вообще мало по этой теме говорит, значит продукт либо не слишком популярный либо наоборот, он на столько самодостаточен что нечего обсуждать и все видно и так.
Я верно понимаю у тебя ошибка которую ты показал теперь на любую попытку открыть страницу выскакивает?
вот тут кроется 99% проблем, из-за удаленности сервера от пользователей никакой протокол тебе не поможет, все упирается в физику скорости света и высокие пинги. Сервер буквально должен стоять максимально близко к пользователям, тогда и nfs/smb протоколы будут отлично работать.
я тут уже советовал решение, которое может помочь, если каждый пользователь работает монопольно на запись только со своим каталогом и может быть сверху общий readonly архив (можно это расширить через какой-то интерфейс отключения диска после работы чтобы к нему подключиться мог другой человек). Через использование протоколов раздачи блочных устройств по сети (nbd, iscsi), так как в этом случае кеширование критичных мест в файловой системе значительно повышает скорость работы именно с мелкими файлами, вплоть до максимума пропускной способности (зависит от процессора сервера)