У меня есть еще одна проблема с amazon и ее связано с загрузкой файлов. Я использую jqueryFileUpload и amazon API для загрузки файлов на amazon S3.I удалось загрузить его, но это связано с трюком.
Мне нужно было сохранить изображение на моем сервере, а затем перенести его на S3 с помощью метода putObjectFile для S3.Now плагин поставляется с большими функциями для обрезки / изменения размера изображений, и я использовал их с тех пор, как долго. Теперь, когда я интегрирую плагин с AWS, я столкнулся с проблемами производительности при загрузке. Время, затраченное на загрузку, больше, чем обычно, и это поднимает вопросы о нас, используя AWS S3 по сравнению с традиционным способом.
Я должен был внести изменения в файл UploadHandler.php, чтобы он работал. Эти изменения сделаны. Я добавил часть кода загрузки AWS в файл с строки 735 до 750
$bucket = "elasticbeanstalk-2-66938761981"; $s3 = new S3(awsAccessKey, awsSecretKey); $response = $s3->putObjectFile($file_path,$bucket,$file->name,S3::ACL_PUBLIC_READ); $thumbResponse = $s3->putObjectFile('files/thumbnail/'.$file->name,$bucket,'images/'.$file->name,S3::ACL_PUBLIC_READ); //echo $response; //echo $thumbResponse; if ($response==1) { //echo 'HERER enter!!'; } else { $file->error = "<strong>Something went wrong while uploading your file... sorry.</strong>"; } return $file;
Вот ссылка на класс s3 на git. Обычная загрузка на мой текущий сервер (не amazon), одно и то же изображение загружается через 15 секунд , но на amazon S3 требуется около 23 секунд, и я не могу найти лучшего решения. Мне нужно сохранить изображение на моем сервере раньше загрузка на S3, поскольку я не уверен, могу ли я обработать их на лету и загрузить непосредственно на S3.
Может ли кто-нибудь предложить правильный способ подойти к проблеме? Возможно ли изменить размеры изображений на разные размеры в памяти и загрузить непосредственно на S3, избегая накладных расходов, чтобы сохранить его на нашем сервере? Если да, то может ли кто-нибудь вести меня в правильном направлении?
Спасибо за внимание.
Я считаю, что примерные 8сек – это накладные расходы для создания версий изображений разных размеров. Вы можете использовать разные подходы, чтобы избавиться от накладных расходов на изменение при загрузке. Основная идея заключается в том, чтобы позволить сценарию загрузки завершить выполнение и вернуть ответ, а процесс изменения размера – как отдельный скрипт.
Мне нравится предлагать следующие подходы: Подход 1. Не изменяйте размер во время загрузки! Создавайте измененные версии «на лету» только тогда, когда они запрашиваются в первый раз и кэшируют созданные изображения для непосредственного обслуживания последующих запросов. Я видел несколько упоминаний об Amazon CloudFront как о решении в некоторых других потоках в Stackoverflow.
Подход 2. Вызовите код для создания измененных версий как отдельный асинхронный запрос после загрузки исходного изображения. Будет доступна задержка в масштабируемых версиях. Поэтому напишите необходимый код, чтобы отобразить на веб-сайте изображения владельца места, пока не станут доступны масштабируемые версии. Вам нужно будет выяснить, каким образом доступна масштабированная версия или нет (например, файл проверки существует или задан некоторый флаг в базе данных). Некоторые способы создания асинхронных запросов cURL предлагаются здесь, если вы хотите попробовать.
Я думаю, что оба подхода будут иметь одинаковый уровень сложности.
В качестве ответов на этот другой вопрос предлагаются некоторые другие подходы.