Масштабируемость в сети

Ruby и PHP не являются платформами веб-приложения. Они - языки программирования, которые популярны для веб-разработки.

Вообще говоря, масштабируемость веб-приложения не является свойством языка программирования, и данная платформа веб-приложения не может самое большее препятствовать масштабируемости. Хорошая масштабируемость является больше свойством проектирования приложений.

Существует слишком много платформ веб-приложения там для детального сравнения, которое является чем-либо за исключением энциклопедического.

Кроме того, можно заняться масштабируемостью для данного приложения несколькими способами. Один путь состоит в том, чтобы иметь четко определенный и узкий объем и нацелить потрясающую необработанную производительность, таким образом, единственная машина может служить огромному количеству единиц работы. Лучшим примером вокруг является Mailinator.

Иначе должен помочь служить увеличивающимся загрузкам, "просто" добавив больше аппаратных средств. В значительной степени любая поддержанная базой данных платформа веб-приложения может масштабировать этот путь: просто добавьте больше серверов приложений между подсистемой балансировки нагрузки и общим бэкендом базы данных. При структурировании проблемы этот путь основное беспокойство разрабатывает приложение для уменьшения 1. конкуренция 2 базы данных. загрузка базы данных.

Последним путем является дизайн система для безумной параллели полностью. Причем Google является главным примером.

Таким образом: языки или платформы не подают масштабируемые заявки, архитекторы программного обеспечения делают.

Править: Чтобы быть ясным, мой ответ фокусируется на масштабируемости, которая является способностью обработать увеличивающиеся загрузки, не изменяя дизайн. Это - другое свойство, чем скорость выполнения.

Алгоритмы рассчитают больше для масштабируемости, чем язык используемый.

Тем не менее будут различия в скорости выполнения между языками. Я полагаю, что Java (Сервлеты и JSPs компилируют в сервлеты, т.е. собственный код) будет быстрее, чем Ruby и PHP некоторой суммой). Существует также тонна веб-платформ для Java, который поощрит Вас делать вещи лучший способ для масштабируемости.

Также разработайте свое приложение так, чтобы оно могло работать счастливо позади подсистемы балансировки нагрузки, и масштабируемость становится намного легче :) Это не мое поле экспертных знаний как бы то ни было.

Веб-масштабируемость платформы - что-то вроде по вопросу для размышления (некоторые сказали бы что конкурс p155ing). Если Вы не получаете мега маркеры (удача с этим в эти дни) и можете гарантировать миллионам посетителей в день, все те платформы могут обработать ее хорошо (как может ASP.NET).

Лично я всегда выбирал бы ASP.NET. Это так же масштабируемо как что-либо и имеет лучшие инструменты разработчика. Единственный недостаток размещает и затраты операционной системы.

Можно ли также смотреть на, "Что быстрее? PHP по сравнению с ASP по сравнению с JSP по сравнению с CGI и т.д."

Я думаю Java/Java, который EE является единственной "платформой", разработанной с нуля для разработки распределенный/кластерные приложения, и это поощряет хорошие методы достигать его от спецификаций (EJB, JTA...).

Но как обычно, это зависит. Этот вид вопросов часто склоняется к войнам пламени :)

Несколько положительных сторон уже. Мой основной момент был бы этим: человек, который знает Python от и до, вероятно, сможет сделать больше масштабируемого кода с помощью Python, чем использование Java. И существует много в широком масштабе больших сайтов, которые используют все технологии, которые Вы упоминаете, таким образом, я не думаю, что так или иначе существует действительно любое большое преимущество.

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

Я не уверен ни одна из тех платформ, которые Вы упоминаете, серьезно препятствует масштабируемости.

Все это зависит от реализации.

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

Скомпилированный язык будет обычно работать быстрее, чем интерпретируемый язык, таким образом, я буду думать, Ruby и PHP запускаются позади восьми шаров, но Он действительно сводится, как Вы используете язык и как Вы структурируете код.

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

A: C ISAPI dll (или пользовательский апачский модуль) :)

Даже затем издержки веб-сервера, анализируя запросы HTTP и служа страницам HTML делают время выполнения Ваших приложений почти не важным. Если Вы запускаете свое приложение как приложение CGI, то ожидаете еще меньше производительности.

Для масштабируемости в сети Вы действительно говорите о добавлении большего количества серверов и выравнивания нагрузки, беря загрузку от сервера путем помещения базы данных (если в большой степени используется) на отдельном сервере.

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

Если Вы хотите знать, как крупнейшие сайты используют ЛАМПУ для достижения масштабируемости, необходимо смотреть на базу данных sharding.

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