У мегафона на мобильники тоже выдаются "не серые адреса". Но по факту эти адреса за натом и постучаться снаружи на них нельзя.
Понятие "серый" адрес - не о диапазоне, в который он входит, а о том, доступен ли он напрямую снаружи или нет.
При том я видел очень хитрый NAT, когда "серый" адрес на интерфейсе совпадал с публичным адресом, что совсем жесть)
Очень уж маловероятно, что приложение за 60 секунд (дефотлное значение) не сможет сказать "ага, я тут, давай заголовки". И "скрипт работает дольше" в данном случае не должно касаться этого таймаута - в fpm скрипт не должен начинать работать до того, как установится соединение (и connect_timeout станет неактуален).
Так что в данном случае не время работы скрипты было бы виновато, а загруженность всех тредов php настолько, что за 60 секунд никто из них не смог ответить вебсерверу открытием коннекта.
Вы же в курсе, что это всё про NAT, да?) Судя по "на коло" человеку не нужно никуда форвардить трафик в другую сеть - ip rule будет в стотыщмильёнов раз быстрее. И conntrack включать не нужно будет, который все забывают тюнить.
То что вы сейчас не упираетесь в диски — ровным счетом ничего не значит. Процессор сможет работать шустрее, вся конструкция под максимальной нагрузкой сможет больше писать/читать с диска, в итоге диск станет узким местом. Если вы не достигнете предела его IO — прекрасно. Достигнете — процессор будет свободным.
И да, SAS — не панацея, они тоже не такие быстрые, как хотелось бы. Ну если у вас их там не 6-8 штук в 10-ке, конечно.
А то, что у вас сейчас тормозят диски, я не упоминал ;)
Та нас-рать =)
Все перечисленные процессоры быстрее упрутся на типовых задачах в дисковую подсистему (если не разоряться на ssd/sas). 5620-ки и 5645-ки точно.
Понятное дело, что можно абсолютно всё держать в памяти — но это как раз из области «если разоряться».
Ну и тут явно не сложная математика будет.
Я могу написать часть, которая выполняется в системе. Но эту часть как-то нужно дергать из вашего приложения. В принципе там должен получиться один скрипт, который на stdout выплюнет урл до VNC, а в веб-приложении нужно будет запустить vnc-плеер до этого урла. Вот только со стороны веб-морды я и такого реализовать не смогу, разве что на sh-cgi. Ну и с настройкой vnc-вьювера помучаться придется, наверное — тот же guacamole без мата не настроишь (а это ещё и авторизация какая-либо «другая» понабится).
Так-то там всё до смешного просто — создаём LVM-том с эталонным образом, перед созданием машины делаем снапшот (или быстренько клонируем эталонный том, если диски хочется пошустрее работающими видеть), создаём машинку. Начинаем мониторить vnc-соединение, как пропадает — начинаем отсчитывать полчаса. Появляется — перестаём мониторить. Проходит полчаса — удаляем.
Сложности тут в том, что надо как-то научиться запускать пользователей в VNC. Точнее даже не в этом (софт-то в целом есть), а в том, что понадобится система авторизации к VNC (ну или пользователям нужно будет ручками вводить логин и пароль при входе, который известен только им).
Ну и в качестве совсем уж быстрого и грязного решения — посылать пользователей поставить плагин вроде этого, выдавая нужные учетные данные.
Вот. Со стороны настройки системы — у меня-то проблем как раз не будет. А вот со стороны сайта — от меня толку ноль.