Производительность и масштабируемость php-кода для спагетти по сравнению с mvc / oop?

Question

У меня есть php-приложение, содержащее около 50-55 кодовых файлов.Файл с максимальным объемом кода содержит около 1200 строк кода (включая пробелы, табуляции и несколько разрывов строк ...), а остальные файлы кода относительно меньше.

Приложениекод почти в каждом файле представляет собой смесь html, sql и php (то, что вы называете спагетти), за исключением нескольких файлов, которые являются чистыми включаемыми файлами php .... например, файл, содержащий функции, которые необходимы во многих других местах.

Я думал о том, стоит ли реорганизовать это приложение в архитектуру типа mvc.

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

Я предполагаю, что, поскольку это небольшое приложение (я так полагаю, как вы думаете, оно достаточно маленькое?), я неПредставьте себе трудные времена с обслуживанием или добавлением еще нескольких функций (максимум), которые могут простоМожно добавить несколько дополнений в существующие файлы или, скажем, добавить максимум 5-10 новых файлов.

Так что я думаю, что не стоит переходить на mvc только для обслуживания.

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

Я думаю, что даже в небольшом приложении для спагетти мы не можем иметьразличные серверы для HTML, базы данных и т. д. мы можем легко масштабировать без снижения производительности, располагая балансировщиком нагрузки перед веб-серверами, сервером данных и т. д. (Предположим, что возникает ситуация, когда одного сервера недостаточно)

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

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

Пожалуйста, не говорите мне, что рефакторинг будет полезен в будущем (я знаю, что это поможет и рассмотрит, действительно ли нам нужно добавитьнамного больше кода к существующей кодовой базе), но, пожалуйста, дайте мне четкий ответ на

1) Действительно ли мне нужно преобразовать это приложение в архитектуру mvc для масштабируемости и производительности?

2) Может ли приложение для спагетти, такое как эта шкала, выполнять как минимум 1 миллион запросов в день, половина из которых происходит в какое-то пиковое время?

Answer 1

Насколько я понимаю, вы можете поместить каждый компонент mvc на отдельный сервер, чтобы распределить нагрузку

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

Основная причина, по которой вы, вероятно, перейдете в MVC (как вы уже упоминали), заключается в преимуществах управления кодом: разделение задач, повторное использование и т. Д .;не производительность.

Теоретически вы могли бы сделать это с помощью технологий, основанных на объектах / компонентах, таких как Java или .Net, где компоненты взаимодействуют друг с другом, но в процедурном коде?я так не думаю!

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

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

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

2) Может ли приложение для спагетти, подобное этой шкале, выполнять как минимум 1 миллион запросов в день, половина из которых происходит в течение некоторого пикового времени?

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

Answer 2

Нет, вам не нужно конвертировать, потому что с бесконечным бюджетом любое приложение будет масштабироваться бесконечно. Просто добавьте больше серверов. Вопрос в том, есть ли у вас бесконечный бюджет? Если у вас нет неограниченного бюджета, узнайте, что дешевле: добавьте больше оборудования или оптимизируйте код.

Так что настоящий ответ: возможно.

Мы не можем сказать вам, что требуется вашему приложению для достижения ваших целей масштабируемости. Мы не знаем, что он делает, и вы не предоставляете жесткие ограничения для желаемой производительности. Например, сколько времени может занять запрос, пока он не будет обработан? Запустите ab или Siege и измерьте свой статус-кво. Запустите профилировщик своего кода и определите узкие места. Выясните, связаны ли вы с IO, CPU или RAM. Вы используете кэш Opcode? Возьмите все свои выводы и сделайте обоснованное предположение о стоимости. Затем решите, как оптимизировать.

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

Обратите внимание, что рефакторинг большого шарика грязи в нетронутое ООП-приложение не обязательно означает, что впоследствии он будет работать быстрее. На самом деле, чем слабее связаны, чем больше косвенность, тем больше слоев, тем медленнее будет приложение. Это компромисс для лучшей ремонтопригодности. Ремонтопригодность также позволяет сэкономить. Это сэкономит ваше время на доставку новых функций.

Answer 3

1. Да
2. Нет

50 + файлы не маленькие.Спагетти-код является не поддерживаемым и крайне неэффективным, поэтому нет никакого преимущества в производительности по сравнению с надлежащей структурой.Наконец, хорошая инфраструктура предлагает хорошо спроектированные, хорошо протестированные и постоянно обновляемые плагины для решения самых распространенных задач, сокращая объем кода, который вам приходится писать и обслуживать самостоятельно.сайты были запутаны путаницы спагетти-кода.Сегодня вы даже не должны думать о том, чтобы запускать сайт с большим трафиком (или любой другой сайт!) В коде спагетти.