Я вот тоже несколько дней назад наткнулся на GT.M и впервые познакомился с такими "удивительными" историями про MUMPS и соответственно продукты на нём. Давно искал, поэтому очень заинтересовался и рассчитываю серьёзно его использовать, но хотелось бы получить напутствие от людей, работавших с ним в реальных условиях.

Я работаю на довольно крупном развлекательном портале, и ищу подходящее решение для аппликационного сервера. Портал вплоть до последнего времени строился без какого-либо планирования и представляет собой множество независимых разработок (php, perl, c, java) разного возраста (начиная с hyperseek образца 96-го) с общей внешностью и завязанных на несколько функционально разделённых mysql баз без репликации. Устанавливалось это всё большей частью до меня, в качестве документации доступны только исходники, и вот теперь стоит задача всё это упорядочить - на живую и параллельно с основной работой по поддержке. Кроме того, в обозримом будущем предстоит сменить хостера, к чему можно было бы приурочить запуск каких-либо "радикальных" новшеств.

Вобщем, будет очень интересно узнать о возможностях и о проблемных местах при использовании GT.M или cache в качестве платформы для нагруженного веб-сервиса - производительность, безопасность, трудоёмкость разработки (с учётом "переквалификации" после perl :), особенности миграции. Судя по всему, cache для этих целей подходит лучше, но GT.M всё же предпочтительнее из-за открытости.
Особенно интересно было бы познакомится с историями конкретных реализаций (задачи, объём работ, запланированные/выдержанные сроки, подводные камни итд.). Желательно без рекламы ;)

Заранее спасибо,
Виктор.

P.S Работаю исключительно с крылатыми/рогатыми осями, преимущественно с первыми.
P.P.S. Разумеется, я в курсе, что для начала не мешало бы набить руку на более простых задачах :)