Че-т Вы намудрили.
Вы вообще-то - раздавали статические файлы с "сервера-получателя" - или просто использовали его как удаленное файловое хранилище, которое Вы по NFS примонтировали?
$ftpfilesize = ftp_size($open, $file); // проверяем размер файла на фтп $locfilesize = filesize($file); // проверяем размер локального файла if ($ftpfilesize != $locfilesize) {echo 'Размеры разные, нужно перезакачать';}
Апофигей PHP кодинга. Функции ошибок не возвращают.
Что, интересно, будет - ежели теперь Вы сервер для статики отключите? Нешто FTP продолжит работу? 🍿
Вывод глупый. Что сложного в том, чтобы подмонтировать каталог - Вы не освоили синтаксис команды mount ? :) Кроме настройки экспорта определенных каталогов по NFS на втором сервере - Вам потребуется только это. Никакого безумного кода писать не надо - работайте с файлами "локально", как Вы делали это раньше.
Про "нестабильность" - уже писали. Не доверяйте местным "гуру", которые вместо того чтобы описать с какими проблемами столкнетесь конкретно Вы, в Вашей задаче, если будете решать ее используя то-то - начинают рассуждать "вообще и в общем" то-зло, се-зло...
Хороший повод либо приобрести таковые знания - либо поручить решение задачи человеку, обладающему ими.
Список, приведенный Вами - говорит об обратном. К примеру, способ с кешированием в nginx или использование rsуnc - не подойдет точно. Без скрипта, работающего на стороне сервера с файлами.
Боюсь, не могу поверить Вам на слово :) Для этого нужно в больших деталях понимать логику работы Вашего веб-приложения и видеть код.
Ну вот как, к примеру?
Ну, чуть затянулось...
Жаль. Если бы Вы включили мозг при "наблюдении" - было бы куда полезнее.
Да не в "разрывах" дело - а в том, что Вам придется написать достаточно сложный код, обрабатывая "отправление" файлов и работу с ними далее. Вам ведь надо редактировать файлы потом, верно?
Почти наверняка - реализация Вашей "идеи" содержит ошибки. Ну к примеру: как Вы контролируете целостность передаваемых файлов? Как обрабатываете эти самые "разрывы"? :)
Есть такие "кодеры", которым лишь бы нашкодитьнакодить... То, что задача совершенно стандартная и имеет кучу готовых вариантов удачных решений - их никак не волнует. По моим наблюдениям это сильно коррелирует с подростковым возрастом. Самые несчастные в результате - те, которым потом с этим "добром" приходится работать и сопровождать проект далее.
foxi, "дай угадаю" - Вам до 25, верно?
Вы хотели сказать - слишком мало? Т.к. формат настраивается - укажите только то, что нужно.
И не забываем про задачу. Она не в отладке медленных скриптов - а в их обнаружении и идентификации. Это на порядок более простая задача.
Можно, конечно. Только имхо: лучше отделить мух от котлет.
А что, у апача запись времени отработки запроса в лог - уже отменили?
На самом деле - strace замечательно подойдет, чтобы узнать "какой скрипт" и "чем занимается". Просто его вывод нужно уметь настраивать, а для этого прочитать man. Dram, разберитесь, к примеру - как заставить его выводить только вызовы open().
Затем, что кто-то головой думать не привык - и понаставил на сервер все что нужно и не нужно. Для справки - xcache не является "системой кеширования", аналогичной memcache. Это один из механизмов кеширования опкода.
Может начать с азов? Читайте документацию апача, узнайте про mod_status.
Помимо strace можно использовать что-то типа
ls -l /proc/PID/fd
И если "диска" и если "канала". "Плох" он будет, если сервера "не рядом" - т.е. планируется разнести их в независимые ДЦ, к примеру.
Увидим.
Может тут еще кто-то именно так "подумал", оттого и возражения возникли? Голову все-таки надо использовать изредка - ТС вполне ясно дал понять, что статику хочет раздавать со второго сервера. Нет, я понимаю если Вы весь тред не читали - но хоть первое-то сообщение?..
Вы хотите сказать - пользователи все поймут и стерпят? Не всегда: нужно постараться им объяснить принцип работы - например "твоя картинка появится через XYZ минут - не паникуй!". И не везде: иногда они просто плюнут на подобный сервис.
Может для разгрузки канала - может диска мало на основном сервере. Гадать, наверно, не стоит - а ТС на вопрос "зачем" пока не отвечал, хотя вроде задавали.
NFS разгрузит канал для основного сервера (где скрипты) очень просто. Трафик для статики - пойдет прямо на соответствующий сервер, минуя тот на котором скрипты. NFS же используется для взаимодействия между серверами - его доля будет мизер в нагрузке на каналы. Да и кроссовером можно сервера соединить, если уж на то пошло.
Вообще-то любопытно услышать подробное объяснение логики, в которой использование rsync "разгрузит канал", а NFS - нет. Или Вы подумали, что картинки предлагают раздавать по-прежнему с основного сервера, просто раздел по NFS подмонтировать? :) Нет, конечно. Картинки раздает сервер для статики. Просто основной сервер имеет к ним доступ через подмонтированный раздел.
Вы либо не потрудились ознакомиться с условиями задачи - либо за давностью о них забыли.
Если бы задача состояла в простом копировании файлов - ее куда лучше решил вариант с кешированием в nginx. Проблема в том, что ТС видимо хочет далее с этими файлами время от времени работать, т.е. редактировать их по запросу.
Пока Вы будете ждать "крона" - пользователи будут кричать "где моя картинка"? Им ведь на Ваши высокие материи с кронами - пофиг. Они будут вполне обосновано считать, что сервис просто сделали криворукие "асы". И будут правы, что характерно ;)
Где Вы видите здесь "дискуссию"? Ряд совершенно бездоказательных заявлений с одной стороны и повторяющиеся просьбы их обосновать с другой.
Логика уровня: "Гвозди - зло, их использовать не надо, т.к. я однажды гвоздем в носу ковырял и сделал больно". В то время как речь идет о совершенно других задачах, нежели "ковыряние в носу". Вот объяснит Андрейка почему "гвозди - зло" для задачи "доски прибивать" (т.е. непосредственно для задачи ТС) - можно будет говорить о дискуссии.
Да нет, он выглядел вполне вменяемым, Вы напрасно.
