Производительность сервера в сумме вырастит пропорционально размерам любого кеша (формула и коэффициенты будет сложна, это к теоретикам)
Чем больше кеш (он более быстрый чем основной хранитель инфы), тем быстрее работа с данными в сумме всей системы.
Чисто теоретически, если обрабатываемые данные будут меньше чем кеш, т.е. они "влезут" в кеш, то увеличение скорости работы с ними будет равна отношению скорости L3-кеша к скорости ram.
Работа кеша эффективнее всего понимается на связке медленного hdd-носителя и файлового кеша в ram. Куча статей имеется. L3кеш и ram практически тоже самое.
фтп не дает доступа к частям файла, имхо каждая операция чтения/записи перекачает весь файл (хз как там работает локальный кеш). что сильно тормознет работу с йдаленным файлом бд или вообще покорежит его.
используй nfs/samba или иной протокол сетевых файловых систем. в них есть функциональность доступа к части файла. в них есть работа с частями файла, что используется в базах данных.
имхо лучший вариант поставить на удаленке СУБД и подключаться к ней сетевыми подключениями. будет правильно и эффективно. таких навалом.
Дмитрий, он его оставил с стороннего ппа - там может быть что угодно...
глянул таки листинг пакетов для бобра в данном репозитории - он пустой, https://ppa.launchpadcontent.net/ondrej/php/ubuntu...
т.е. компиляция пыха под бобра(18.04) в ентом ппа не поддерживается.
обычно зависит от схемы БП. силовые части схемы достаточно кондовые и обычно рассеивают импульсы. иначе б БП у тебя б сдох еще при первой коммутации.
последовательно с диодом надо ставить сопротивление в пару десятков ом, да бы не спалить диод бешенным током.
плюс диод должен быть импульсным.
вот под боком валяется FR304 с какого компутерного БП. на 24 вольта хватит и 301.
плюс желательно еще повесить керамику хорошей емкости для снижения "отвесности" выброса.
и т.д.
смотри рекомендации к реле, там обычно (для мощных) есть предложения по защите от самоиндукции.
sagisuu, учитывая качество современных кодопейсателей, даже низкоуровневых драйверов - не исключу.
бекапь хомяк и будет тебе щастьё (с) древняя мудрая асболютно универсальная мысль.... :)
бекап настроек хоть хрома хоть лиса хоть ребра хоть кого в надежное место даст возможность их восстановить.
Elvis, не знаю.
берешь свою систему и четко разбираешься в том отчего и почему в ней происходит - с вероятностью 99% получаешь точный ответ и познания как чего изменить.
в qna ты получишь ответ если ктото уже сталкивался ровно с такой же проблемой и решил ее.
но с "вероятностью 50 на 50" твой случай уникальный или описан так что никто не понимает как тебе ответить :)
кстати посоветую еще вариант с платной тех.поддержкой или платной компутерной консультацией - там спецы, оплата и ~гарантия результата.
Синхфинг одноранговая сеть :) у него нет деления на сервер/клиент - каждый пир работает полноценно
Можно создать локальную сеть без подключения к интернету и синхфинги в ней найдут друг друга по локальному обнаружению.
имхо тема ушла в сторону.
вопрос поставлен не корректно.
проблема будет в том, что нет ни одного способа передать пользователю устройства какую-либо информацию, зная лишь его ip и mac.
посему сбор ip и mac бессмыслен.
Икотий Айтишевич, mac и ip элементарно сливаются с DHCP сервера локалки. без всяких приложений :)
да и просто пропинговать небольшую сеть можно очень и очень быстро.
НО !! весь вопрос? что даже зная ip и mac адрес устройства, как либо послать ему сообщение нельзя :) это была б дырка в безопасности побольше, чем секретарша директора.
заодно сравнить из под кого запускается php/php-fpm на боевом и тестовом
и т.д.