Максимальное одновременное соединение на ADODB.connection? - PullRequest
0 голосов
/ 03 ноября 2019

Я планирую загружать акции на 1400 акций, каждые 10 секунд. загрузка прошла идеально и потребляет всего пару миллисекунд.

Следующий шаг - запись 1400 записей в 1400 отдельных файлов MDB (т. е. каждый файл MDB с использованием 1 adodb.connection) каждые 10 секунд. Я пытался улучшить производительность, используя для выполнения работы многопоточность (не превышающую количество потоков ЦП), причем каждый поток отвечал за некоторые соединения.

Вскоре я понимаю, что производительность не улучшилась, как ожидалось (больше потоков не 't повышает производительность), и загрузка ЦП не увеличивается с увеличением числа потоков, что говорит о том, что узкое место было в объекте adodb.connection. Тем не менее, производительность была улучшена за счет использования альтернативно 2 отдельных строк подключения (другой поставщик), как показано ниже.

Provider=Microsoft.ACE.OLEDB.12.0;Data Source=xxx

Provider=Microsoft.JET.OLEDB.4.0;Data Source=xxx

Я также попытался превратить потоки в согласованный файл .exe и одновременно вызывать их с несколькими экземплярами (т. е. 12 экземпляров с 12-поточным процессором), и производительность была значительно улучшена (и нагрузка на ЦП начала увеличиваться до максимума при увеличении экземпляра)

Является ли провайдер узким местом всего процесса?

Или есть какой-нибудь правильный способ «продублировать» провайдера, чтобы повысить производительность?

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

Я также заметил, что общее количество одновременных подключений в проекте VB.net не может превышать 64 или иначе после всплывающего сообщения об ошибке:

Ошибка времени выполнения -2147467259 (80004005) Ошибка автоматизации, не указанаошибка

Можно ли увеличить ограничение на 64 соединения?

1 Ответ

0 голосов
/ 04 ноября 2019

Вы должны иметь возможность запускать каждую задачу как отдельный поток в .net. НАСТОЯЩАЯ проблема здесь, в то время как вы могли бы попытаться выполнить тяжелый поток вашего кода с 6 ядрами, вы получите увеличение только в 6 раз. Основная горлышко бутылки? Даже если бы вы держали все 6 ядер под управлением Thead? Вы также видите только небольшой процент использования процессора! Но почему?

Ну, а .net (или даже VBA) может легко выполнять миллиард инструкций в секунду? Ну, проблема становится огромным временем, чтобы открыть файл.

Если вы откроете файл? Затем ОС вступает в игру здесь. ОС проверит разрешения. ОС проверяет, существует ли файл. Затем он проверяет, открыт ли кто-то еще. Вирусное программное обеспечение может сканировать файл или выполнять другие действия. затем механизм данных ACE / JET в Access начинает работать. Он проверяет, открыт ли кто-то еще (и если да, то открывает файл в многопользовательском режиме). Если не многопользовательский режим, откройте файл для однопользовательского высокоскоростного использования. Теперь я могу вставить еще около 100 шагов здесь.

Но ВСЕ ВЫШЕ шаги не являются вашим кодом! Все вышеперечисленное происходит и выполняется ОС - все, что может сделать ваш код, это WAIT и WAIT для завершения всего вышеперечисленного. Поскольку вышеизложенное означает, что вы используете файловую систему, то ваш код будет сидеть сложа руки и долго ждать. В результате вы будете ждать информацию каталога и все виды вещей для загрузки. И эти вещи занимают много времени. Таким образом, процессор будет ожидать ввода / вывода и ждать загрузки файловых каталогов, а затем сканировать их. Таким образом, все становится привязанным к вводу / выводу (I / O), а не к процессору. В результате вы увидите ОЧЕНЬ низкий процент использования ЦП, поскольку на самом деле все тратит время на ожидание открытия и загрузки файла. Время открыть и получить дескриптор файла и начать поток данных в базу данных доступа? Ну, я сделал несколько тестов лет назад. Это около 100 000 записей потока данных. Другими словами, время открытия ОДНОГО файла базы данных примерно такое же, если база данных уже открыта и вы хотите сохранить 100 000 строк данных!

Итак, если вы открываете 10 баз данных? Что ж, если у вас уже есть один открытый, вы можете записать 1 миллион строк данных в то же время в одну базу данных !! Теперь, с лучшими ОС и файловыми системами, ядрами muti?

Что ж, 100 000 строк данных = открыть одно правило файла базы данных? Это могло бы измениться, и все могло бы быть НАМНОГО лучше. Но мы все еще стоим меньше 10 000 строк данных, записывающих в таблицу, поскольку это ОДНОВРЕМЕННАЯ стоимость и время, чтобы открыть ОДНУ базу данных !!!

Вы, безусловно, можете открыть 1400 файлов (баз данных) при запуске. Тем не менее, я должен думать, что что-то серьезно не так с дизайном и подходом, используемым здесь. Это вовсе не ясно из общей цели, но 1400 баз данных, похоже, не являются работоспособным решением, и использование большего количества процессоров и увеличение потоков в этой проблеме не принесут значительных результатов. В то время как вы можете получить 1400 потоков, файловая система ОС будет обрабатывать эти запросы и обрабатывать их не так уж и параллельно.

Хуже еще? Код для механизма доступа к базе данных (ACE / JET) более 30 лет. Это не управляемый код и, конечно, не многопоточный код. Однако, если вы создаете 1400 отдельных instsncs вашего файла, то они должны хорошо воспроизводиться, но совместное использование объекта подключения и т. Д. Не будет работать. Таким образом, вам нужно 1400 отдельных объектов подключения, и открывается 1400 отдельных файлов. Итак, если вы создадите класс и создадите 1400 экземпляров, а затем запустите каждый из них как отдельный поток из .net? Это должно работать, но, как уже было отмечено, с 6 ядрами вы получите только 6 реальных потоков, работающих и работающих над этой проблемой одновременно. И каждый из этих потоков по-прежнему будет ограничен операционной системой, которая поставит в очередь функции открытия файлов и управления файлами. Я не знаю, сколько файловых потоков позволяет Windows (скажем, версия 10), но файловая система все равно останется узким местом, если вам удастся открыть 1400 файлов.

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

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

Вам действительно нужно открыть один файл базы данных, и внутри у вас будет 1400 таблиц (поскольку это только один файл, который открывается).

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

Вам необходимо дать дополнительные сведения, почему нельзя использовать одну таблицуВот. Это, вероятно, ваш лучший выбор и решение. Вы можете рассмотреть 1400 таблиц в ОДНОЙ базе данных, но открытие 1400 баз данных на самом деле не является практической идеей.

...