<?php // Полная загрузка сервисных книжек, создан 2024-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
имхается мне, что «обычный метод» — веб-сервис, возвращающий результат, будет отрабатывать в 30-50 раз быстрее comконнектора-а из статьи
как вообще два слова «COMConnector» и «скорость» оказались рядом? 🙂
(1) vano-ekt, За скорость веб-сервис vs COM-соединение сказать не берусь, но чтобы реализовать ч/з Веб-сервис, надо что-бы был веб-сервер, вроде бы. Кроме того, надо менять конфигурацию.
> как вообще два слова «COMConnector» и «скорость» оказались рядом? 🙂
Проверял на разных базах — быстрее работает почему-то. Сам в шоке.
Спасибо за статью!
Тоже возникала такая идея: если нельзя ходить на сервер, сходить туда фактически через Com. Но задач когда «нельзя» так и не поступило. А про скорость (то что быстрее будет через Com) не думал и не знал. Если когда-нибудь пригодится: обязательно попробую 2 варианта (классический и через Com) и посмотрю кто быстрее.
А не проще ли толстый клиент запустить?
(4) tormozit, Это хороший вопрос. Он может послужить началом длинного разговора о целесообразности толстого и тонкого клиента и вообще о подобной архитектуре. А если говорить кратко, то я бы с удовольствием запустил толстый клиент, но, к сожалению, его будущее у 1С выглядит весьма туманным.
(5) это будущее может и внешнее соединение убрать в туман, т.к. по сути толстый клиент = внешнее соединение + UI.
(6) tormozit, Согласен, но это произойдет, по крайней мере, не раньше, чем об этом скажет Microsoft.
Microsoft давно похоронило бы COM, и .NET — есть шаг именно в этом направлении, но у них еще слишком много клиентов, использующих старый хлам. Хотя рано или поздно это произойдёт.
Интересно. Подозреваю, действительно возможны ситуации, когда com-соединение будет быстрее. Я вот только не знаю, используются ли при таких соединениях сеансовые данные клиента и как именно, и что туда пихается, и как кэшируется. Может, оно засчёт прогрева кэша выезжает?… Или вы однократную операцию меряли?
(8) Yashazz, Непонятно, что имеется ввиду под сеансовыми данными клиента.
Сам COM-объект находится на клиенте. Проще всего представить его как отдельный процесс. Это процесс 1С, это он обеспечивает связь с сервером. Скорее всего теми же механизмами, что и в толстом клиенте.
Когда я замерял, я старался исключить влияние возможного кэша, если он есть. Просто мерил несколько раз подряд, пока результат не стабилизировался.
Ускорение возникает, на мой взгляд, за счет эффективной работы объекта «РезультатЗапроса». Он формируется относительно быстро. Его содержимое нельзя посмотреть в отладчике, мы не можем обратиться к записи по индексу. Такое ощущение, что где-то там используется что-то вроде последовательного доступа. И, скорее всего, в асинхронном режиме. Т. е. когда мы извлекаем из него первую запись, основная часть данных находится еще где-то за пределами сервера 1С. И в теории, мы можем начать заполнение какой-нибудь коллекции уже через каких-то 1-2 секунды после того, как мы только отправили запрос на выполнение. И если мы всё делаем на сервере, то так оно и будет.
Однако в режиме «тонкий клиент-сервер», получить первую запись из него на клиенте мы можем только после полного обхода всего результата запроса. Это необходимо, как минимум, чтобы его сериализовать. Пытаться передавать данные последовательно в этом режиме просто нереально. Сервер инициализирует контекст при каждом вызове. И это беда.
Всё было бы по другому, если бы клиент общался с сервером 1С также последовательно и в асинхронном режиме. Но это уже что-то из области фантастики.
Немного не понял смысла статьи, если вкратце:
1. Передача данных между клиент-сервер тормозит из за сериализациидесериализации не примитимвных типов.
2. Комобъект разрешает передавать только примитивные типы, проблемы из п.1 нет.
Я где то ошибся?
(10) webester, Факт в том, что получить данные на клиенте предлагаемым способом можно в 3-5 раз быстрее, это реально работает, можно проверить. Почему это так, я могу только предполагать.
Передача тормозит не столько из-за сериализации именно не примитивных типов, сколько вообще из-за сериализации 1С. Насколько я понимаю, 1С всё это перегоняет в XML. XML — это всегда не лучший вариант с точки зрения быстродействия, но главная проблема на в XML, в том, что я описал выше, см. (9)
В основном выигрыш возможен, если не весь объем данных в реальности используется. У части записей не используются некоторые поля, за счет программной логики пропускается «обработка части записей».
Несколько меньше должно влиять факт, что «обработка на клиенте» происходить только после полной сериализации (и передачи) всего пакета. При ComConnect получение данных размазывается и ведется параллельно с «обработкой».
(12) V.Nikonov, Можно поставить эксперимент. Странно то, что «размазывание» получения данных даёт ощутимый выигрыш. Я набросал обработку, которая позволяет сравнить передачу данных в двух режимах — стандартным способом (ч/з ЗначениеВРеквизитФормы) и через COM.
Обработке надо указать текст запроса (конструктор запроса вызывается по правой кнопке). Запрос должен выдавать одно поле типа «Строка». Называться это поле должно «Значение». Потом нажимаете либо «Получить стандартно», либо «Получить через COM». Время засекается автоматически.
В моих условия получились следующие результаты.
Текст запроса:
Время передачи стандартным способом: 205 сек.
Время передачи через COM: 38 сек.
Получилось быстрее более чем в 5 раз. Какими накладными расходами это объяснить, сам не понимаю.
(13) а пробовали делать то же самое с помощью процедуры c &НаСервереБезКонтекста?
Т.е. взять, и написать так:
Показать
Быстрее Вашего решения получается или нет?
(14) starik-2005, У меня получается примерно следующий результат:
10 сек
13 сек
8 сек
(15) Вы не поняли сути. Я предлагаю выполнить запрос на сервере без контекста (т.е. вообще без СОМ), потом передать результат в виде массива назад, а потом уже на клиенте заполнить. В Ваших вариантах я подобного не нашел. Есть мнение, что таи, как предлагаю я, будет некоторым образом быстрее, но мне особо не на чем тестить.
(16) starik-2005, Проверил.
Схема такая:
Время на выполнение запроса не учитывается, как и в предыдущих случаях.
По предыдущим способам у меня получились теже самые секунды, а по этому так: сам массив получается довольно быстро — 9 сек. Еще 6 сек. уходит на заполнение коллекции, итого 15 сек. Для сравнения, через ЗначениеВРеквизитФормы на сервере — 46 сек.
(17) а это связано с тем, что сервер готовит форму с заполненными данными, после чего полностью именно форму и коллекцию формы сериализует и передает на клиент для отображения. Видимо сама подготовка контекста формы на сервере занимает существенное время, а не передача данных с клиента на сервер и обратно. Это проблема криворукости и лени программистов из 1С, реализовавших данный механизм через какое-то далекое место (аля запроса в цикле).