Нет callback от TFDQuery

[Камышев Александр]

Windows, TFDConnection + TFDQuery, асинхронный режим запросов, 10 TFDQuery создаются динамически

fconnection = new TFDConnection(NULL);
fquery = new TFDQuery(NULL);
fquery->Connection = fconnection;
fquery->AfterOpen = AfterOpen;
fquery->AfterExecute = AfterExecute;
fquery->OnError = QueryError;

Всего около 500 запросов в секунду, т.е. по 50 на каждый, после каждого запроса по AfterOpen и AfterExecute сразу следующий запрос из очереди. В случае QueryError - разрыв соединения и через паузу повтор. При тестировании была выявлена деградация количества записей в секунду, вплоть до полной остановки. Локализация показала, что при высокой нагрузке TFDQuery иногда не возвращает callback менее чем совсем, ни AfterExecute ни QueryError, в общем "друг, оставь покурить, а в ответ - тишина". При этом у TFDConnection State = csConnected  и у TFDQuery State = dsInactive. 

Проблема была решена костылем с таймаутом, если за секунду нет ответа - уход в ошибку с разрывом соединения и повтором.

Теперь вопрос, может я чего-то не знаю? где callback?

[Равиль Зарипов (ZuBy)]

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

и в devart тоже самое

[Камышев Александр]

7 минут назад, Равиль Зарипов (ZuBy) сказал:

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

и в devart тоже самое

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

[Равиль Зарипов (ZuBy)]

я имел ввиду серверные языки на бэкграунд, там такой болезни нет)

[Камышев Александр]

В продолжение темы.

С асинхронным режимом amAsync  в FD все плохо, нет колбэков - полбеды, на 1200-1500 крашится все сразу, на нескольких сотнях запросов умирает медленно и мучительно. Завершение работы через раз с крашем. Режим amNonBlocking ненамного лучше, те же яйца только в профиль, годится только для клиентского интерфейса работы с БД.

Перемудрили что-то разработчики там с потоками.

Остался режим amBlocking + TTrhead. Класс для простоты общения со средом:

//---------------------------------------------------------------------------

class TMyDBConnThread : public TThread
{
private:
	TInterlocked *Interlocked;
	TNotifyEvent FOnExecute;
	TNotifyEvent FOnReady;
	void __fastcall SyncReady(){ FOnReady(this); }

protected:
	void __fastcall Execute();
public:
	__fastcall TMyDBConnThread(bool CreateSuspended);
	__property TNotifyEvent OnExecute = { read = FOnExecute, write = FOnExecute };
	__property TNotifyEvent OnReady = { read = FOnReady, write = FOnReady };
	TFDConnection *connection;
	TFDQuery *query;
	TSimpleEvent *event;
	int buzy;
};
//---------------------------------------------------------------------------

//---------------------------------------------------------------------------

void __fastcall TMyDBConnThread::Execute()
{
Interlocked = new TInterlocked;
while ( !Terminated )
	{
		event->WaitFor( INFINITE );
		if ( Terminated ) break;
		Interlocked->Exchange( buzy, 1 );

		FOnExecute(this);

		Interlocked->Exchange( buzy, 0 );
		event->ResetEvent();
		Synchronize( SyncReady );
	}
delete Interlocked;
delete event;
}
//---------------------------------------------------------------------------

Вся работа с бд в FOnExecute и потокозащищенный колбэк FOnReady.

Далее удивление: устойчивая работа, отсутствие ошибок, 9000+ запросов в БД в секунду и при этом 20-30% загрузки, в асинхронном режиме для сравнения 1500 запросов под 60%. 

Все зависит от степени кривизны рук, однако...

 

Изменено 27 января, 2017 пользователем Камышев Александр

[Rusland]

3 часа назад, Камышев Александр сказал:

Далее удивление: устойчивая работа, отсутствие ошибок, 9000+ запросов в БД в секунду и при этом 20-30% загрузки, в асинхронном режиме для сравнения 1500 запросов под 60%. 

 

 

9000+ - это select-ы или запись в базу так же быстро делается?

[Камышев Александр]

В 27.01.2017 в 15:42, Rusland сказал:

9000+ - это select-ы или запись в базу так же быстро делается?

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

На пакет http ответ уходит сразу, без подтверждения записи в бд. Если ждать подтверждение скорость резко падает, и больше 600-800 http запросов служба затыкается, краш где-то получается.

Всего удалось получить больше 3000 тысяч запросов т.е. 3000 * 3 = 9к в секунду, движок СУБД при этом занимает 10-15% загрузки.

MySql с максимальными настройками, измерял время потраченное на три запроса - поднималось в пике до 50мс. Десять коннектов держали по 300 таких пакетов запросов, т.е. среднее время должно было быть ~3 мс на запрос. Как-то не сходится... буду дальше копать

[Камышев Александр]

статистика:

запросов задач в сек. 3000
подтверждений в сек. 0
параметры файлов в сек. 0
запросов данных в сек. 0
запросов клиента в сек. 0
время запроса, мсек. 156
активных соединений с бд 10 из 10
запросов в бд в сек. 3000
размер очереди в бд 1365 из 5000
время запроса к бд, мсек. 31
устройства 2490
профили 139
задачи 51
файлов доступно 11
db_client 0 запросов в сек. 300
db_client 1 запросов в сек. 302
db_client 2 запросов в сек. 300
db_client 3 запросов в сек. 300
db_client 4 запросов в сек. 301
db_client 5 запросов в сек. 300
db_client 6 запросов в сек. 300
db_client 7 запросов в сек. 298
db_client 8 запросов в сек. 299
db_client 9 запросов в сек. 300

[Камышев Александр]

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