d'Ivan

Linux + ImageMagick + ps2pdf + простенькая веб-морда для загрузки файлов, запуска скриптов и выдачи результата. Буквально один скрипт на РНР, например.
Если задания шаблонны - можно использовать inotify для выстраивания схемы "пользователь положил файл в одну папку и забрал в другой сжатый результат".

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

Эрик Блейн, которого больше знают под псевдонимом Джордж Оруэлл, нервно курит в сторонке.

AWS может быть и рад был бы Вам что-то продать - но ему не дают :) И еще долго давать не будут. И не факт, что когда "там" разрешат - его не забанят "тут"

"Я знал, что будет плохо, но не знал, что так скоро" (С) В. Цой "Фильмы"

1Кб весом и внутри пустота. Что вы там хотели увидеть?

В Linux все бинарники хранятся в /usr/bin/

Нет.

Если речь идёт о размещении по каталогам, то 32-битные библиотеки помещаются в /lib32, /usr/lib32 и ряд других каталогов.

Для Дебьяна информацию можно найти здесь и тут. По другим дистрибутивам, полагаю, тоже есть информация на их сайтах.

Мне кажется что ты не тем занят. Нужно очень сильно постараться чтобы ОС стала узким местом в бизнес логике.

Собери данные профилирования.

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

Почему медленно когда по 1 сообщению? Идей много. Как вариант - виновата сетевая латентность и некие усиленные проверки транзакций или квитирований с вашей стороны. Вот по этому пункту нужно смотреть конфигурации и пинговать и трассировать ваши сети.

Что значить "Надо их где-то хранить"? Эти данные будут использоваться далее, отдельно от описанного?
Если не будут, просто сразу пересылайте из сервера Go в сервер nodejs. Если, чтото и потеряется, то оно все равно утратит свою актуальность и придут новые данные.
Если будут использоваться, то зависит от того, как будет использоваться, вполне может и вообще классическая СУБД нужна.

На heroku нельзя хранить файлы, так как любой инстанс скрипта может быть запущен на разных узлах сервиса и в любой момент перезапущен. https://help.heroku.com/K1PPS2WM/why-are-my-file-u...

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

- Предположительно, тебе загрузку замедляют 2 индекса по id, uuid. Выключи их. Потом построишь когда загрузишся.
- У тебя - MariaDb. Модная зверюга. Попробуй мнесто InnoDB поставить другой двигатель Aria например.
Ну и проверь там чтоб XML и датафайлы лежали на физически разных дисках во время загрузки.

Скорее всего не будет работать. NAS может обеспечить throughput, но не IOPs.

Это одна причина. И вторая - протокольная. Если Mysql все таки запрашивает какую-то операцию которая характерна только только для локального диска (fsync) то что будет если мигнет сеть ? Это фатально для базы. Я не знаю как она среагирует, но это равносильно выдергиванию SATA диска из шлейфа.

ну примерно вот так:

image: # имя докер-образа 

stages:
  - build
  - tests
  - deploy

build_my_project:
  stage: build
  tags: 
    - тэг раннера где запустить
  script:
    - ... # собственно действия для билда
    - ... 
    - ...
    - ...
  artifacts:
    name: как будет обзываться артефакт сборки
    paths:
    - путь до файлов в артефакт
    expire_in: 1 hour # сколько ему жить
test1: 
  stage: tests
  tags: 
    - тэг раннера где запустить
  needs:
    - build
  scripts:
    - # действия по выполнению теста

test2: 
  stage: tests
  tags: 
    - тэг раннера где запустить
  scripts:
    - # действия по выполнению теста 2

deploy_to_dev:
  stage: deploy
  tags: 
    - тэг раннера где запустить
  needs:
    - tests
  rules:
    - if: $CI_COMMIT_BRANCH == "development"
  scripts:
    - # действия деплою в dev


deploy_to_prod:
  stage: deploy
  tags: 
    - тэг раннера где запустить
  needs:
    - tests
  rules:
    - if: $CI_COMMIT_BRANCH == "master"
  scripts:
    - # действия деплою в dev

словами: на первом шаге - build выполнится то что прописано в scripts (последовательно, по строкам)
на втором шаге - test - параллельно выполнится два (ну или сколько надо блоков тестов)
на третьем - deploy - выполнится или deploy_to_prod или deploy_to_dev или ничего в зависимости от того в какой ветке идет сборка ($CI_COMMIT_BRANCH)
image: # имя докер-образа - имя соответсвующего docker-образа с подготовленной средой разработки (node:14 - для npm, mcr.microsoft.com/dotnet/sdk:6.0 - для .net6 и так далее)
можно и любой свой

needs: - описывает от каких шагов зависит шаг (это относительно свежее, ранее более жесткое dependencies:)