Как после 400 часов работы снятие ограничения на 2 МБ резко увеличило продажи
16 апреля 2023 г.Иногда, когда вы некоторое время работаете инженером-программистом, вы узнаете, какие области ремесла заболочены.
Вы точно знаете, как это сделать, вы знаете все проблемы, которые могут возникнуть, и вы подходите к таким областям с особым вниманием, громко смеясь, когда кто-то думает, что может сделать это быстрее и лучше, не зная, что их ждет впереди.
Это история об одной из таких областей, в которых я многому научился за свою карьеру.
Чему меня научили 400 часов видео
Где-то в 2007 году YouTube было уже два года, а это значит, что о нем еще почти никто не знал. Люди записывали видео на SD и сохраняли их на CD или DVD.
В те дни никто не предполагал, что вы будете загружать каждое видео в Интернет, потому что загружать их было очень дорого.
Ну кроме торрентов разве что. Но уже существовали приложения для записи вашего экрана и добавления подписей, поэтому было интересно узнать, можно ли загружать видеоуроки онлайн.
С учетом сказанного я купил сервер CentOS и начал собирать сайт онлайн-видеоуроков.
Чтобы это работало, мне нужно было решить две вещи: как разрешить людям загружать учебные пособия и как дать людям возможность их просматривать.
Я думал, что загрузить видео было довольно просто. Вы просто добавляете поле ввода в HTML и получаете файл на сервере.
Но это произошло тяжелее, чем предполагалось. Во-первых, это размер видео, а во-вторых, качество интернет-соединения.
Мой сервер, использующий PHP, единственный язык, который предлагал все, что вам нужно (который до сих пор это делает), был великолепен. Он работал на Apache, а затем на Nginx.
Дело в том, что ранние версии Ngnix не ожидали такой полезной нагрузки. Мне пришлось настроить несколько параметров, чтобы сервер мог принимать до 30-60 минут постоянной загрузки и размер передачи. Потребовались некоторые эксперименты, и в итоге это сработало.
Другой проблемой был способ разветвления процессов Ngnix. В ранних версиях Ngnix были ошибки, из-за которых вилки неожиданно зависали.
Такая вилка, повешенная одним пользователем, позже была назначена другим пользователям, то есть они тоже не могли загружать видео.
Мне приходилось хранить информацию о том, кто использовал какой процесс, и убивать их, когда пришло время это сделать. Более того, мне приходилось регулярно каждую ночь убивать все процессы, потому что в течение дня накапливались баги.
После долгих часов, потраченных на настройку Nginx и PHP, загрузка наконец-то заработала.
Следующим шагом было отображение видео пользователям. В то время был доступен один онлайн-плеер. Я не помню название, но оно было хорошим и предлагало субтитры. Это было важно, потому что я хотел, чтобы все могли учиться по видеоурокам.
Но возникла другая проблема. Воспроизведение необработанного видео было очень сложным. При достаточно быстром соединении сильно глючил, а иногда даже ломал браузер.
Там уже был ffmpeg, поэтому я разобрался, как оптимизировать видео. Важным аспектом видеоуроков является то, что вы хотите показать весь экран в высоком качестве. Потому что иначе люди не увидят, что вы нажимаете, и какие тексты отображаются на мониторе.
По сравнению с живыми записями того времени, видеоуроки предъявляли более высокие требования к качеству (поэтому видеоуроки не были сильной стороной YouTube на протяжении многих-многих лет).
Потребовалось много экспериментов с ffmpeg, чтобы выиграть сделку по высокому качеству и небольшому размеру видео. Конечно, это нельзя было сделать мгновенно, поэтому было задано задание cron, которое запрашивало базы данных MySQL и находил видео, которые еще не были должным образом преобразованы.
Также было важно проверить, было ли видео создано не только с помощью ffmpeg. Хотя ffmpeg был великолепен, иногда ему не нравился формат сжатия видео или аудио или даже размер входного видео. В результате он выдал видео на выходе, но оно было черным.
Поэтому я добавил еще одну работу cron. Его задача заключалась в том, чтобы снова запустить ffmpeg на выходном видео, прочитать его размер, разрешение и захватить один кадр, который мне также был нужен для миниатюры. Затем процесс проверил пиксели на миниатюре, чтобы убедиться, что она черная. Если ошибок не было и миниатюра не была черной, считалось, что преобразование прошло успешно.
Я думал, что этого будет достаточно, но оказалось, что это не так. Потому что иногда ffmpeg или другая библиотека просто зависают. Это означает, что процесс преобразования или процесс проверки также зависал и не мог сохранить информацию, если что-то пошло не так.
Поэтому я добавил еще один процесс cron. Третий процесс проверял предыдущие два процесса. Он проверял в базе данных, когда начался процесс преобразования, когда сообщал, что был активен в последний раз, и сравнивал с текущим временем.
Так, например, если конверсия не отвечает в течение трех часов, я помечаю конверсию как неудачную и добавляю ее для повторного запуска. Если процесс проверки не отвечал после 30 минут работы, проверка базы данных не удалась, поэтому видео приходилось конвертировать с нуля, а процессы приходилось завершать.
Обычно это помогало. Если это не сработало в третий раз, система отправила электронное письмо, значит, что-то не так.
В конце концов система заработала, и люди смогли загружать видео. Видео конвертировались и отображались на странице с миниатюрой и субтитрами.
Это был интересный проект, на который я потратил более 400 часов. Это научило меня многому об обработке и проверке видео, аудио.
Но это также научило меня тому, что обработка загрузок — это болотистая область, на которой я должен сосредоточиться. Это окупилось…
Ограничивая загрузки, вы ограничиваете продажи
Можно подумать, что сейчас, в 2023 году, ситуация иная. Но это не так. Наверняка многое изменилось. Легче получить вычислительную мощность и хранилище. Интернет-соединение лучше. Инструменты стали лучше и имеют более подробную документацию.
Но все же, с настройками по умолчанию некоторые загрузки будут терпеть неудачу из-за размера. Форма загрузки по умолчанию не будет работать на устройствах Android. Я снова и снова вижу эту проблему во многих веб-приложениях.
Обработка нескольких форматов видео и даже фотографий сложна. Тем более что сейчас появились новые экспериментальные форматы.
Например, несколько лет назад я разрабатывал систему управления контентом и планирования для социальных сетей.
Он должен был предложить маркетологам возможность редактировать загруженную фотографию. Только основные вещи, такие как обрезка и фильтры. Даже при использовании новейших библиотек он не был на 100% надежным и требовал много настроек, чтобы сделать его хотя бы пригодным для использования в приемлемой степени.
Во многих случаях загрузка файла является важным этапом процесса. Например, когда вы заполняете длинную форму и на последнем шаге вам нужно загрузить файл.
Если по какой-либо причине загрузка не удалась, вы должны защитить пользователя от потери всех данных, которые он уже ввел.
Вам нужно обработать сценарий, когда загрузка не удалась, или любой последующий процесс, который вы применяете к файлу.
Один из способов решения некоторых из таких проблем — ограничить пользователей размером и форматом. Звучит заманчиво.
Недавно я работал над проектом электронной коммерции, где люди могли создавать свои собственные продукты, загружая фотографии. Однако приложение ограничивало размер изображения до 2 МБ и разрешение 1000 x 1000 пикселей.
Было предложение увеличить эти лимиты до 3Мб и 2000x2000px. Я достал телефон, сделал фото и показал людям, какого размера фото.
Это было 4 МБ и около 3000x3000px. Поэтому было сделано еще одно предложение, чтобы объяснить это. Поэтому я увеличил разрешение, с которым мой телефон делает фото, и сказал нам, что мы должны полностью снять эти ограничения.
Также было предложено сохранить ограничения, поскольку люди могут конвертировать фотографии и уменьшать их перед загрузкой.
Это верно. Но большинство людей не знают, как это сделать, не хотят об этом думать и могут столкнуться с трудностями. Мне удалось убедить клиента и команду полностью снять ограничения.
Это был отличный шаг, потому что он резко увеличил продажи, а количество выходов также упало, доказывая, что люди хотели покупать товары на своих телефонах, но они были заблокированы требованиями. Снятие ограничений было одним из простых решений, позволяющих большому количеству людей покупать товары, которые они хотели.
Загрузка файлов — сложная область, но в некоторых случаях она может иметь решающее значение для продаж и удовлетворенности клиентов (опять же продаж).
Вот почему я уделяю особое внимание этим областям разрабатываемых мной систем, которые обрабатывают загрузку файлов, потому что это место, которое может больше всего повлиять на бизнес клиентов.
У вас есть истории, связанные с загрузкой файлов? Поделитесь в комментариях!
Также нажмите на значок сердца, поставьте лайк и поделитесь в социальных сетях. Это мотивирует меня писать больше на такие темы!
Если вы не хотите слишком много думать об этом как инженер-программист, загляните на Файловый стек тоже. Это API для обработки загрузки файлов Javascript. Они спонсируют конкурс, в котором я участвую с этой историей. Filestack и HackerNoon - спасибо за мотивацию поделиться! Было здорово это сделать! п
Оригинал