обработка написанная в 1С шьет, очевидно, и складывает либо у себя, либо лезет по SFTP какому-нибудь на сайт и сваливает. Вообще всё это древнее, как говно мамонта решение. С 8-ки у 1С есть из коробки веб-сервисы (на самом деле она вся через веб-интерфейс может работать) в которые можно стучаться и забирать что нужно без всяких там файликов с минимальной настройкой со стороны 1С. Так и нужно реализовывать обмен.
Там по времени ограничение максимум поставили было проблема с nginx решилось с помощью установления тайм лимита, ошибок не выдает но и не работает зараза --- Добавлено --- \ Стандартный механизм переписали на фтп т.к. он не вывозил объем, а насчет 1с по вебке, у нас она стоит на нашем сервере, а закидываем мы на хостинг, т.е. можно например на нашем серваке расшарить и чтобы по доступу сайт опрашивал эту папку и забирал свежее? тогда как быть с заказами, они формируются на стороне сайта, тогда нам надо чтобы сайт на наш сервер ложил новые заказы так сложнее
вот что написали в ответ по поводу скрипта, показал я скрипт ребятам на форуме php, они подтвердили мою догадку при полном запуске full скрипт работает 7 часов Ничего подобного. Стоит сравнение что если скрипт запущен и не прошло еще 7-часов, то выдаваться сообщение и скрипт не запуститься заново. Как только скрипт отработает параметр запуска скрипта изменится и это сравнение не будет работать. В среднем полный спринт сейчас работает 6-8 часов, для этого и поставили это сравнение, т.е. Если его убрать, то случайно можно запустить несколько раз обработку и сервер просто ляжет. --- Добавлено --- печаль
Ну вот это к тому, что прежде чем строить догадки нужно досконально исходники изучать и запрос на бизнес-логику показывать. Иными словами, вы обманули подрядчика что показали тут на форуме всю логику, а вас обманули, что логика из того что вы показали понятна и предположительно работает так-то. Соответственно, другой момент: очевидно, есть необходимость делать всё это в один поток 6-8 часов, возможно, из-за ограничений веб-инфраструктуры, либо ограничений со стороны 1С откуда вы отдаете документы. Потому как технически возможно сделать это за 10 минут на том же php, запуская задачи импорта одновременно в 100 воркеров. Вопрос опять же в бизнес-требованиях и ограничениях.
Я тут прикинул, исходя из скорости обновления данных этим скриптом, наше среднее количество обновляемых позиций в день обновлялась бы неделями, а то и месяцами ))
просто для сравнения. у нас проводки за день с 200 филиалов обрабатываются и закрываются за 3 часа. хз что может импортироваться в базу за 7 часов. если все так долго, то возможно имеет смысл переписать на java или c#, хотя скорее всего идет какая нить дикая обработка циклов, которые по хорошему нужно оптимизировать.
Если есть доступ по SSH то проще воспользоваться готовой утилитой, которая напрямую загрузит данные в MySQL если они уже готовы.
я так понимаю там проблема именно в подготовке данных к загрузке в базу. т.е. из формата 1с приводят к формату магазина. соответствие категория и т.д. и т.п.
или дооптимизировались до того что insert в базу 2 секунды идет, причин может быть много 17к позиций*2 вот вам и 7 часов
У нас много полей в тч картинки и тех описания, если товар новый то еще и загружает со ссылок в базу картинки с описаниями, сами файлы формируются часа два из готовой базы 1с закидываются в папку в течении 10 минут, потом их начинает парсить