rPman

причем тут cygwin?

cygwin это фактически полноценный linux, скомпилированный под windows (т.е. приложения windows но собранные из исходников linux, которые и не думали поддерживаться разработчиками)

Поэтому вопрос наверное должен быть как в linux так сделать?
Например в bash можно так:

mkdir -p Projects/Project_1/{directory_1,directory_2,directory_3}
mkdir -p Projects/Project_1/directory_1/{sub_dir_1,sub_dir_2}
mkdir -p Projects/Project_1/directory_3/sub_dir3

Под php подразумевается сервер бакэнд, а то можно на другом языке написать, например на javascript node.

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

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

Вообще то это должен быть it архитектор, который должен определить все необходимое, и даже составлять прогнозы развития систему на будущее, особенно если инет подробного ТЗ.

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

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

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

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

еще можно поковырять логи

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

Без индексов скорее всего никуда, если в запросе идет фильтрация по полю, то если не создать на него индекс, этот запрос и будет создавать нагрузку

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

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

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

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

p.s. диск на сервере hdd или ssd? если не хватает денег на большой ssd, настрой маленький ssd как кеш к медленному hdd (linux bcache), даже когда данные полностью не влезают в кеш, это дает заметный прирост, потому что hdd начинает менее случайно двигаться, плюс добавляется буферизация записи (данные записываются на ssd и лежат там пока hdd не освободится), так же дает эффект ускорения записи вынос журнала файловой системы (если ext4) на ssd (требуется пара гигабайт от силы).

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

Но мне больше нравится резервирование на лету (настроить онлайн репликацию, пусть и на слабый, бакап сервер)

тот на котором были любые транзакции

очень сложное условие, для этого нужно сканировать блокчейн

Можно это делать самому (bitcoin core так делать не умеет, можно сделать индекс на транзакции или контролировать указанный список, при добавлении адресов потребуется пересканировать блокчейн, иногда мне кажется это такое тонкое издевательство разработчиков) либо взять готовый клиент, например btcd там есть опция создания индекса --addrindex и будет соответствующий rpc запрос

p.s. если бы было требование положительного баланса, для bitcoin core есть утилита дампа списка UTXO (не потраченные выходы) но это разовая операция, занимает некоторое время и готовит (на текущий момент) 5-гб csv файл.

Удостоверься что проблема именно в биосе а не неправильно созданная флешка, идет ли загрузка с нее если физически выключить диски?

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

2009 возможно usb3 еще не было, синие, но если есть - не вставляй в них загрузочную флешку.

Можно попытаться создать флешку не с помощью windows download tool а с помощью посекторного копирования образа iso - windd, это имеет смысл если в биосе есть пункт меню загрузки с usb cdrom, так же можно по перебирать разные типы загрузки usb hdd, usb fdd (да да я такие видел) и т.п.

Не использовать флешки больше 8 гигабайт, это странно но старые компьютеры часто не хотят с 16 и выше флешек грузить windows (при этом грузят linux).

Можно не лезть в сам биос а использовать меню загрузки, обычно оно по кнопке F8/F11/F12 вызывается, смотри стартовое окно загрузки компьютера (можно отключить логотип в биосе), иногда оно дает больше информации и контроля

* проверь наличие в биосе пункта efi (uefi) загрузчика, и включи его, в 99% случаев это может помочь (для работы этого режима обычно достаточно чтобы флешка в принципе определялась и ее формат был fat/fat32, а бут сектор нет)

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

Еще экзотический способ - загрузиться с livecd ubuntu (я ни разу не видел чтобы нельзя было загрузить linux, можно поперебирать разные usb загрузчики, например unetbootin), установить virtualbox или qemu/kvm и используя системный диск целиком как диск виртуальной машины, запустить начало установки из виртуалки (самый первый процесс копирования файлов до первой перезагрузки), но продолжить установку после этой перезагурзки уже с реальной машины, перезагрузив ubuntu и вынув флешку.

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