Обойти таймаут выполнения скрипта
 

Закачивается прайс-лист с помощью curl и выполняется скрипт, который из csv закачивает прайс-лист в mysql, но т.к. число строк в прайсе большое, то получаю
"Maximum execution time of 10 seconds exceeded in..."

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

Всё-таки уточню. Настроить сервер чтобы ждал дольше это не проблема, но больше интересует как решается задача закачки больших объемов данных.

Закачивают пачками, например по 1000 строк.

[quote=40KHYTbIU;38709875] Закачивают пачками, например по 1000 строк. [/quote]
+1
Задача норм решается например через строго последовательные асинхронные AJAX запросы к серверу.

Поможет
set_time_limit(0);
если не хочется загружать сильно сервер, то можно между циклами добавить паузу
sleep ( 5 );

0-Leshgan >А с помощью FTP залить прайс на Сервак НЕЗЯЯ?
Тогда просто грузи через Форму:
<form name="update" method="post" action="index.php?admin=update" enctype="multipart/form-data">
Обновить прайс:<input name="userfile" size=50 type="file" />
<input type="submit" value="Загрузить" />
</form>
А дальше PHP:
<?php if($_GET['admin']=='update')**
if(file_exists($_FILES['userfile']['tmp_name']))**
Обработка файла Прайса !!!
**
** ?>
Ну вообщем куда и что вставлять сами разберетесь - пример рабочий, прайсы обрабатываются заливаются Спокойно!
Причем прямо из Excel прайса в 35000 строк 18 метров!
Проверенно МИН НЕТ!

1-Leshgan > уточни условия задачи, а то не понятно, может для вас 20мб тоже большие данные.
Но поскольку это пхп тут пишут разные варианты [url]http://joomlaforum.ru/index.php/topic,36283.0.html[/url]

5-AlexIT >читайте внимательнее вопрос
6-40KHYTbIU >задача - грузить в mysql
---
пачками надо, сохранять номер последней обработанной строки и продолжать с нее, при этом использовать защиту от дублирования на всякий случай.
Скрипт из браузера запускается? Можно просто выводить мета рефреш, а последние строки (номер) хранить в сессиях, или передавать в get.
Если из ssh запускается, ограничение не должно срабатывать.

7-Фанат NASCAR >Так я Вам про что и говорю?
Про Загрузку из Прайса в базу MySQL!
Причем ВСЕГО прайса сразу!
Сначала загружается весь файл - Стандартной процедурой Формы HTML из Браузера.
А затем PHP проходит по строкам прайса и Заливает их в Базу.
Никаких проблем с таймаутами НЕ БЫЛО.
Скорей всего Вы что то Перемудрили!

8-AlexIT >я? Я не топикстартер. Вы просто с объемами не сталкивались. А я сталкивался, когда база уже в mysql 40гб весит, и импорт всю ночь шел)

Ключевое тут - формировать запрос пачками, исполнять пачку, брать следующую и тд

7-Фанат NASCAR > кэп с нами!

Автор, чтобы не городить "правильное" решение в вашем маленьком интернет магазине, но не увеличивать продолжительность жизни скрипта при каждом чихе, есть вы на стороне сервера можете исполнять команды и там линух, то вот пример распиливания

split -l 1000 book.txt new

Потом заливаете каждый файл подотдельности, можно даже параллельно если мускул позволит.

10-Фанат NASCAR >Я тебе в личку уже кинул Демку!
Когда база 40 гиГ - глупо ее обновлять одним файлом!
Всегда можно разбить на ПОДРОЗДЕЛЫ например по категориям товара это РАЗ!
2) Если ты файл в 40 гиг кидаеш на Сервер - тогда таймаут тут не причем!
Ты спросил у Сервера он может его принять?
И если сервер даже согласен такого монстра принять - спроси свой канал Интернета, а сможет ли он его ПЕРЕДАТЬ!
Недавно был такой случай - Человек с работы не смог обновить на сайте прайс в 12 метров.
А из дома тотже прайс обновил Спокойно за 5 сек!
Вопрос кто ТУПИТ Сервак, Человек или Админ на работе?

И к стати, если файл уж такой НЕПОДЪЕМНЫЙ - лучше его лить по FTP, а потом его обрабатывать.
Как это делает 1Ска с Битрексом!

13-AlexIT >поясню еще раз.
У автора проблемы не с доставкой файла на сервер, а с конвертацией его содержимого, с импортом в mysql.
Вопрос "как залить файл на сервер" не стоит.

Правильно - не разбивать на "подрОзделы", надеясь на то, что превышения не будет.
Правильно - построить алгоритм формирования запросов "пачками", и перезапуск скрипта с новыми данными.

15-Фанат NASCAR >А Вы уверенны что проблема не в ЗАЛИВКЕ?
Любой обработчик из файла обновляет базу по Строкам!
Другого алгоритма пока еще не придумано!
так как в MySQL оператор UPDATE конечно может выполнить обновление нескольких строк БАЗЫ если ему задать параметр WHERE id<10 но это для ГУРМАНОВ.
А для обычных людей WHERE id=10.
А оператор INSERT вообще вставляет только 1 строку без всякого id!

[img]http://www.podkat.ru/uploads/posts/2010-12/thumbs/1292415665_homer_facepalm.jpg[/img]

простите)

Очень тронут такими дебатами, спасибо. В споре рождается истина :)

[quote=Фанат NASCAR;38724187] автора проблемы не с доставкой файла на сервер, а с конвертацией его содержимого, с импортом в mysql[/quote]

именно так! Хотел выпендриться и делать это всё из curl по шедулеру с сервера в локальной сети. Без браузера.

[quote=AlexIT;38724882]А Вы уверенны что проблема не в ЗАЛИВКЕ?[/quote]

залить можно было и по FTP как Вы советовали, это вообще не проблема. И заливаю я так же как Вы посоветовали в №5, только вызываю форму curl'ом.
Вот только у меня не 35тыс записей, а 90. На 35 тоже не было проблем. Вообще-то он успевает даже все 90 залить в базу, но вываливает таймаут. Это не надежно, поэтому отказался от этого изврата. А городить разбивку в моем случае или писать что-то еще более сложное нет смысла.


В общем было принято решение заливки прайса на сервер по FTP и дальнейшая его обработка по крону. В этом случае есть шанс закачать в базу старый прайс (если вдруг заливка на сервер сбойнула). Но это не столь критичный момент. Можно сделать анализ даты/времени создания файла и слать на почту уведомление, если дата/время не поменялись. Как-то так.

19-Leshgan >да сделайте простейшие пачки, по тому же крону. Вариантов масса, просто сохраняйте в файл обработанный номер строки, и прыгайте от него + 10000строк построчно, если не еоф. И формируйте запрос.
Запрос исполнили, новую строку сохранили, вызвали php -f self асинхронно и умерли

А перед стартом можно проверку на себя запущенного делать, $r=exec('ps ax | grep script.php') и смотреть вывод

20-Фанат NASCAR > зачем пачки, если запуск скрипта на сервере (на хостинге) не имеет ограничений по времени? Просто запустить то, что уже есть и пусть пашет хоть 10 минут (сейчас из браузера работает около 4-5 минут)

wget, парсинг в оффлане...

22-Leshgan >потому что дальше потребуется полчаса, час, и в итоге придется собирать данные по кускам после каждого косяка. Работу надо делать хорошо и правильно.

[quote=Игорь2;38710865] Цитата: Сообщение от 40KHYTbIU Закачивают пачками, например по 1000 строк. +1 Задача норм решается например через строго последовательные асинхронные AJAX запросы к серверу. [/quote]

Смешно :) А если строго последовательные, то почему асинхронные?

25-zorg >чтобы не завешивать вызывалку.

Ребята (что почти всех касается), вы почитайте пожалуйста документацию к MySQL. Там есть функция быстрой загрузки данных из csv. Причем работает она реально быстро. У меня 800к записей загрузились за 20-30 сек.

Для сравнения INSERT на этой БД выполнялись со скоростью 100-140 записей/мин.

Не хочу переходить на личности, но советую особо отличившемуся (и даже прописавшему IT в своем нике) прочитать таки документацию...

Грамотно эта задача решается так: прайс переводят в csv, заливают на сайт (можно даже через http, но правильнее через ssh), затем или из консоли запускается апдейт или CGI скрипт форком осуществляет заливку базы.

27-1isadmin > LOAD DATA INFILE?
Это хорошо, наверное, когда у вас данные один к одному и не требуется никакой предобработки и проверки.

28-40KHYTbIU >именно так. На практике - поиск дублей, различий в данных и только потом обновление или вставка.

28-40KHYTbIU > хорошая штука этот LOAD DATA INFILE. Спасибо 27-1isadmin
А вот на счет
[quote=40KHYTbIU;38824838] не требуется никакой предобработки и проверки[/quote]
то я бы данные загонял в темповую таблицу.

Но пока меня устраивает работа скрипта по крону на хостинге. Работает себе как часы.