|
|
|
SQLEЧУС и задержка 200мс
|
|||
|---|---|---|---|
|
#18+
Выполняем тестовый пример Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. Отчего происходит задеожка в 200мс при выполнении SQLEXEC ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2007, 14:49 |
|
||
|
SQLEЧУС и задержка 200мс
|
|||
|---|---|---|---|
|
#18+
Компиляция запроса. Время можно в данном случае можно уменьшить используя SQLPrepare(). Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2007, 14:55 |
|
||
|
SQLEЧУС и задержка 200мс
|
|||
|---|---|---|---|
|
#18+
Ну это и так известно. Свои Native данные обрабатываются быстрее. Только, если данных очень много (гигабайты), сервер быстрее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2007, 15:38 |
|
||
|
SQLEЧУС и задержка 200мс
|
|||
|---|---|---|---|
|
#18+
задержка идет еще и потому, что при каждом SQLEXEC идет обмен с сервером не только для получения данных , но и некоторые "системные" проверки . поэтому пример не совсем корректен. Тут больше времени тратиться не на обрабтку и получение данных , а на организацию обмена. "Выгода" будет , если у вас на сервере много данных , с ними что-то надо сделать : отобрать , сгрупировать и т.д. Причем чем больше объем данных и чем селективнее запрос , тем больше "выгоды" получаешь. Кстати - вот еще чем хорош фокс - где надо можно получить выгоду в скорости обработки , используя "родные" курсоры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2007, 16:47 |
|
||
|
SQLEЧУС и задержка 200мс
|
|||
|---|---|---|---|
|
#18+
кстати - выполните в QA Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2007, 16:58 |
|
||
|
SQLEЧУС и задержка 200мс
|
|||
|---|---|---|---|
|
#18+
-=AlexiS=-задержка идет еще и потому, что при каждом SQLEXEC идет обмен с сервером не только для получения данных , но и некоторые "системные" проверки . поэтому пример не совсем корректен. Тут больше времени тратиться не на обрабтку и получение данных , а на организацию обмена. Т.е от этой задержке в обмене с SQL никак не избавится? OLEDB или ADO помогут? Sergey Sizov.Компиляция запроса. Время можно в данном случае можно уменьшить используя SQLPrepare(). Код: plaintext 1. 2. 3. 4. В том то все и дело, что запрос на сервере обрабатывается за 1-2ms(по крайней мере в profiler время 0) Программа написана так что происходит большое (1000-10000) количество последовательных простых запросов к sql и обработка результата каждого вызова. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2007, 17:16 |
|
||
|
SQLEЧУС и задержка 200мс
|
|||
|---|---|---|---|
|
#18+
-=AlexiS=-кстати - выполните в QA Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 3 секунды на серваке и 8 секунд в аналогичной по смысле программе на фоксе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2007, 17:18 |
|
||
|
SQLEЧУС и задержка 200мс
|
|||
|---|---|---|---|
|
#18+
По умолчанию, 100 мс VFP ждет перед тем, как проверять, что команда на сервере выполнилась Параметр WaitTime команды SQLSETPROP. Так, что это время будет тратиться всегда. Минимизируте кол-во обращений к сервере. Постарайтесь обработку перенести на сервер. С уважением, Алексей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2007, 08:52 |
|
||
|
SQLEЧУС и задержка 200мс
|
|||
|---|---|---|---|
|
#18+
Aleksey-KПо умолчанию, 100 мс VFP ждет перед тем, как проверять, что команда на сервере выполнилась Параметр WaitTime команды SQLSETPROP. Так, что это время будет тратиться всегда. Минимизируте кол-во обращений к сервере. Постарайтесь обработку перенести на сервер. Параметр WaitTime ни на что в данном случае не влияет(зависит от драйвера?). Смысла переносить на сервер обработку тоже не вижу , т.к. клиенту достаточно "толстые". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2007, 09:47 |
|
||
|
SQLEЧУС и задержка 200мс
|
|||
|---|---|---|---|
|
#18+
Если клиент "достаточно толстый", то может имеет смысл все на него закачать в один заход? С уважением, Алексей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2007, 10:45 |
|
||
|
SQLEЧУС и задержка 200мс
|
|||
|---|---|---|---|
|
#18+
Если клиент "достаточно толстый", то может имеет смысл все на него закачать в один заход? Проверено - лучше один раз все на клиента и потом локальные селекты, чем каждый раз дергать сервер для маленького запросика в цикле. Выигрыш в разы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2007, 11:30 |
|
||
|
SQLEЧУС и задержка 200мс
|
|||
|---|---|---|---|
|
#18+
BurnПроверено - лучше один раз все на клиента и потом локальные селекты, чем каждый раз дергать сервер для маленького запросика в цикле. Выигрыш в разы Несогласен - это смотря для чего. Если мы просто "по кускам " тягаем данные из одной таблице( ну или из простого запроса ) - тогда да - быстрее получаеться затянуть максимум нужных данных и перелопатить их на клиенте. Однако если данных много , а результаты выборки достаточно малы и получаються путем сложных или "тяжелых" расчетов - тогда обработку - на сервак . Опять-же для чего тягать "куски" в цикле - может стоит переложить весь расчет на сервер - и просто уже получить окончательный результат. Короче говоря - под каждую задачу-свой подход.И опять-же как хорошо что есть Фокс с его собственным движком БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2007, 12:04 |
|
||
|
|

start [/forum/topic.php?fid=41&fpage=209&tid=1589745]: |
0ms |
get settings: |
6ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
22ms |
get topic data: |
6ms |
get forum data: |
1ms |
get page messages: |
35ms |
get tp. blocked users: |
1ms |
| others: | 207ms |
| total: | 293ms |

| 0 / 0 |
