А, ну кабельная цепь - тоже отличный нормальный вариант. Скорее всего прыгать напряжение в данном случае будет совсем незначительно - линия и скорость небольшая. А если использовать достаточно широкие щетки - то вообще незаметно.
Добавлю важное замечание: данное API выдает коэффициенты в виде чисел, что для работы с реальным деньгами недопустимо - для этого следует применять тип Decimal и соответствующие библиотечные решения. Т.о., это API не для продакшена и не более чем для ознакомления с примерными курсами.
2 разработчика ) CI/CD на отдельном сервере - иначе гитлабу становится совсем плохо, т.к. CI/CD запросто может сожрать вообще все доступное. Так что для пайплайнов используйте отдельный сервер. Гитлаб сам по себе не из легких систем. Вообще, там можно поковырять настройки и попробовать отключить лишние сервисы, но сомневаюсь, что сильно легче станет.
Скорее всего там у вас какая-то проблема - надо изучать. У меня гитлаб крутится на 16 ядрах и 12 гигах оперативки - 10 гигов он кушает стабильно. Так что рекомендую поднять число ядер хотя бы до 6-8 и памяти минимум до 8. На 4 ядрах он в принципе работал, но с явными лагами, а вот с 16 заработал ощутимо быстрее.
Диагностика сети решается обычным мониторингом - вешаете мониторинг на сеть, хотя бы на самом простом уровне мониторинг на время выполнения и частоту запросов в вашем приложении (можно, например, в тот же редис или монгу все складировать как наиболее простое решение и забирать и показывать графаной), а так же нагрузку на диски и процессоры. Собираете данные и далее уже смотрите, когда были медленные запросы - что было с другими компонентами. Кроме того, проблема может быть в стороннем сервисе, куда отправляете или откуда получаете запросы - там так-то тоже не бесконечная скорость. Так же проблемы могут быть где-то на промежуточном узле.
Посмотрите в сторону покупки виртуального номера в нужной стране с работой через SIP от какого-нибудь неназываемого сервиса, который легко ищется в гугле по фразе "IP телефония, виртуальные номера, облачная АТС" (опасное название у него, да, поэтому вот так). Я им пользовался довольно продолжительное время - отличный сервис, цены вполне адекватные на сами номера.
Так и пусть вешает. Разве ж проблема это? Вот если надо хэндлеры цеплять отдельно по каким-то специфичным причинам - то тогда да, использовать отдельный публичный метод самое то. Я всегда так и делаю:
Более практично это решается как раз объектом со списком нужных вам пар ключ-значение. Изменение глобальной области видимости может создать вам кучу проблем. Например, попадётся у вас там имя типа Array - и все, это сломает вам массивы и все приложение.
Иван Иванов А какие вы провели исследования вашей проблемы и в чем именно она заключается? Вы нашли ваше бутылочное горлышко? Провели более детальное его исследование и выявили конкретное место/причину? Каким образом и по каким критериям вы определили, что проблема именно в сети и и почему для её устранения надо запускать запускать дополнительные потоки?
Я, кстати, погуглил проблему: на первых же страницах пишут, что там максимальное ограничение в 32k*32k, а на СО рекомендуют использовать другие утилиты и сервисы для создания диаграммы
Конечно поможет, ведь тогда ОС сможет неиспользуемые данные из ОЗУ сбросить на диск и позволит приложениям использовать освободившееся место в памяти. Размер - по выбору системы. Ну или вручную указать 1.5 размера ОЗУ (стандартная рекомендация).
jastioknow а вы провели исследование и выяснили, что в данном случае является узким местом/бутылочным горлышком? Или, может у вас какая-то проблема со скоростью загрузки у клиента? Как и чем измеряли? Какие результаты?