Ping между New-York и Los-Angelos составляет примерно 70мс. Тоесть у вас еще очень даже неплохие показатели времени. У вас работала база внутри докера. Вот и пускай там работает всегда. У вас архитектура такая. Вы разрабатывали и тестировали исходя из таких вот условий.
Возвращайте все взад как было.
И вам надо думать над архитектурой. Что у вас в запросах. Подумайте над когерентными запросами. Например с одной страницы с одно пользователя будет прилетать все время 3 типа запроса. В одном и том-же порядке. Попробуйте их объединить в батч. Оформить как хранимую функцию и получать сразу все 3 ответа за 1 раз. Тоесть у вас вместо трёх блокирующих TTFB будет один TTFB.
Попробуйте кешировать данные через nginx. В большинстве случаев кеширование является спасением для таких вот нагруженных систем. Кеширование - это компромисс. Какие-то данные будут стареть в кеше. Это расплата.
Надо понять соглашение о вызовах. Как эта либа вызывалась. Какие в ней функции?
И вообще имеет ли смысл тратить ресурсы в переписывание? Может проще создать новый софт.
Что там по комментариям? Упоминается ISO 1745. Это телекс-протокол. Что нам нужно от этого протокола?
Какие функции? Найти им аналог в оперсорце реально? Вот такие вопросы.
Вы просто таким постом обесцениваете Котлин низводя его до простого конвертера. А если конвертить - то
зачем вообще нужна смена языка? Оставайтесь на Java.
Jacen11, смена языка в проекте это "нихрена себе" смена версии. Это не билд и не минор. Это точно мажор даже с префиксом. Вобщем безразлично как там гугл-маркет различает эти эфемерные сущности. Главное чтоб все пользователи поняли что программный продукт сильно обновил версию. Это - важно.
А проблемы пре переносе будут. Котлин - это более сложный и более высокоуровневый язык. Он вводит операции и сущности которые раньше в Java не было. Но может быть и такая ситуация что Java использовала какую-то технологию которая в Котлине так не работает или ее вообще нет.
По идее где-то в пакетах должна быть функция которая экранирует служебные символы текстового поиска.
Программист может и не помнить всех служебных. А если идет пользовательский ввод - то его трудно
очистить от служебных вручную. В Java регулярках есть метод quote(..) который специально это и делает.
Если счетчик будет обновляться очень часто, то файл может стать узким местом в системе.
Сколько транзакций в секунду он выдержит я не знаю. От многого зависит. Но главный
вопрос - какие гарантии ты хочешь от этой системы.
Чтоб построить sequence наподобие тех объектов что лежат в базе данных - нужно поработать
с lowlevel API (fsync). Нужно работать двоичным образом. Поэтому echo тут не катит. И нужно
работать блоком, кратным минимальному блоку файловой системы.
Ну делайте так.