Стоимость масштабирующихся направляющих по сравнению со стоимостью масштабирования PHP по сравнению с платформами Python
Если Вы хотите оценить порядок своего кода опытным путем, а не путем анализа кода, Вы могли всунуть ряд увеличивания стоимостей n и время Вашего кода. Выведите свои синхронизации на печать на логарифмической шкале. Если код является O (x^n), значения должны упасть на строку наклона n.
Это имеет несколько преимуществ просто изучение кода. С одной стороны, Вы видите, являетесь ли Вы в диапазоне, где время выполнения приближается к своему асимптотическому порядку. Кроме того, можно найти, что некоторый код, что Вы думали, был порядком O (x), действительно порядок O (x^2), например, из-за времени, проведенного в вызовах библиотеки.
2 ответа
Одним из основных факторов здесь является то, что выбор фреймворка не зависит от доступа к базе данных. Независимо от того, какой подход вы выберете, вы, скорее всего, поместите данные в реляционную базу данных. Тогда вопрос в том, насколько эффективно вы можете получить данные из базы данных. Это в первую очередь зависит от СУБД (Oracle vs. Postgres vs. MySQL), а не от структуры, за исключением того, что некоторые библиотеки отображения данных могут неэффективно использовать SQL.
Для чистого параметра «количество посещений» вопрос действительно, насколько быстро работает ваша система шаблонов HTML. Возникает вопрос: сколько страниц вы можете отображать в секунду? Я бы сделал это основным показателем, чтобы определить, насколько хорошо будет масштабироваться система.
Конечно, разные страницы могут иметь разные затраты; для некоторых вы можете использовать кеширование, но не для других. Итак, при измерении масштабируемости разделите свой 1 миллион посещений на дешевые и дорогие страницы и измерьте их отдельно. Вместе они должны дать хорошую оценку нагрузки, которую может принять ваша система (или количества систем, необходимых для удовлетворения спроса).
Также существует проблема использования памяти. Если у вас есть данные в SQL, это не имеет значения, но с кешированием вам также может потребоваться масштабируемость. использование основной памяти.
IMHO Я не думаю, что стоимость масштабирования будет отличаться между этими тремя, потому что ни один из них не имеет «аккумуляторов масштабируемости». Я просто не вижу каких-либо огромных архитектурных различий между этими тремя вариантами, которые могли бы вызвать значительную разницу в масштабировании.
Другими словами, архитектура вашего приложения будет определять масштаб приложения независимо от того, на каком из трех языков.
121] Если вам нужно кэширование памяти, вы, по крайней мере, собираетесь использовать memcached (или что-то подобное, которое будет взаимодействовать со всеми тремя языками). Возможно, вы улучшите масштабируемость, используя nginx для обслуживания непосредственно из кэша памяти, но это, очевидно, не повлияет на производительность php / perl / python / ruby.
Если вы используете MySQL или Postgresql, вы: