Проектирование нагрузки на веб-сервер

[ADSoft]

Всем привет, освоим новый раздел))))

Итак, в чем стоит вопрос:
Имеется диспетчерская служба такси реализованная на php+MySQL, клиенты - приложения для Андроида, которые так-же коннектятся к серверу чрез api реализованное на php

На данный момент имеем нагрузку следующего типа......
Клиенты (Андроиды), порядка 150-200 шт, запрашивают каждые 20 сек список доступных заказов (порядка 20-30 заказов), тут же отдают гпс координаты, кроме того отправляют свои данные какие то ... взятие заказа, отмена, инфа диспетчеру, вне расписания этих 20 сек.. .

Диспетчерская (5-10 дисп одновременно): веб-интерфейс, аяксовое обновление списка заказов - 50-60 заказов

+ служебные расходы, в кроне ежеминутно работает скрипт рассылки СМС (от 5 до 50 смс в мин)


Все это крутится на VDS (Диск 40.0 ГБ, Процессор 4x2000МГц, Память 4096МБ )

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

типа - для данного сервака у вас максимум будет - вот такое кол-во.... и почему.... что можно сделать кроме увеличения производительности железа.. .может на программном уровне что можно сделать?

[Utkin]

Ну а сам сервер-то какой? Название-то Вы не даете. Вот уже по нему смотрите параметры, да и все.

.может на программном уровне что можно сделать?

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

[Stilet]

когда ждать наступления перегрузки

Я не думаю что перегрузку при таких условиях стоит ждать.

может на программном уровне что можно сделать?

поиграться с кэшем мускула...

[ADSoft]

я названия не знаю..... крутится в reg.ru в аренде
... мне просто необходимо понять алгоритм расчета нагрузки....
ну например - 1 клиент - N Мб памяти, 1 диспетчер - M Мб, может еще какие-то параметры... ну там по Процу.... недавно была ситуация просто - в запрос добавил один доп join и все легло..... типа нагрузка по БД возросла.... возможно мой косяк ....ибо объединение по строке номер телефона было... оно строковое и неиндексируемое

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

а сегментирование юзеров - по сути не спасет, если макс возможные ресурсы потратятся

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

[Utkin]

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

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

[ADSoft]

адекватно отвечали бы- не спрашивал тут

[come-on]

Клиенты (Андроиды), порядка 150-200 шт, запрашивают каждые 20 сек список доступных заказов (порядка 20-30 заказов)

может на программном уровне что можно сделать?

убрать запросы, на сокетах реализовать

[Stilet]

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

А как можно рассчитать то, что в динамике постоянно? Плановая нагрузка исчисляется исходя из тестов. Крутится (как мы это делали с админами) самый тяжелый запрос, им сожраные ресурсы умножаются на кол-во пользователей, и берется средний показатель после того, как пользователи провели бета-тесты.
Более того сожранные СУБД ресурсы могут использоваться повторно, а не возвращаться в систему. Если я запросил гиг - память выделилась на гиг, потом ты запросил сто метров - выделенная под гиг память обработала эти сто метров без запроса нового места. Поэтому я бы дал некий период юзерам поработать, а уже по его результатам и судил бы что лучше сделать для оптимизации. Может БД, может памяти увеличить или кластеры поставить.

убрать запросы, на сокетах реализовать

А что обращение к СУБД по сети не на сокетах что ли?

[ADSoft]

не, не на сокетах, по сути REST ... запрос - ответ

[come-on]

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