rPman

Сообщения об ошибках должны быть видны разработчику в dev консоли, потому что ошибки должны быть обработаны не только с точки зрения кода но и владельца сервиса в целом!

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

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

file_put_contents(... FILE_APPEND) дописывает содержимое в конец без пересоздания и перечитывания файла
это просто упрощенная запись конструкции
fopen(...,'a');fwrite(...);fclose(...);
если FILE_APPEND не указывать, то используется режим типа w+ (существующие файлы обрезаются в 0 размер, не существующие ошибки не вызывают)
p.s. важное замечание file_put_contents FILE_APPEND работает очень медленно, синхронизируя каждую запись с диском, я помню переписывал код на использование fopen/fwrite плюс там можно гибко задавать буфер записи

upd. на самом деле там используется просто режим 'a' и 'c' и чуть больше проверок
С интересом обнаружил по исходникам что file_put_contents умеет писать array, объединяя без разделителя значения и пропуская ключи.... век живи век учись, не знаю зачем но смешно

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

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

p.s. проблемный провод не мог повредить данные на диске! но могли быть ошибки во время копирования (случайно прекращается).

Практически все современные linux для загрузки используют grub, т.е. вне зависимости от выбранной ОС способ настройки и потенциальные проблемы - одни и те же.

Настоятельно рекомендую grub (и EFI раздел linux если используется secureboot) не совмещать с загрузчиком windows и в идеале выделить любой носитель (хоть флешку или карту памяти, потребуется от силы несколько десятков мегабайт а для mbr legacy - всего 1) и для выбора с чего загружаться выбирать загрузочный раздел в BIOS. Саму же систему можно ставить куда угодно, я помню были даже решения, когда linux размещался в файле-контейнере на window диске (да это медленнее).

Дело в том что конечно linux умеет предлагать выбор, что загружать, linux или windows. но майкрософту это не нравится ис периодичесттью раз в 1-2 года, с очередным обновлением приезжает какая то хрень и что то перестает работать, можно получить проблемы на пустом месте (например grub подменялся на майкрософтовский загрузчик и приходилось его восстанавливать), или вот - например у меня в прошлом году win10 отказывалась обновляться, ошибка маловразумительная причины гуглились в linux загрузчике но решения не подходили, я тогда помаялся и впервые решил проблему в win10 переустановкой, как это было когда то с winxp (скорее всего решение было но там был вопрос времени)

wss - это websocket по https, тебе точно нужно вручную заниматься всем что касается шифрованием на php?
настоятельно рекомендую для работы с websocket использовать уже готовые библиотеки например textalk websocket или ratchet pawl, вот почитай минитуториал на русском

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

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

Меняй данные сразу при загрузке страницы

Вот этот список/таблица в которой номеру соответствует строка-описание называется справочник
У тебя 2 основных подхода, хранить эту таблицу в базе данных (особенно если приложение должно уметь его редактировать) либо хранить его на клиенте и подставлять в программе

Про хранение на клиенте тебе уже подсказали

Про хранение в базе данных - либо ты создаешь буквально таблицу-справочник, либо про создании таблицы (твоя profile) определить не числовое поле а enum со строковыми описаниями (подходит для очень небольшого количества записей)

При использовании таблицы-справочника sql запрос будет примерно таким

select ... from profile p left join admin_cls a on p.admin=a.id

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

в триггеры добавь условие - включение компьютера

Ответ на этот вопрос можно получить либо экспериментально либо изучив серверную реализацию (в конечном счете тоже экспериментально).

У тебя 2 основных узких 'горла' - скорость подготовки ответа сервером (процессор и диск) и скорость сетевого соединения до него... ну а медленный клиент можно распараллелить несколькими машинами (и соответственно провайдерами если проблема в сети на стороне клиента).

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

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

Ну и вишенка на торте, транспортный уровень может внести корректировки, полистай статью

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

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

Ну и нагрузка на процессор, если реализация однопоточная (асинхронная реализация сильно усложнит подсчет) то скорость ответа будет линейно зависеть от времени обработки одного и нагрузки на процессор (проще замерить сколько клиентов дадут 100% нагрузку). Но вот многопоточные реализации могут давать неожиданные ухудшения характеристики, т.е. 10 потоков могут не дать 10-кратное увеличение скорости, и с величением потоков будет много ресурсов уходить на поддержание этой работы (кажется теория вообще говорит о квадратном корне из количества потоков), и это еще про кеш процессора речи не идет, так как в зависимости от того, влезает ли алгоритм обработки (нужная ему память) в него или нет тоже можно получить кучу странностей, например 1-2 потока будут давать быструю скорость, но добавив третий, даже не нагрузив весь процессор, можно получить значительное понижение производительности, так как данные трех потоков не влезают в кеш. Кстати оперативная память хоть и называется Random Access memory но может давать разную производительность в зависимости от характера нагрузки (особенно это видно по вычислениям на GPU) что тоже не лучшим образом влияет на многопоточный результат.

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

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

дальше, существуют имена, которые windows обработать не может, это зарезервированные слова типа com lpt prn и т.п. их создать не просто но реально, и штатные утилиты работать с ними не смогут

p.s. rmdir /s/q имя_каталога
у меня удаляло обычно все максимально быстро (/s/q это без запросов и с подкаталогами)

На сколько мне известно, в майкрософт убрали принудительную перезагрузку, как минимум это отключается, а уведомление о перезагурзке теперь не модальное окно на весь экран.

могу предположить что используются домашние ревизии windows, там обновления скорее всего менее гибко настраиваемые, попробуйте сменить систему на pro или ultimate ревизии

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

Первое что нагуглил это для VB# но разницы нет никакой

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

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

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

Кстати в биос майнеры могут зашить нестандартные параметры, сравнивать это с официальными данными по модели
upd. погуглила бы хоть
если продавец - магазин, то ты можешь вернуть карту в этот же день если заметишь что она БУ (по уму у тебя 10 дней на это есть но меньше будет проблем если в тот же день вернешь)

шлешь в бесконечном цикле паузу и запрос
SHOW FULL PROCESSLIST;
сохраняешь список идентификаторов для проверки а следующем шаге, проверка - если какой то id остался с прошлой проверки - считать этот запрос медленным, интервал (длина пауза) между запросами - пороговый интервал для определения что такое 'медленный'

upd. можешь добавить к идентификатору содержимое info, как то поможет, чтобы хоть немного обойти замечание акина

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

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

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

Не понимаю, зачем тебе посредник между nicehash и тобой в виде awesome miner, абсолютно все необходимое есть у самого nicehash

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

и сказано что в человеко-читаемом формате это (08.11.1965)

кто тебе это сказал? в смысле что за приложение?
unix time определен как количество секунд с 01.01.1970 года, и про отрицательное их количество речи не идет

для определения времени до этого события нужно использовать другие стандарты