Сергей П

Добавлю к очень хорошим ответам выше, что имеет смысл для конкретно вашего сайта посчитать статистику использования разных размеров в сочетаниях. Ещё нужно понимать цели, которые вы преследуете.
Если вам нужно снизить трафик с севрверов - это одно. Если вам нужно ускорить рендер страницы, то это другое. Причем для разных страниц и разделов оптимум может быть разный.
К примеру, если у вас страница с комментариями пользователей, где огромное количество этих комментариев с разными аватарками мелких размеров, а большая аватарка на такую страницу грузится только одна (своя), и в профили пользователей кто-то редко заходит, то конечно лучше кешировать и отдавать с сервера мелкие иконки сразу. Это повысит скорость рендера страницы с комментами.
Отдавать аватарки лучше с CDN, так быстрее получится для рендера страницы.

Вам, похоже, не нужно какое-то абсолютное время. Достаточно отправить игроку сигнал и замерить локальное время реакции на этот сигнал по времени браузера игрока. Браузер игрока знает локальное время, знает когда пришел сигнал с сервера и знает когда отреагировал пользователь. Осталось отправить на сервер локальное время регистрации пришедшего сигнала от сервера и время реакции игрока.

Минус у схемы только один, через отладочную панель можно жульничать.
Чтобы жульничать было труднее, можно заставить клиенты подключиться к веб-сокету сервера и сигнал с реакцией прокидывать через него. Это тоже не убережет от жульничества с автоматизацией реакции.
Наверно самое безопасное в плане жульничества решение потребовало бы стриминга видеопотока с физической реакцией игрока, а все подозрительные случаи выборочно потом проверять и модерировать людьми покадрово на предмет подделки видеосигнала.

https://grafana.com/
Есть и другие, но это по описанию подходит лучше всего.
А данные надо хранить в БД, а не в экселе

То, о чем вы говорите - это не какая-то отдельная программа. Код, который отвечает за такую загрузку с прогресс-баром должен располагаться частично на сервере, а большей частью на клиенте, то есть в браузере. Это значит, что этот код будет встроен в ваш сайт и на серверной и на клиентской его стороне.
Реализовать это можно разными способами, и есть много разных готовых решений для разных фреймворков. Приделать загрузку от одного фреймворка к другому в общем случае можно, но это не тривиальная частная задача, поэтому искать надо способ сделать это в вашей экосистеме, а не отдельно.

Однако, если совсем пофиг на интеграцию с существующими интерфейсами и сайтом, то можно взять любой пример с самым классическим аплоадом из любого фреймворка прям по документации, и поднять его в изолированном докер-контейнере. У вас получится отдельная изолированная страница, вы зароутите её на отдельный адрес через ваш обратный прокси (например nginx), и будет у вас колхоз, но с прогрессбаром.

Если вам не понятно то, что я тут рассказал, то, увы... Пока что вам будет не по силам такое реализовать. Опыта и знаний маловато. Учитесь, или идите к фрилансерам, ну или более детально формулируйте свой вопрос. Потому что по нынешней его формулировке выходит, что вам нужна подробная индивидуальная лекция о том, как работают веб-приложения, причем для совершенно неподготовленного человека. Это часов 15 индивидуальных занятий.
Вы же понимаете, что этот ресурс не про такое?

Если все субдомены должны ввести на один физический сервис, то на днс сервере ничего динамически прописывать не надо, просто добавляете запись со звёздочкой.
Если нужен просто редирект, то можно реализовать его на nginx, например, a на бэке ничего делать не приедпридется. А можно наоборот, все сделать на быке, туда по-любому прилетает полный урл, можно делать любую логику.

Что конкретно не понятно? Там вам в комментарии правильно объяснили, что вопрос задан слишком широко. Мало данных. Не понятно что именно не понятно.

Нужно поставлять свои решения с развертыванием в докере. Компоуз файл ему отдаете и говорите. что дальше не ваша забота. Может он на QNX каком-нибудь или OS/2 решил бы все завести. Это его проблемы.
Ну а то, что вы не согласовали заранее требования к платформе и окружению, не оговорили в каком виже будет поставка и какие вы готовы обеспечить работы по развертыванию - это теперь ваши обоюдные роблемы.
Если вы уже отдали ему исходники, то он может попытаться свалить с ними под предлогом, что вы ничего не развернули на его железе.
То. что не оговорено в договоре, будет геморроем. Ну а там уж только меряться кому геморрой длиннее покажется.

Как бы ни позиционировал себя хакатон, насколько бы готовыми ни требовались решения на выходе, на деле у всех получается всё сырое и не готовое не то что к продакшну, но и вообще к любому использованию. Хакатон - это не про попытку впихнуть полный цикл жизни продукта в два хакатоновских дня и бессонную ночь.
На выходе хакатона хорошим результатом будет прототип или демонстрация концепции. Всё зависит от тематики, конечно, но не стоит ожидать продукта на выходе.
Самое ценное и нужное что можно извлечь из хакатона - это знакомства, новые идеи, опыт авральной работы в команде, приятные воспоминания о классном приключении, романтика, общение, мотивация к развитию, понимание в какую сторону хочется расти и развиваться дальше, дельный совет от членов своей команды, от соперников, от членов жюри.
Если команда подобралась достаточно цельная с более-менее опытными учатстниками, то может получиться годная, продуманная (в общих чертах) концепция, вразумительная презентация и симпатичный прототип.
Просто обрисуйте для себя то, в чем вы более-менее разбираетесь или готовы оперативно поразбираться и ищите команду, где нужно делать то, что вы хоть как-то умеете. Если, скажем, в команде уже есть более опытный верстальщик, то можно попроситься и в эту команду, более опытный партнер сможет нарезать и делегировать вам понятных задачек, подсказать, если будут вопросы, а сам будет тем временем расти в каких-то новых для себя областях помогая бэку придумывать АПИ или сосредоточившись на фронтовой логике.

В любом случае это не последний хакатон, в котором вам предоставится возможность поучаствовать. Было бы желание.

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

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

Я еще раз упомяну про ассеты. Их много, много бесплатных. Это хороший способ сэкономить на дизайне, если у вас нет отдельного дизайнера в команде, а даже если и есть, но он не очень опытен и не знает что рисовать, то такой ассет может служить примером для перерисовки в ваш уникальный дизайн.
Существуют ассеты графики, вёрстки, звуков, анимаций, моделей, иконок... Хорошо иметь подборочку в загашнике.
Не забудьте также о шаблончике презентации для хакатона. С нуля ее рисовать гораздо дольше, а те же ассеты и клипарты из загашника позволят вам кастомизировать ваш шаблон под тему проекта более оеративно.
В инете полно подборок вроде такой.

Заведите себе Pocket. Удобно складывать туда полезные статьи и мануалы по созданию проектов и приложений, по настройке окружения, по конфигурированию nginx... аккуратно подходите к тегированию таких статей, ссылок и материалов. То, что может пригодиться в хакатоне, можно помечать отдельным тегом. а потом, когда приспичит, все релевантные материалы вам станоятся доступны мгновенно, да к тому же вы сможете поделиться с командой. Часто опытные разработчики надеются на свой опыт и не готовятся с такими ссылками и ассетами, а они могут сильно сэкономить время команды.

Подберите себе провайдера, у которого можно на сутки или несколько снять бесплатную (пробную) или недорогую VDS. Попробуйте с ней поиграться, чтоб не разбираться потом в админке с нуля в цейтноте.

Заведите себе какой-нибудь дешевый домен. Если планируете дальше карьеру разработчика или в целом айтишника, то личный ресурс в интернете вам в любом случае пригодится. Не так уж это дорого, по крайней мере до первого продления. Разберитесь как быстро поднять на нем субдомен и привязать к IP вашей тестовой VDS-ки. Это полезное умение сэкономит массу времени на хакатоне. а ваша команда получит серьёзный козырь и преимущество перед другими имея работающий прототип не где-то на вашем локальном вайфае с ноута одного из членов команды, а в интернете и этот прототип смогут потрогать все жеоающие и члены жюри. Это не так важно по сравнению с более работающим прототипом, но если у вас будут заготовки всего этого и времени это не займёт, то это только в плюс.

Короче, просто возьмите блокнотик и карандашик с собой на первый хакатон. Ходите там с широко открытыми глазами, примерьте это дело к себе, постарайтесь найти интересное, поучаствуйте там и сям, предложите себя, подсказывайте что знаете, спрашивайте что интересно. Проект - это не только разработка, но и идея, концепция, UX. Вы же пользуетесь сайтами и приложениями, у вас есть своё какое-то видение и понимание что в них удобно, а что нет. Используйте свой бытовой опыт, применяйте его на практике.

С первого хакатона вы увезёте блокнотик с контактами, с баззвордами (словами, обозначающими технологии, продукты, инструменты и решения, о которых вы не знали ранее, но о которых точно стоит почитать и что-то детально изучить), идеями, набросками, мыслями.
Фотайте на презентацииях соперников и докладчиков интересные слайды (контакты, диаграммы, QR-коды). Потом может пригодиться. Можно включить диктофон в кармане и носить, потом контакты, которые вам просто продиктуют, а вы неразборчиво напишете в блокноте, можно будет восстановить. Также можно будет "вспомнить" какую-то инфу, которую вы и не собирались запоминать.

А тут ссылок накидаю:
Вот примеры ассетов:
https://habrahabr.ru/company/plarium/blog/329330/
https://habrahabr.ru/company/plarium/blog/330068/
https://habr.com/post/421149/
https://vectorcdr.com/skhemy-korobochek
Еще есть чудесный и замечательный https://www.thingiverse.com/ как источник идей, есть генераторы текстур, и куча полезных ондайн редакторов всего на свете (GeoJSON, куча всего, js sandbox)

Прикольная статья о том, почему стоит участвовать в хакатонах: https://habr.com/ru/company/ods/blog/450034/
А вот подробная статья как готовиться к хакатонам: https://habr.com/ru/company/leadersofdigital/blog/...

Хоршо иметь в гитхабе заготовочку идеального пакета и идеального приложения. Вот есть такого рода статеечки: https://habr.com/ru/post/483512/

Бывают вот такие и аналогичные ресурсы, на которых можно попробовать верстку и логику: https://replit.com/

При такой постановке вопроса на любом языке у вас CMS медленно будет работать ввиду недостатка опыта правильной разработки.
Язык программирования нужен не для скорости, а для понятности людям. Скорость выполнения кода не так критична в вебе, как правильная архитектура. Иначе всё бы писали на ассемблере, но где вы видели сайты на ассемблере? Нет, наверняка такие есть и вполне можно сделать какой-нибудь фреймворк с CMS хоть на ассемблере, хоть на брейнфаке, но это глупо.
Обычно язык программирования не является бутылочным горлышком для скорости CMS.
Ошибки в архитектуре, непродуманная масштабируемость, отсутствие кэширования, излишняя связность, избыточность внешних зависимостей, пренебрежение CDN -- всё это гораздо сильнее влияет на тормоза и все эти проблемы можно реализовать на любом языке.
Язык нужно выбирать так, чтобы он давал возможность делать код более простым, читабельным и понятным не смотря на его количество. У языка должно быть большой комьюнити, чтобы можно было легко находить недорогих и эффективных специалистов для поддержки проекта.

Питон проще осваивать, к нему больше примеров, библиотек, обучающих курсов, книг и открытого кода в инете. А ещё полно удобного инструментария. Для любых ваших проектов питон подойдёт не хуже го.
Когда вы готовы разрабатывать на Го, у вас уже не возникает вопроса питон или го. А если возникает, значит питон.
ИМХО.

Но го неслабо так развивается и у него большие перспективы, как мне кажется.

Во-первых, определитесь с набором функциональности. audiodenoise - не полноценный редактор, там просто загрузка, обработка и получение файла обратно. Онлайн-редактором это называть странно.
Во-вторых, чётко сформулируйте ТЗ. Оно вам пригодится в записке к дипломной работе.
В-третьих, разработайте лаконичный и удобный API, опишите его в формате openapi.
Затем уже можно приступать к реализации. Она у вас будет состоять из бэкенд аи фронтенда.

В зависимости от богатства функциональности, у вас будет либо более-менее полноценный аудиоредактор, который загружает данные дорожек, позволяет сводить их, держит стек операций над данными и кэш промежуточных слоёв обработки, либо получится вот такая-вот тривиальная форма как в вашем примере: загрузили файл и в месте с файлом передали параметры того,ч то нужно с ним сделать. Обычно на бэке все эти параметры преобразуются в развесистую командную строку или пайплайн из набора команд, а потом всё запускается,а результат кладётся в кеш и закрепляется за сеансом.

Ваша задача, как все инженерные задачи, разбивается на много мелких частей. ТЗ позволяет структурировать объём предстоящей работы.
В ходе поиска информации, возможно, вы найдёте утилиты командной строки, которые уже умеют делать всё что вам надо и тогда ваш аудиоредактор будет не сильно отличаться от любого веб-интерфейса из одной формы.

Приходите с конкретными вопросами, когда у вас будет ТЗ или, хотя бы, подробный фичлист

Yariik, вот этой фразой вы расставили точки над Ё.

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

Теперь я вам готов ответить. Купите несколько HDD и недорогой комп. Поставьте комп в чулан, a диски настройте в программный RAID-массив (какой тип RAID выбрать - это отдельный вопрос, отдельно и задавайте). Нужно, чтобы было резервирование на случай выхода из строя одного диска.
На компе поставьте линукс, поднимите SAMBA, попросите у провайдера белый IP.
Настройте nginx на раздачу каталога с музыкой в виде статики.

Этого достаточно. Ваш "серьёзный" подход и размышления о рисках говорят сами за себя. Не будет никакой аудитории и вами никто не заинтересуется.
Если бюджет для вас настолько критичен, что вопрос встаёт даже в проблематичности бэкапа, то никакой рекламы и раскрутки сервиса вы не обеспечите.

Если я вас не убедил, подключите себе CDN Cloudflare поверх домашнего хранилища и попробуйте. Никто не мешает сайт вашего сервиса держать на VDS? Источник данных на домашнем компе, а раздавать публично через CDN Cloudflare.

P.S. Имеет смысл не брать для RAID-массива диски одной серии. Желательно иметь запасной пустой комплект в отключенном состоянии на подмену. Если вылетит один диск, не исключено что на подходе и другие. Первое, что нужно делать - это синкануть на свежий и по одному плавно выводить все выжившие диски из RAID заменяя свежими.

Но... кажется это не по вашим бюджетам, сударь.

Ну кто так вопросы составляет, блин!?

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

"Загрузить" - это имеется в виду единоразовая акция? Через FTP rsync не подойдёт? Или это пользователи будут "загруЖАТЬ" такие здоровенные треки?

Что бы по щелчку на плей все быстро воспроизводилось

Так в чем вопрос, в том, чтобы быстро воспроизводилось или загружалось на сайт?
Бывает download, а бывает upload. Проясните в чем именно вопрос. Или тут целых два вопроса?
Если акция одноразовая то загружать (upload) треки можно как угодно. Это делает какой-то знающий специалист, а загрузка всё равно будет длиться не быстрее, чем пропустит интернет-канал.

Если upload от пользователей, то выше ответили, нужно нормальный прогресс отобразить и скорость вы не увеличите, поскольку она ограничена пропускной способностью канала.

Если речь о download для пользователей, то убедитесь, что у вас веб-сервер поддерживает и настроен на докачку файлов с произвольного места. Тогда проигрывание на странице можно запускать не дожидаясь полной загрузки.
Однако будьте осторожны, бывает вот такая атака.

Не надо беседовать с "прохожими", вы просто потеряете много времени.
Пишите статью на хабре, это будет более эффектвино.
Основная фишка хакатона - это локальность. Люди участвуют для получения новых впечатлений, а изоляция в каком-то новом месте на время проведения хакатона "освобождают" человека от рутинных бытовых занятий, от основной работы, от "поспать", от обычного распорядка.

Онлайн-хакатон это своего рода оксюморон. Чтобы он не превратился в "пшик", нужно чем-то привлечь и чем-то удержать в нём людей. Это непросто. Недостаточно просто сделать всё как обычно, но онлайн.
Вам придётся подыскать либо крутую цепляющую тему в паре с очень активным и большим комьюнити, либо громкий и резонансный повод, который поддержит азарт и вовлечение

Для более плодотворного поиска ответа на ваш вопрос хорошо бы знать больше подробностей. Какая тема, какой стек технологий, какая цель...

Я, вот, подумываю на счет концепции "бесконечного хакатона".
Это такая площадка для публикации идей, команд и проектов для обсуждения и совместной работы. Кто-то скажет: "Зачем?! Есть же гитхаб, гитлаб, кикстартер и прочие! Там можно оформить страничку проекта, обсуждать фичи, принимать фичреквесты, форкать, делать ревью..."
Суть "Бесконечного Хакатона" в том, что там первична именно коллаборация обсуждения и планирования, а не кодинга.
На площадке можно было бы завести проект, оформить его карточку (для эффективного поиска), настроить донаты для краудфандинга, привязать репозиторий (возможно сделанный по шаблону).
Для работы с кодом есть IDE и gitgub, для общения есть зумм, но нет единой точки кристаллизации, где можно искать проекты, единомышленников и идеи.