Покинул форум
Сообщений всего: 530
Дата рег-ции: Февр. 2011
Помог: 10 раз(а)
Возможно, в документации и есть ответ на мой вопрос, но если кто обращал на это внимание, то пожалуйста подскажите:
1. имеет ли значение очерёдность параметров для сеанса CURL (влияет ли на скорость)?
и второй вопрос
2. существует ли параметр для ограничения величины получаемого пакета? скорей всего нет и здесь по-другому надо крутиться, ну а вдруг...))) то было бы очень удобно устранить ошибку "MySQL server has gone away", когда при проверке большого количества прокси на анонимность, вдруг натыкаешься на какое-нибудь сообщение от администрации длиной (8500, например)
Мелкий
Отправлено: 25 Апреля, 2011 - 15:12:15
Активный участник
Покинул форум
Сообщений всего: 11900
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 615 раз(а)
1) нет, не имеет. Всё равно до вызова curl_exec ничего не происходит.
2) немного не понял, как длина ответа курлу зависит от "MySQL server has gone away"
----- PostgreSQL DBA
vsll
Отправлено: 25 Апреля, 2011 - 15:23:06
Частый посетитель
Покинул форум
Сообщений всего: 530
Дата рег-ции: Февр. 2011
Помог: 10 раз(а)
я не умею задавать вопросы, вечно тороплюсь...
у меня есть такой скрипт:
те в зависимости от проверки на анонимность, прокси либо перемещается в другую таблицу (с условием, что там такого уже нет), либо остаётся на месте если он плохой и при
Цитата:
при посылке серверу неверного или слишком длинного запроса. Если mysqld получает неправильный или слишком большой пакет, то сервер предполагает, что с клиентом что-то не так, и закрывает соединение
отсюда http://www[dot]mysql[dot]ru/docs/man/Gone_away[dot]html
такое происходит, если при проверке большого количества прокси попадается живой, но возможно требующий платной авторизации и тд, он расценивается правильно как bad, но mysqld видимо уже закрывает соединение и выдаёт ошибку (Добавление)
ладно, спасибо Мелкий, видимо через курл нельзя так указать придёться вот здесь переписывать
Покинул форум
Сообщений всего: 9095
Дата рег-ции: Июнь 2007 Откуда: Berlin
Помог: 707 раз(а)
До конца не дочитали. Справляться с проблемой помогает:
Цитата:
Если необходимо выполнять объемные запросы (например, при работе с большими столбцами типа BLOB), можно увеличить предельный размер запроса, запустив mysqld с опцией -O max_allowed_packet=# (по умолчанию 1 Mб).
Интересно, какое именно поле в Вашей таблице столь велико.
И еще, не очевидно при чем здесь приведенное Вами регулярное выражение.
----- Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.
vsll
Отправлено: 25 Апреля, 2011 - 16:23:15
Частый посетитель
Покинул форум
Сообщений всего: 530
Дата рег-ции: Февр. 2011
Помог: 10 раз(а)
EuGen спасибо, тут не объёмный запрос тут дело в обработке моим регулярным выражением (которое требует чтобы первым значением массива был обязательно ip, а не пустота или административное сообщение), короче неправильное условие надо другое думать
EuGen
Отправлено: 25 Апреля, 2011 - 16:24:46
Профессионал
Покинул форум
Сообщений всего: 9095
Дата рег-ции: Июнь 2007 Откуда: Berlin
Помог: 707 раз(а)
Ну так а большой размер пакета для mysqld тогда при чем?. Делайте все вычисления заранее.
----- Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.
vsll
Отправлено: 25 Апреля, 2011 - 16:27:22
Частый посетитель
Покинул форум
Сообщений всего: 530
Дата рег-ции: Февр. 2011
Помог: 10 раз(а)
да, поняла уже, спасибо EuGen
vsll
Отправлено: 26 Апреля, 2011 - 17:44:35
Частый посетитель
Покинул форум
Сообщений всего: 530
Дата рег-ции: Февр. 2011
Помог: 10 раз(а)
В общем тупик...
если я проверяю много прокси с таймаутом 5сек - проблем нет
если 10сек - MySQL server has gone away
НО если я проверяю один прокси с интервалом 10сек, то всё нормально
самое оптимальное и быстрое условие как оказалось (кроме !empty, оно не все проблемы устраняет): if (!preg_match("/^[\d](\d|\.)+/", trim($result[0]))) {
см. код
Покинул форум
Сообщений всего: 4350
Дата рег-ции: Авг. 2008 Откуда: Москва
Помог: 57 раз(а)
Vasiliya пишет:
Champion если не сложно, pls надоело уже
Ну я же написал
Champion пишет:
то можно коннектиться заново перед выполнением запроса.
, то бишь mysql_connect перед mysql_query вставить (Добавление)
А можно поставить тайм-аут и 5, и даже 3 секунды. Нафига медленные прокси нужны? За 3 секунды не получилось - всё, значит не получилось.
vsll
Отправлено: 26 Апреля, 2011 - 18:12:35
Частый посетитель
Покинул форум
Сообщений всего: 530
Дата рег-ции: Февр. 2011
Помог: 10 раз(а)
Champion пишет:
А можно поставить тайм-аут и 5, и даже 3 секунды. Нафига медленные прокси нужны? За 3 секунды не получилось - всё, значит не получилось.
это из таблицы bad_proxy только, для опытов )))
это понятно что реконнект перед запросом, но нужно же наверное какое-то условие ещё чтобы абы зря не реконнектиться? или я ошибаюсь?
Покинул форум
Сообщений всего: 4350
Дата рег-ции: Авг. 2008 Откуда: Москва
Помог: 57 раз(а)
Да не, не нужно. Можно конечно засекать время между предыдущим и текущим mysql_query с пом. microtime() или time, но можно и не заморачиваться.
А еще можно mysql рестартануть с wait_timeout побольше. Или попробовать поменять ее запросом сразу после коннекта: set wait_timeout=2345.
Мелкий
Отправлено: 26 Апреля, 2011 - 21:43:01
Активный участник
Покинул форум
Сообщений всего: 11900
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 615 раз(а)
Vasiliya, возможно, имеет смысл сохранять результат проверки в массив и скидывать его в базу через каждые n проверок (штук 15-30). Т.е. сделали 20 проверок, подключились к БД, сохранили, отключились, делаем следующие.
Или, если set_time_limit можно в ноль выставить - то вообще сделать всю работу, а результат в самом конце сохранить.
Покинул форум
Сообщений всего: 530
Дата рег-ции: Февр. 2011
Помог: 10 раз(а)
Мелкий пишет:
Или, если set_time_limit можно в ноль выставить - то вообще сделать всю работу, а результат в самом конце сохранить.
Снять ограничение времени выполнения скрипта set_time_limit(0) не удалось, так так см скрин. Я действительно, попробовала, как мёртвому припарка... Где-то 8-9 проксей пропускает, если больше, то закрывает соединение (если таймаут > 5с), кстати такое подозрение, что соединение исчерпывает лимит времени, если натыкается на живой прокси, но с какой-нибудь бурдой первым значением массива вместо ip адреса, может preg_match не самое лучшее решение в такой ситуации?
возможно, имеет смысл сохранять результат проверки в массив и скидывать его в базу через каждые n проверок (штук 15-30)
мне кажется мудрое решение, но какие функции здесь нужно задействовать, если можно пример, не обязательно с расшифровкой или писать под мой код Прикреплено изображение (Нажмите для увеличения)
Все гости форума могут просматривать этот раздел. Только зарегистрированные пользователи могут создавать новые темы в этом разделе. Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.