Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Возможная производительность  [new]
jaze
Member

Откуда:
Сообщений: 4
Есть приложение, основной поток работает по схеме - select, обработка, update.(по 1 записи на запрос). Таблица одна, 2-3 поля, вряд ли перевалит за 5000 записей. Запросы в плане будут поступать от 3-4 тысяч пользователей с интервалом в 2-3 сек. для одного пользователя.
На данный момент до этих чисел далеко, но даже без учета обращений к базе, сам обсчет данных занимает немало времени, посему скорее всего система переедет с одиночной машины на кластер.
Вопрос. Ориентируясь на данные цифры стоит ли думать о распределении базы по кластеру или же хватит 1 быстрой машины, выделенной чисто под базу? На данный момент это 4core * 3Ghz, 4096 RAM.
20 июн 09, 14:54    [7324173]     Ответить | Цитировать Сообщить модератору
 Re: Возможная производительность  [new]
Glory
Member

Откуда:
Сообщений: 104760
У MSSQL нет load balancing кластеров. Только failover
20 июн 09, 14:58    [7324187]     Ответить | Цитировать Сообщить модератору
 Re: Возможная производительность  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
jaze,

А зачем здесь вообще СУБД?
20 июн 09, 14:58    [7324189]     Ответить | Цитировать Сообщить модератору
 Re: Возможная производительность  [new]
jaze
Member

Откуда:
Сообщений: 4
Glory
У MSSQL нет load balancing кластеров. Только failover

Неожиданно.. Но все же интересен хотя бы порядок требований к мощностям при такой нагрузке.
Senya_L
jaze,

А зачем здесь вообще СУБД?

Что значит зачем?) Это основной поток, кроме него есть еще очень много всего, нужного для функционала, но практически не отягощающего.
20 июн 09, 15:13    [7324225]     Ответить | Цитировать Сообщить модератору
 Re: Возможная производительность  [new]
Glamorama
Member

Откуда:
Сообщений: 152
дак Вы сейчас попробуйте сымитировать некое подобие ожидаемой нагрузки и узнаете ответ на свой вопрос. Завалите сервер тестовыми запросами из одной сессии в режиме нонстоп на полчасика, хотя бы узнаете какого быстродействия можно ждать от текущего железа.

По приведенным данным совершенно непонятно чё к чему - 1) какие операции включаются в транзакцию; 2) будут ли пользователи ломиться на прямую в базу или через приложение; 3) связаны ли между собой обращения разных пользователей; 4) что за селекты, обработка и апдейты, насколько они ресурсоемки сами по себе, ведь малый размер таблицы на гарантирует высокого быстродействия; 5) и ещё мильон разных вопросов....
21 июн 09, 00:49    [7325076]     Ответить | Цитировать Сообщить модератору
 Re: Возможная производительность  [new]
flexgen
Member

Откуда: Город на песке
Сообщений: 765
jaze
Есть приложение, основной поток работает по схеме - select, обработка, update.(по 1 записи на запрос). Таблица одна, 2-3 поля, вряд ли перевалит за 5000 записей.

То есть и select и update будут работать по одной и той же таблице? Почему бы не выполнять update с правильно прописанным where?

автор
Запросы в плане будут поступать от 3-4 тысяч пользователей с интервалом в 2-3 сек. для одного пользователя.
Где гарантия что интервал будет соблюдаться?

автор

На данный момент до этих чисел далеко, но даже без учета обращений к базе, сам обсчет данных занимает немало времени
То есть еще не выйдя на production нагрузку производительность уже низкая.
21 июн 09, 01:40    [7325133]     Ответить | Цитировать Сообщить модератору
 Re: Возможная производительность  [new]
aleks2
Guest
jaze
Таблица одна, 2-3 поля, вряд ли перевалит за 5000 записей. ...
без учета обращений к базе, сам обсчет данных занимает немало времени, посему скорее всего система переедет с одиночной машины на кластер.

Интересуюся, шо такое можно считать на 5000 записей ДОЛГО?
21 июн 09, 17:09    [7325632]     Ответить | Цитировать Сообщить модератору
 Re: Возможная производительность  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
aleks2
jaze
Таблица одна, 2-3 поля, вряд ли перевалит за 5000 записей. ...
без учета обращений к базе, сам обсчет данных занимает немало времени, посему скорее всего система переедет с одиночной машины на кластер.

Интересуюся, шо такое можно считать на 5000 записей ДОЛГО?
Вот и меня заинтересовало. Не проще ли сделать собственный сервис типа TCP-сервера и хранить эти несчастные 5000 строк в памяти. Ручками делать побольше, так и работать будет шустрее.
22 июн 09, 00:01    [7326045]     Ответить | Цитировать Сообщить модератору
 Re: Возможная производительность  [new]
iljy
Guest
jaze
Есть приложение, основной поток работает по схеме - select, обработка, update.(по 1 записи на запрос). Таблица одна, 2-3 поля, вряд ли перевалит за 5000 записей. Запросы в плане будут поступать от 3-4 тысяч пользователей с интервалом в 2-3 сек. для одного пользователя.


У вас получается, что в секунду должно обрабатываться около 1-2 тысяч запросов, и все они - по одной записи. Вообще схема мягко говоря неоптимальная, т.к. каждый запрос подразумевает update, т.е. транзакцию, и то, что в таблице 5000 записей - явно не спасет, думаю операции собственно с таблицей занимают минимум времени. Вы не думали на тему оптимизировать работу с сервером, хотя бы группировать изменения? Ну или правда придется делать собственный сервис для хранения и выборки этих 5000 строк.
22 июн 09, 00:13    [7326056]     Ответить | Цитировать Сообщить модератору
 Re: Возможная производительность  [new]
jaze
Member

Откуда:
Сообщений: 4
Если подробней - все действительно по 1 записи - она достается select'ом по id, далее обработка - довольно нагруженная математика(на нее будет кластер) - update. В минувшие выходные провел тесты - в секунду дай бог 500 select'ов с 1м update'ом на все. Видимо, действительно придется класть все в память и синхронихироваться с базой отдельно.
22 июн 09, 11:34    [7327042]     Ответить | Цитировать Сообщить модератору
 Re: Возможная производительность  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31200
jaze
Вопрос. Ориентируясь на данные цифры стоит ли думать о распределении базы по кластеру или же хватит 1 быстрой машины, выделенной чисто под базу? На данный момент это 4core * 3Ghz, 4096 RAM.
Конечно хватит одной машины, если у вас сама обработка на других серверах..
22 июн 09, 11:38    [7327082]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить