jacksonmihailov: "небольшой файл" - это очень размытое понятие, и зависит и от вашего железа (размер буфера и размер блока) и от фс, и настроек операционки, и от нагрузки на систему. На некоторых ssd размер буфера достигает гигабайта, и там этот файл будет просто мелкой букашкой. Но бывают и диски с буфером 8мб, например.
Если нагрузка на эту штуку большая - нужно тестировать разные варианты, и смотреть не только на то как быстро переписывается файл, но и не мешает ли это остальной работе сервера. Если это редактирование происходит относительно редко и проблем не возникает - оставьте как есть.
Сейчас получается какой-то странный диалог, типа
- мне нужно завалить [какое-то животное], но не скажу точно какое.
- используйте копье, или огнемет, или противотанковую мину, или мухобойку - смотря какое именно животное вам нужно завалить
Ришат Султанов: Не совсем понимаю что вы подразумеваете под мониторингом. Вести историю и рисовать графики? Следить за превышением каких-то параметров и высылать уведомления? Сейчас на ваш вопрос можно дать десятки или сотни разных ответов. Опиште где вы собираетесь это применять и где запускать. И смотрели ли вы существующие решения перед тем как решится писать "мониторинг" самостоятельно.
Маша Кравцова: быстрее будет разбросать их в один поток, чем писать многопоточный. Ну и вам наверное нужно их не как попало разбросать, а так, чтобы потом можно было найти нужный файл.
Один из стандартных подходов в таком случае - генерировать папки по нескольким первым символам от хэша имени файла.
Допустим файл helloWorld001.jpg
md5('helloWorld001.jpg') = 028707f54e8387ab32ef5cb373555247
Создаются папки /02/87 и перемещается файл. В результате:
/02/87/helloWorld001.jpg
Если вам не нужно равномерное распределение, то можно и не брать хеш, а сохранять как /he/ll/helloWorld001.jpg
Дарья Субботина: здорово. Чтобы убедиться что работает правильно можете проверить те-же ссылки из браузера, например, или wget'ом, или curl'ом. В общем чем-нибудь, где можно посмотреть код ответа.
4). Парное программирование. Кто-нибудь вообще видел
Я участвовал, нас было трое таких "экстремальных" и мы периодически садились по двое за один комп и разруливали какие-то сложные задачи. Не все время, конечно, но пару раз в неделю по 2-3 часа в день бывало. И это очень заметно ускоряло некоторые процессы, особенно в таких местах, где нужно было вносить изменения затрагивающие очень большие куски проекта.
Типа "вот этот кусок ORM очень медленный и жрет память, я думаю надо его выбросить, вон ту таблицу разделить, а вот здесь сделать денормализацию, а вон тот кусок вообще выбросить, но это заденет кроссдоменный логин который ты сейчас пилишь, так что давай вместе".
Тут стоит отметить, что сам проект был тем еще цирком - мы за несколько месяцев сильно переписали код, который до того разрабатывался года полтора, при этом к каждой пятнице нужен был "показательный" билд, который мало того чтоб просто работал, но еще и какие-то новые фичи имел. На других проектах не пригождалось потому что архитектура была стабильной и заранее продуманной или не так просто было найти напарника с которым процесс ускорялся бы а не замедлялся.
