Монолитный Perl и виртуальные машины по 700 Гб оперативной памяти

где пулы у ТС-то? если бы у него были пулы, то он бы не использовал Memcached - тут же логика абсолютна прозрачная: если я умею хранить соединения с БД в памяти приложения, то мне ничего не мешает в память пихать и данные - мне совершенно здесь не нужен никакой внешний кеш - у возникает только потребность в получении сообщений об инвалидации данных.

Какая связь между неиспользованием пула и использованием memcached?

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

Но это неверно говорить, что, мол, ничего не поменялось, только аппетиты программистов выросли.

Много что поменялось. К лучшему ли, к худшему, но на Pentium 100 современная жизнь невозможна.

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

да на перле полно разработчиков. просто отдельные жмоты не хотят платить, чтобы кто-то что-то рефакторил. и это относится не только к перлу, это вообще распространённая практика.

Какая связь между неиспользованием пула и использованием memcached?

Да тут много экспертов, которые в теории любую проблему - «одним махом всех побивахом». Ведь весь мир тупой, и придумал сначала ненужные memcached, затем ненужные redis, затем ненужные keydb. Ведь настоящий эксперт их не просветил, что всё это банально не нужно. 95% мира - тупы безнадёжно, всё что-то придумывают, а настоящий эксперт - вот он, на ЛОРе, бесплатно советы раздаёт.

Гугл увидел бы, если б по русски читать умел, и мигом бы скоростью YouTube выросла в 10 раз. У них ведь там явно используются ненужные докеры и memcached. Нет экспертов, чтобы подсказать, что надо выкинуть, и что тюнинг большой системы по производительности может сделать наш эксперт за несколько тысяч рублей, одним махом, не глядя.

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

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

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

заблуждения жителей Нерезиновска. они кроме своего искусственного рая ничего не видели.

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

ага, «везде». ну ты фантазёр. когда я раньше ходила в походы по местным пикулям, я видела посёлки, где нет электричества. туда пару раз в неделю ездит молоковоз на тракторе - вот и вся связь с внешним миром.

я живу достаточно близко к центру в городе-миллионнике. один провайдер в доме. остальные - «нет возможности».

кто тебе будет тянуть километры провода ради нескольких подключений? заплати за все работы сам - проведут. а так «нет возможности».

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

Логи - наше всё.

А куда делись метрики и трассы?

Это где до сих пор кобол в проде по описанным тобой причинам?

Реально что можно делать в таком случае - просто сидеть и делать новую систему рядом со старой, постепенно заменяя её куски. Начинать внедрять её на максимально раннем этапе [...] по крайней мере это путь, который приведёт к результату

Скорее всего это просто приведет к двум легаси системам.

Это где до сих пор кобол в проде по описанным тобой причинам?

Ткни в любой мало мальски значимый банк в NA… :)

Или в любое достаточно старое gov-agency (их только в США было более 400 до Трампа)…

И причина именно эта - там за секунду проскакивают суммы превышающие годовой бюджет твоей страны - таким БАБЛОМ никто рисковать не будет. Даже если ынженеры крест на всё пузо дают что всё сходится … своё кресло - ближе к (_|_) :)

PS: Но в РФ что COBOL что ADA учить смысла нет, в туда всё равно не возьмут, а внутри ничего нет (ну может Бериев остался) :(

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

вот вы реально в это верите, или кто-то когда-то в уши нассал?

А ты сам то фраерок какой масти будешь?(С)

Ну или если мы в другой палате: А судьи кто?(С)

Я вот работал в Blackberry. «Симулятор эмулятора всея Ынтернета и нашего самостийного к нему подхода»(С) был настолько огромен и сложен что его на плаву держали … только infrastructure engineers за 20 штук, а сколько проггерров и других позиций … И делали его сами, потому что такое тогда купить было нельзя. Никто не предлагал готовый, не было такого ещё :)

эээ… а при чём тут вообще мелкософтовская база?

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

Завидую :) Тоже чтоли в пампасы переехать?

А так то: МелкоМягкости

непонятно, о каких «пампасах» речь. я работала на многие страны. и нигде маздайной базы не было. потому что не нужна она, даже если они примазались под линь. по ссылке на их сайт не пойду: один фиг наверняка не опенсорц, нефиг им набивать скоры.

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

Тема разрослась.

Если кто-то уже предлагал, то прошу меня простить за повторение. Насколько я понял, нужны какие-то доводы для руководства, что бы решить проблему с тормозами попутно начав процесс модернизации. Предлагаемые решения - это «либо заставить обманом (порезать на мс), либо насилием (добить железом), а нужно, чтобы добровольно и с песней» (с).

Как это я вижу, в нынешних обстоятельствах сложившихся в России, способом заставить добровольно петь ИТ-песни и модернизировать ПО является ИЗ, ИБ и всякие ПДн.

Поэтому если драма разворачивается в родном Отечестве, то осмелюсь предложить следующий подход:

1. Для начала собрать подробный с названиями и версиями список всего ПО на котором построена система. Чем подробнее будет тем лучше вплоть до версий пакетов из которых прод собирается.

2. На основании этого списка составить список CVE, которому подвержено это ПО. Если там много легаси, то список CVE должен получиться внушительным.

3. По возможности провести анализ кода. Это добавит CVEшек и, предположительно, позволит завлечь в процесс разработчиков.

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

5. На основании этих списков из п1-3 составить список компонентов подлежащих,переписыванию, обновлению или замене. Могу предположить, что он будет достаточно объемным.

6. Составить план плавной, без ущерба бизнесу, последовательной смены ПО по списку. Например отсутствие метрик, можно использовать как аргумент, объясняющий невозможнлсть решить проблему. Или, например, вдруг обнаружится, что современые аналоги работают только в контейнере. Это конечно учесть.

7. Составить краткую, на 1,5 страницы, выжимку с цифрами и пояснением всего этого безобразия.

8. С выжимкой, списками, суммами ущерба и планом модернизации идти к руководителю. Нет! К его заму или кто-там поближе. Хотя зависит от конторы, конечно.

9. …

10. Profit!?

Я бы начал с уязвимостей в коде. Может быть в процессе исправления выяснится где косяк. Например у нас, в старой системе вебформа производства Oracle отображала многострочные документы каждый раз перерисовывая заново табличную часть, за которой бегала в БД. При 10 пользователях в день и 10 строках вполне работала. При 10000 пользователях и 800 строках уже не работала. Из постов не понятно где сидят разработчики этой системы если в прямой вашей доступности, то почему не подключаются к решению проблемы? Не специалист в perl, но при сегодняшнем уровне средств разработки заниматься рефакторингом кода в самописном монолите, например, на java, очень приятно, если конечно там не xmlками всё управляется.

банк

Ну ожидаемо, да. Десятилетями этот миф ходит, что банки не обновляются, ибо у них мифические сверхнадёжные системы сверхнадёжно написаны на коболе, а если потеряется копейка — рухнет экономика всех стран на континенте, банк засудят, совет директоров расстреляют.

Не знаю, как в США, не взаимодействовал с их процессингом, но в РФ кобола в банках нет, в СНГ нет, в Европе нет.

Со времён ПЦ на коболе еком изменился капитально. Появились посы, айфоны с nfc, списки мошенников и террористов, необходимость в антифроде, интеграция с кучей разного софта, а VISA/MC так и вовсе каждые пол года (или год, если честно не помню) обновления стандартов выкатывают, с обязательным тестированием всех вокруг через пол года на соответствие им.

И банки, что жили тогда и дожили до сего дня, уж точно имели деньги на то, чтобы плавно, но неотвратимо мигрировать с устаревшего стека (и не один даже раз). И для этого не нужно останавливать весь процессинг. Требование об обратной совместимости подразумевается по-умолчанию, как и, в значительной мере, о прямой. Тем, кому такие вещи непонятны просто не место в индустрии. Последнее — не моё субъективное мнение, а реальность, за счёт которой всё это и работает.

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

Когда в очередной раз выдали про непереписываемый кобол в проде, я понадеялся на хоть какой-то пример, кроме очередного обсасывания мифоф и легенд про Банки, Которым Нельзя Терять Деньги. : )

Да, на HN писали где-то месяц назад, или два, что какой-то американский банк успешно переписал legacy код с КОБОЛа на Java.

Со всеми причинами согласен, но где-то всё же КОБОЛ видимо действительно остаётся, пускай и в исчезающе малы количествах.

Для начала спроси где они нашли живого перл-разраба. Ну, если только название компании не начинается на М или Я.

Для начала спроси где они нашли живого перл-разраба.

Как вы думаете на чем проще «писать» проги/скрипты с подсказками так называемого ИИ?

Язык Perl поднялся с 27 на 10 место в рейтинге Tiobe

На пистоне. Страдал на перле три года, такое себе