NeuroPastor, nfs отличается от sshfs поддержкой в ядре и отсутствием шифрования. Плюс создавалось оно как раз для таких целей как у вас. Так что все правильно.
andrei_pro, возможно в апи есть статика, которую можно эффективно кэшировать. Но это все от лукавого - основной момент нагрузки, это установка соединения. Стабильные накладные расходы клиент-серверного взаимодействия постороенного по схеме запрос-ответ.
пассаж интересный - лаги на других серверах, а виноват нгинкс. Но нгинку явно тесно - в таких условиях я бы рекомендовал расширяться по достижению 75% нагрузки на цпу в среднем.
При желании можно и тут поколдовать - логи там выключить, гзип отключить, но вангую что 99% нагрузки это https и лучшее что тут можно проверить - кэширование статики на стороне клиента.
Начнем с нулевого варинта. Это самая плохая идея, которая тут может быть - увеличить размер спринта. Не стоит этого делать, поскольку это принесет больше проблем, чем решит. Вплоть до того, что через некоторое время окажется, что задачи не влезают и в расширенный спринт.
Вариант первый, самый простой, осознанно смотрим проблеме в лицо - явно говорим на планировании, что да, история большая, кросфункциональная, мы ее оцениваем как Х, а практика показывает, что истории больше У не продят в спринт, значит эта история займет этот спринт, часть следующего и будет готова только через два спринта. Если заказчику/ПО это ок и такие штуки не особо часты, можно не делать из этого трагедию. Если такое часто происходит - лучше посмотреть другие варианты.
Вариант второй, использующий инженерные практики - явно говорим команде, мол вы профессионалы или кто? Зачем вам друг друга ждать? Используйте контрактное программирование, парное программирование, экстремальное программирование ну или просто договоритесь как это все будет работать и приступайте к работе одновременно, итеративно внутри истории добавляя весь функционал и графику сразу же как только оно будет готово. Звучит как магия, но на практике вполне достижимо и работает в соответствии с духом agile/scrum. Чтобы попробовать такой вариант, достаточно просто не брать в спринт ничего кроме этой задачи и дать понять разработчикам, что от них ожидается еще до начала спринта, чтобы было время свыкнуться с мыслью. С третьего раза даже начнет получаться.
Вариант третий, призываем силу декомпозиции - лучшее из того, что может сделать менеджер в подобной (да и вообще в любой) ситуации - декомпозировать. В случае с пользовательскими историями должны помочь шаблоны декомпозиции пользовательских историй - ниже перевод статей про модель INVEST с красивой схемой, которую можно держать как шпаргалку на столе:
- https://scrumtrek.ru/blog/right-sizing-features-sa...
- www.agileukraine.org/2014/05/patterns-for-splittin...
Хочу порекомендовать перенести эту проблему на уровень деплоя - в поддержке проще иметь по инстансу на каждый автопарк, чем жонглировать базами данных в едином приложении.
Максим Федоров реализовывать что-то - это последнее, что я хочу делать. Написать первую версию несложно, но ее же надо еще и поддерживать. Хочется взять готовый инструмент и начать его использовать.
Мне нужно, чтобы эту виртуалку не приходилось пересоздавать раз в полгода, поскольку она начинает есть ресурсы. Плюс не хочется, чтобы на ней жили какие-нибудь трояны, поскольку с этой машинки возможен доступ в защищенную сеть.
В идеале бы туда поставить линух какой бы, но к сожалению, требуется именно венда.
ну ок, соглашусь, в описанном случае можно использовать. Я почему-то подумал, что уровни вложенности не ограничены и вытаскивать значения надо из всех вложенных массивов.
Если придираться к словам - OpenVZ это как раз не виртуализация, а контейнеризация. Как и докер.
Но контейнеризация внутри контейнеризации, хоть и звучит как масло масленное, однако тоже вполне допустимо.
Все же не советую. Это штука сильно специфична для клиентского js - там это вполне разумно выглядит для отделения моделей от отображения - многие изменения в объектах моделей должны быть перемещены в объекты DOM с необходимым форматированием. А зачастую даже и изменения из DOM должны попасть в модели.
В PHP такой подход тоже возможен, но отображение как правило - это не объект, а текст в конечном счете. Поэтому проще использовать последовательное преобразование моделей в представление форматируя их прямо в шаблоне, для чего вполне подходят разнообразные шаблонизаторы.
Кирилл Горелов: public function getContentPage() { return file_get_contents <- вот оно. Подключаемый файл отправляется в браузер как есть. Вместо его вывода, его стоит подключать через Include, если хочется, чтобы оно было обработано как phpшный файлик.
Тогда не то, да. Возможно этот файл не обрабатывается как пхпшный или вместо его подключения он просто выводится - стоит проверить его расширение или настройки вебстервера и способ, как он включается в страницу.
