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

[Stilet]

Про субд ничего сказано не было

А это?:

диспетчерская служба такси реализованная на php+MySQL

Или мускул уже перестал быть СУБД?
Или я чего-то недопонял?

[ADSoft]

специально ничего не делал, а само вряд ли создалось.... про кэш -имеете ввиду memcache ?

[come-on]

А это?

напиши тут что угодно как оно расскажет как с ним работа идет?

про кэш -имеете ввиду memcache ?

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

[Stilet]

напиши тут что угодно как оно расскажет как с ним работа идет?

Супер просто... У меня даже слов нет О_о.

[ADSoft]

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

2 Stilet - в чем преимущество сокетов? Я что-то смотрел думал и не нашел...... деражать открытыми постоянно 300 сокетов думаете не накладно? А если завис демон, какой то код - которые его перезапустит итд

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

[Stilet]

я не совем уверен что иногда дело только в БД

Попробуй справочники вынести в MEMORY-объект. Это увеличит скорость. Мы так на Оракле only-read таблицы ставили, чтоб ЖД не дергало постоянно.
http://www.jeo.ru/mysql-harakteristi...mory-heap.html

Есть кто нибудь тут кто делал реально высоконагруженные проекты?

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

[Utkin]

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

Ответить за них мы тоже вряд ли сможем.

[Gorychev]

Описанные нагрузки - совсем не нагрузки Раз в 20 сек список из 30-заказов это совсем ничего..
Но все же можно сделать быстрее
1. Понять какие запросы наиболее грузят систему
2. Проанализировать - добавить индексы там где нужно. (Думаю вы это уже сделали)
3. Денормализация структуры таблиц, чтобы уменьшить надобность в join. Еще, как по мне лучше насколько простых запросов, чем один сложный
4. Можно хранить всегда актуальный список заказов в мемкеш и базе одновременно. Добавился заказ - добавили в базу и мемкеш. Заказ выполнили/отменили - в бд изменили статус, удалили из мемкеш. Соответственно отдавать мемкеш-копию заказов

Железо у вас скромненькое, есть куда вертикально масштабировать.

[ADSoft]

Спасибо всем за советы...
Сопутствующий вопрос - какие есть средства мониторинга нагрузки Мускула... ну например чтобы лог какой-то велся с указанием запросы и времени выполнения?

[Stilet]

деражать открытыми постоянно 300 сокетов думаете не накладно?

А в чем там накладка?

какие есть средства мониторинга нагрузки Мускула

http://www.mysql.com/products/enterprise/monitor.html