Узкое место веб-приложений?

Question

Этот вопрос относится к Ruby on Rails и PHP. При поиске VPS-хоста для веб-приложения (еще не определились, на каком из двух языков его писать), что я должен учитывать больше? Память или процессор? Я знаю, что вам нужен справедливый баланс обоих, но с какой стеной я столкнусь первым?

Я уверен, что это зависит от типа работы, которую выполняет приложение, и в моем случае это обычный CRUD. Мое предположение было бы памятью, но я просто хотел бы убедиться.

Answer 1

Я думаю, что СУБД и характер / количество запросов, которые вы будете делать, будут здесь самым важным фактором, а не чем-либо, касающимся используемого языка. (Предполагается, что база данных работает на том же сервере)

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

Кроме того, вы на самом деле не указали, какие комбинации предлагаются, поэтому сложно дать ответ.

Answer 2

На самом деле, по моему опыту, первое узкое место, с которым я столкнулся при работе веб-сервера на VPS, было пропускной способностью. Либо насыщение фактической пропускной способности, либо исчерпание разрешенных открытых сокетов / соединений на VPS. С первым вы ничего не сможете сделать, если ваш хост не позволит вам купить больше пропускной способности, но последний, по крайней мере, обычно может быть изменен хостинговой компанией. После пропускной способности память стала следующим пределом, который я достиг, в основном из-за запуска SpamAssassin в то же время, что и MySQL, Apache и т.д.

Если вы еще не выбрали хостинговую компанию, я могу порекомендовать Tektonic . Цены не могут быть побеждены, и если у вас есть планы среднего или более высокого уровня, они имеют приличное количество оперативной памяти и процессора. Пропускная способность не измеряется, вместо этого вы ограничены фактической пропускной способностью, поэтому, если вам не хватает пропускной способности, вам, вероятно, придется платить за дополнительную пропускную способность, как с любым хостом.

Answer 3

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

Answer 4

Больше памяти, позволяя MySQL использовать ее для кеша, даст вам большие улучшения производительности. Смешайте это с хорошим дизайном БД, избегайте создания больших дорогих массивов объектов, и вы должны столкнуться с любыми проблемами с ЦП ... Ну, если вы не выполняете сильные агрегации ЦП или некоторую сложную логику.

Answer 5

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

Answer 6

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

Answer 7

Я столкнулся с проблемами с памятью задолго до проблем с процессором, но я запускал сервер SQL на том же VPS, что и веб-интерфейс. Были некоторые серьезные проблемы с памятью, пока я не заплатил за обновление.