LINUX.ORG.RU

Сервер для мобильного приложения

 , ,


1

1

Привет!

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

Условно на сервере apache + php + mysql

Каковы технические характеристики сервера по количеству запросов в секунду для какой либо конфигурации сервера?

Например: 1 Гб памяти 1 Ггц проц Диск, опять же условно, hdd

Сколько может запросов в секунду обработать сервер?

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

Сколько может запросов в секунду обработать сервер?

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

Ghostwolf ★★★ ()
Ответ на: комментарий от Ghostwolf

Само собой :-)

Приходилось ли поднимать/покупать/арендовать сервер по результатам установки которого ты мог сказать: Ага! Для комфортного взаимодействия 1000 пользователей с сервером (пускай время от получения запроса сервером до его ответа пользователю проходит до 5 секунд максимум) такой то и такой то конфигурации сервера достаточно, или наоборот недостаточно

Correctnoe_imya_polzovatelya ★★★★★ ()

Apache benchmark в зубы и тестировать В 2006 год на селерон-D 250Mb связка debian 5 apache1 + php + mysql

php только запрос к базе, xml не использовался.

Не самый простой запрос к базе несколько таблиц (самая большая 10к записей)

При тестировании одновременно с 600 устройств посылалось (5 запросов с устройства)

Узким местом оказалась сотовая связь.

В городе Москва падали билайн и мегафон, не смотря что устройства были распределены по городу. (MTC устоял из-за отсутствия у нас его симок)

Был доволен как слон поэтому, определить мах нагрузку на сервер не удалось, с Apache benchmark тогда знаком не был.

Назвать тестированием по сегодняшним меркам не могу. (разве что тест всей системы в целом)

Плюс сейчас с развитем человечества, нужно смотреть на нежелательный трафик

s-warus ()

От веб-сервера тут мало что зависит. Вопрос скорее в том, как твой код на стороне сервера будет отрабатывать эти запросы.

dimss ★★★★★ ()
Ответ на: комментарий от dimss

Да обычно узкое место это MySQL

Даже по тем временам база очень маленькая 10000 записей + одна таблица 600 записей другая плюс не сколько мелких не более 10 записей весь отбор по целочисленным ключам.

Для той конфигурации подозреваю 0.01s достаточно даже если размеры базы увеличить в x100

На той машине гонял полнотекстовый поиск по базе Архангельской областной библиотеки. отбор по словам +биограф* +пушкин* вроде 0.001s укладывался, не уверен, но меньше 0.1 точно

s-warus ()

Тут ничего сказать нельзя.

Есть у тебя там простой GET, который делает один select и выплёвывет одну запись, то на любой кофеварке будет обрабатываться over9000 запросов в секунду. А если у тебя там select с кучей join'ов на неиндексированной базе и всё это приправленно хитроумной логикой на php, оно и от одного запроса на суперкомпьютере по таймауту отвалиться может.

shell-script ★★★★★ ()
Ответ на: комментарий от shell-script

+100 на неиндексированной базе (хотя бы лечится)

+10000000000000 приправленно хитроумной логикой на php (тут лечение не поможет только убийство с последующим перерождением)

хотя может и так сойдёт если проект не требует роста

s-warus ()