На сервер у тебя должен крутиться вебсокет сервис, который и будет как то мониторить изменения и рассылать нотисы клиентам.
Если вебсокет сервер так же будет принимать и обрабатывать запросы на модификацию данных, то ему не потребуется опрашивать базу данных в принципе, ведь сервер в момент изменений может разослать сразу сообщения клиентам, если делать все асинхронно, то будет быстро и просто.
По факту код менять сильно не придется, просто метод, который ты ранее вызывал на получение POST запроса, пусть теперь вызывается на прием сообщения по websocket, ну и клиент чуть чуть переделать вместо отсылки ajax, так же сообщение по вебсокету.
до появления websocket их эмулировали с помощью технологии long pooling (гуглить либы есть), когда запрос к серверу на обновление данных им придерживается максимально долго, а чтобы соединение не обрывалось, периодически отправляет по символу, т.е. клиент как бы качает бесконечный файл очень медленно (как только появляется обновление, загрузка завершается), чаще всего это подключаемый javascript с вызовом функции dataUpdated(данные json); Сейчас можно обойтись и асинхронным аяксом.
но использовать эту технологию сейчас - это извращение
Developer, да конечно, wfp пришел на замену (или скорее сбоку, winforms скорее заброшенн ради wfp, windows mobile и прочего, в общем политика компании,..) и тоже сейчас позволяет мышкой повозить и приложение написать... почти.
имха
Скажем так, я лично wfp не люблю и поэтому не умею (я вообще не разрабатываю на .net) где то последние несколько лет, каждый раз, когда я для самообразования пробую покликать в студии и создать что-либо сложнее helloworld для wfp то там постоянно что то не работает, какие то ошибки, что то недозагрузило, не до установило и прочее. Вот сейчас одна из двух попыток создать простейшее приложение работающее с msaccess базой выдало на пустом месте ошибку не найден oledbdataadapter (знаю, ссылки на .net либы есть entityframework в nuget есть, вот один раз проект создал тупо по докам на которые сама студия ссылается - не работает, второй раз - работает).
Так вот биндинги в wfp отвратительны, что то там сломали разработчики, вместо создания приложение идет какая то борьба с какими то наслоениями абстракций и кода, ни о какой мышевозекательной разработке речи не идет. Простейший пример - две таблицы 1 ко многим, два листбокса, один поле из первой таблицы, второй - поле из второй, с фильтрацией по выбранной записи в первой, хотя бы просмотр, забыли про редактирование и датагрид... в биндингах есть все необходимое, связь в dataset оно видит, но в настройках подключения листбокс выбрать не дает, показывает муть
Ограничение по размеру есть только у GET запроса и только на длину параметров запроса но не на ответ.
Если строка будет обрезана на канальном уровне, то формат json будет не валидным (не будет как минимум закрывающей скобки массива) и js выдаст ошибку.
Ошибка либо при чтении данных запроса на клиенте в js либо при формировании данных на сервере однозначно.
ставь соседнюю машину и повторяй что делал на первой, по шагам, можно периодически на ней же проверять скорость чтобы отловить момент.
это 100% не относится к сертификатам, логично предположить что то что ты делаешь (лишнее/не правильное) при установке сертификата ломает что то в системе.
сам сертификат точно не может затронуть систему так что упадет скорость, потому вопрос что именно делал что так поломало сервер
Для чистоты эксперимента подними еще один сервер, закинь туда сертификат (пусть тестовый или бесплатный возьми, хоть letsencrypt), если проблема не повторится, значит ищи что еще делал.
во время работы спидтест процессор на сервере нагружается?
это значит в установочном пакете который через пакетный менеджер flatpak отсутствует необходимый файл
если программу скачивать с офф сайта, нужный линк и бинарник присутствуют (я в ответе ранее его и написал)
ума не приложу почему такое странное поведение, я считаю это неприличным, не следовать тем принципам которые устоялись в дистрибутивах linux, скорее всего мейнтейнеры flatpak так сделали (но наверняка это не ошибка а особенность механизма установки приложений этим способом, у snap тоже не все радужно).
raid покрывает достаточно большой и значимый пласт причин потери данных, связанных с технологией хранения hdd и позволит продолжать работать в единичных случаях выхода из строя диска
ключевое слово 'значимый', поэтому если вы беспокоитесь о данных, рейд обязателен
и да, это совершенно не отменяет бакапы
p.s. выбор технологий того как и где хранить, как именно использовать и как бакапить определяют - можно ли беспокоиться или нет
к примеру ежедневный бакап не даст вам спать спокойно, если важные к сохранению данные должны быть сохранены безальтернативно сохранены и потери даже суток работы могут встать в копеечку, в этом случае механизмы резервного копирования становятся совсем непохожими на классические (будешь делать бакап на каждую запись в базу?).
АртемЪ, это и есть надежность, термин для обывателя, а наработка на отказ это термин профессиональный
не будем же тут обсуждать что те или иные диски смогут выдержать падение с какой высоты, при какой рабочей температуре и прочее?
ну и помним, что гарантийный срок почти никак не коррелирует с этим параметром, а именно он важен когда речь идет о поломках диска, кто будет за нее платить.
Т.е. обывателю при выборе лучше взять диск не с большей наработкой на отказ а с большим сроком гарантии, и конечно всегда пользоваться raid 1/5/6 если беспокоится о данных (я бы еще по разным компьютерам/помещениям разнес но это отдельный разговор)
если есть авторизация, то храни счетчик запросов в сессии (список дат последних N запросов) и при превышении лимитов выдавай отлуп