частые обращения к базе

[aaa3d]

поделитесь опытом...
заинтересовал след. вопрпос - сколько простейших обращений к базе можно реализовать на FB (1.5.2, Athlon 2500+)

строю цикл вида:
query - "SELECT shop_id from SHOP" -- SHOP - таблица с 1 записью

transaction.begintransaction;
while (not Stop)
begin
IBQuery.Open();
IBQUery.Close;
inc(cnt);
end
transaction.commit;

при написании в DELPHI+IbExpress - примерно 900 раз в секунду

на MFC (через ODBC драйвер FB) - около 400.

пробовал на IBPP - точно не подсчитал, но вроде на уровне 200-400 запросов в секунду
в обоих случаях распределение процессора 50% FB, 50% - прога
чтений-записи диска не наблюдается

это реальные результаты? или все таки есть способы делать такую работу раз в 10 быстрее

[kdv]

а зачем быстрее? во-первых, тачка у тебя худая, а во-вторых, может, тебе трехзвенка нужна?

[aaa3d]

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

перенес что смог в ХП - но их тоже приходится вызывать
щас на на каждую строку обновления происходит 2-3 запроса к базе -
- с учетом того что запросы делаются не напрямую на сервере а на клиентской машине по сети к серверу - время обработки минуты а то и десятки минут)
то что я вижу по ускорению:
сократить количество запросов к базе
ускорить как-то выполнение этих запросов (кэширование метаданных или что там еще ), перенести синхронизацию на сервер)

а вопрос все таки - на локальной машине по TCP это максимальные цифры или используя, например, чистый IB API можно заметно ускориться)

трехзвенка тут вроде не при чем

[Ivan_Pisarevsky]

с учетом того что запросы делаются не напрямую на сервере а на клиентской машине по сети к серверу - время обработки минуты а то и десятки минут)

Фетчится такое кол-во данных, что ложится сетка? Надо же... но уж больно на бред похоже...

[aaa3d]

ладно, поставлю вопрос по другому
в известных Вам репликаторах какая скорость репликации считается нормой? (имею в виду строк в секунду)

у меня сейчас порядка 100-200

[Ivan_Pisarevsky]

ладно, поставлю вопрос по другому
в известных Вам репликаторах какая скорость репликации считается нормой? (имею в виду строк в секунду)
у меня сейчас порядка 100-200

Тебе нужна средняя температура по больнице?

щас на на каждую строку обновления происходит 2-3 запроса к базе -

Если тормоза в запросе, так приведи метаданные, план, время исполнения... и тд.

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

[aaa3d]

в своем первом посте я привел схему, которая выполняется у меня самое длительное время - элементарный запрос:
сейчас проверил еще раз :
по TCP к локальной машине - порядка 900 запросов в секунду
по TCP к удаленной машине (локалка 100мбит) - 200 запросов в секунду (при этом загрузка проца: там где прога - 10%, там где сервер - 0%)

подробнее :

Код: Выделить всё

procedure TForm1.Button1Click(Sender: TObject);
begin
  button2.tag:=0;
  ibquery1.SQL.Text := 'select shop_id  from main';
  ibtransaction1.StartTransaction;
  while button2.tag=0 do
  begin
    ibquery1.Open;
    ibquery1.Close;
    cnt:=cnt+1;
    if cnt mod 10 = 0 then
        application.ProcessMessages;
  end;
  ibtransaction1.Commit;
end;

procedure TForm1.Timer1Timer(Sender: TObject);
begin
  Edit1.Text:=inttostr(cnt);
  cnt:=0;
end;

procedure TForm1.Button2Click(Sender: TObject);
begin
  button2.tag:=1;
end;

вопрос то блин простой - неужели нельзя делать запросы к базе быстрее?

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

[Dimitry Sibiryakov]

ладно, поставлю вопрос по другому
в известных Вам репликаторах какая скорость репликации считается нормой? (имею в виду строк в секунду) у меня сейчас порядка 100-200

У меня на тестовых данных (табличка 5-6 полей) IBP Replicator работал почти на порядок быстрее. Так что правильное применение API - rulezzz.

[kdv]

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

[aaa3d]

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

репликация построчная - соответственно требует проверок:
запись не была удалена
пришедшая запись новая или для обновления
если для обновления, то проверить, что пришедшая запись новее

итого несколько запросов до выполнения операции обновления/вставки

я тут еще поэксперементировал и вот что нарыл еще:
ограничения на скорость накладывает способ соединения, если по TCP - то к локальной машине 1000 запросов в секунду, к удаленной - 200.
при этом я запускал десяток прог (одновременно), которые делают запросы, на удаленную машину - скорость не падает !!!!!!

при к локальной машине по NamedPipes - скорость около 4500 запросов в секунду
при простом соединении local - около 6000 в секунду.

короче, сильно тормозит TCP соединение

[Ivan_Pisarevsky]

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

[aaa3d]

тема затянулась и поползла в сторону
объясняю почему твой подход не универсален (мне пожалуй не подойдет)

т.к. все засовываем в таблицу а потом одной толстой ХП данные раскладываем по местам, все это происходит в пределах одной транзакции

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

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

[Ivan_Pisarevsky]

тема затянулась и поползла в сторону

Может она в нужную сторону ползет?

например, связанные таблицы по мастер-деталь, удалять мастера нельзя пока не удалены все детали.

ODDELETE CASCADE и нет конфликта

т.к. все засовываем в таблицу а потом одной толстой ХП данные раскладываем по местам, все это происходит в пределах одной транзакции

Ну заливай не одной, а побей на 10-20-100, пихни в процедуру пару параметров от какого ключа до какого.

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

На каждый чих отдельную транзакцию? Не поплохеет серверу?

[Ayrton]

Может она в нужную сторону ползет?

Именно так! Алгоритм синхронизации изначально кривой. Его надо просто выкинуть и написать по человечески. Чтоб небыло никаких сравнений баз, а ходили только изменения, причём каждое изменение имело бы свой Id и в случае любых коллизий было точно известно - на каком изменении сбой.

[Ayrton]

я тут еще поэксперементировал и вот что нарыл еще:
ограничения на скорость накладывает способ соединения, если по TCP - то к локальной машине 1000 запросов в секунду, к удаленной - 200.
короче, сильно тормозит TCP соединение

Естественно сетка тормозит - каждый вызов процедуры это нехилый обмен по сетке. Именно поэтому количество обращений должно быть минимальным, в идеале - ровно одно, с одним входным параметром и одним выходным.

Гонять данные построчно - это ваще дикость: потери сетки на передачу 1 байта информации и пакета на 32К ровно одинаковое - вот и вся тайна сетки. Общение клиента и сервера выглядит примерно так:

К - Сервер, хочу процедуру позвать
С - Зови
К - Процедуру Foo зову
С - Ну попробуй
К - Первый параметр ХХХ типа YYY
C - Хм! С типом первого параметра угадал!
К - Второй параметр ZZZ типа VVV
C - Опять угадал!
.... и так далее все параметры...
К - Больше параметров нет. Пускай процедуру
С - Ну ты сам этого хотел! Лови свой результат
К - Мать, так этож код ошибки!
С - А это уже не моё дело. Сам думай, чо с ней делать. Конец связи...

И вот такой трафик на каждый чих! Ваще любое общение сервера с клиентом - это тормоза.

Банальный тест: два запроса через ISQL:

select x from table;
select sum(x) from table;

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

[hvlad]

Естественно сетка тормозит - каждый вызов процедуры это нехилый обмен по сетке. Именно поэтому количество обращений должно быть минимальным, в идеале - ровно одно, с одним входным параметром и одним выходным.

Учите матчасть. Это давно есть в API

Общение клиента и сервера выглядит примерно так:

К - Сервер, хочу процедуру позвать
С - Зови
К - Процедуру Foo зову
С - Ну попробуй
К - Первый параметр ХХХ типа YYY
C - Хм! С типом первого параметра угадал!
К - Второй параметр ZZZ типа VVV
C - Опять угадал!
.... и так далее все параметры...
К - Больше параметров нет. Пускай процедуру
С - Ну ты сам этого хотел! Лови свой результат
К - Мать, так этож код ошибки!
С - А это уже не моё дело. Сам думай, чо с ней делать. Конец связи...

И вот такой трафик на каждый чих!

Сам придумал, или подсказал кто ?
Рекомендую жаропонижающее принимать.