PHP.SU

Программирование на PHP, MySQL и другие веб-технологии
PHP.SU Портал     На главную страницу форума Главная     Помощь Помощь     Поиск Поиск     Поиск Яндекс Поиск Яндекс     Вакансии  Пользователи Пользователи


 Страниц (2): [1] 2 »   

> Без описания
vsll
Отправлено: 25 Апреля, 2011 - 14:41:53
Post Id


Частый посетитель


Покинул форум
Сообщений всего: 530
Дата рег-ции: Февр. 2011  


Помог: 10 раз(а)




Возможно, в документации и есть ответ на мой вопрос, но если кто обращал на это внимание, то пожалуйста подскажите:
1. имеет ли значение очерёдность параметров для сеанса CURL (влияет ли на скорость)?
и второй вопрос
2. существует ли параметр для ограничения величины получаемого пакета? скорей всего нет и здесь по-другому надо крутиться, ну а вдруг...))) то было бы очень удобно устранить ошибку "MySQL server has gone away", когда при проверке большого количества прокси на анонимность, вдруг натыкаешься на какое-нибудь сообщение от администрации длиной (8500, например)
 
 Top
Мелкий Супермодератор
Отправлено: 25 Апреля, 2011 - 15:12:15
Post Id



Активный участник


Покинул форум
Сообщений всего: 11900
Дата рег-ции: Июль 2009  
Откуда: Россия, Санкт-Петербург


Помог: 615 раз(а)




1) нет, не имеет. Всё равно до вызова curl_exec ничего не происходит.
2) немного не понял, как длина ответа курлу зависит от "MySQL server has gone away"


-----
PostgreSQL DBA
 
 Top
vsll
Отправлено: 25 Апреля, 2011 - 15:23:06
Post Id


Частый посетитель


Покинул форум
Сообщений всего: 530
Дата рег-ции: Февр. 2011  


Помог: 10 раз(а)




я не умею задавать вопросы, вечно тороплюсь...
у меня есть такой скрипт:
Спойлер (Отобразить)
PHP:
скопировать код в буфер обмена
  1. function get_contents($proxy) {
  2.         $ch = curl_init();  
  3.         curl_setopt($ch, CURLOPT_URL, "http://www.domen.ru/check.php");
  4.         curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
  5.         curl_setopt($ch, CURLOPT_USERAGENT, "Mozilla/5.0 (Windows; U; Windows NT 6.0; ru; rv:1.9.2.16) Gecko/20110319");
  6.         curl_setopt($ch, CURLOPT_TIMEOUT, 5);
  7.         curl_setopt($ch, CURLOPT_PROXY, $proxy);
  8.         $ss=curl_exec($ch);
  9.         curl_close($ch);
  10.         return $ss;
  11. }


те в зависимости от проверки на анонимность, прокси либо перемещается в другую таблицу (с условием, что там такого уже нет), либо остаётся на месте если он плохой и при
Цитата:
при посылке серверу неверного или слишком длинного запроса. Если mysqld получает неправильный или слишком большой пакет, то сервер предполагает, что с клиентом что-то не так, и закрывает соединение
отсюда http://www[dot]mysql[dot]ru/docs/man/Gone_away[dot]html
такое происходит, если при проверке большого количества прокси попадается живой, но возможно требующий платной авторизации и тд, он расценивается правильно как bad, но mysqld видимо уже закрывает соединение и выдаёт ошибку
(Добавление)
ладно, спасибо Мелкий, видимо через курл нельзя так указать придёться вот здесь переписывать
PHP:
скопировать код в буфер обмена
  1. if (!preg_match("/^((25[0-5]|2[0-4]\d|1\d{2}|\d{1,2})\.){3}(25[0-5]|2[0-4]\d|1\d{2}|\d{1,2})/", trim($result[0]), $m))

(Отредактировано автором: 25 Апреля, 2011 - 15:23:46)

 
 Top
EuGen Администратор
Отправлено: 25 Апреля, 2011 - 16:16:58
Post Id


Профессионал


Покинул форум
Сообщений всего: 9095
Дата рег-ции: Июнь 2007  
Откуда: Berlin


Помог: 707 раз(а)




До конца не дочитали. Справляться с проблемой помогает:
Цитата:

Если необходимо выполнять объемные запросы (например, при работе с большими столбцами типа BLOB), можно увеличить предельный размер запроса, запустив mysqld с опцией -O max_allowed_packet=# (по умолчанию 1 Mб).

Интересно, какое именно поле в Вашей таблице столь велико.

И еще, не очевидно при чем здесь приведенное Вами регулярное выражение.


-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.
 
 Top
vsll
Отправлено: 25 Апреля, 2011 - 16:23:15
Post Id


Частый посетитель


Покинул форум
Сообщений всего: 530
Дата рег-ции: Февр. 2011  


Помог: 10 раз(а)




EuGen спасибо, тут не объёмный запрос тут дело в обработке моим регулярным выражением (которое требует чтобы первым значением массива был обязательно ip, а не пустота или административное сообщение), короче неправильное условие надо другое думать
 
 Top
EuGen Администратор
Отправлено: 25 Апреля, 2011 - 16:24:46
Post Id


Профессионал


Покинул форум
Сообщений всего: 9095
Дата рег-ции: Июнь 2007  
Откуда: Berlin


Помог: 707 раз(а)




Ну так а большой размер пакета для mysqld тогда при чем?. Делайте все вычисления заранее.


-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.
 
 Top
vsll
Отправлено: 25 Апреля, 2011 - 16:27:22
Post Id


Частый посетитель


Покинул форум
Сообщений всего: 530
Дата рег-ции: Февр. 2011  


Помог: 10 раз(а)




да, поняла уже, спасибо EuGen
 
 Top
vsll
Отправлено: 26 Апреля, 2011 - 17:44:35
Post Id


Частый посетитель


Покинул форум
Сообщений всего: 530
Дата рег-ции: Февр. 2011  


Помог: 10 раз(а)




В общем тупик...
если я проверяю много прокси с таймаутом 5сек - проблем нет

если 10сек - MySQL server has gone away


НО если я проверяю один прокси с интервалом 10сек, то всё нормально


самое оптимальное и быстрое условие как оказалось (кроме !empty, оно не все проблемы устраняет): if (!preg_match("/^[\d](\d|\.)+/", trim($result[0]))) {
см. код
Спойлер (Отобразить)

можно ли както решить эту проблему, кроме запрета проверки нескольких прокси за раз, при заказном таймауте (по умолчанию 5с)
 
 Top
Champion Супермодератор
Отправлено: 26 Апреля, 2011 - 17:55:10
Post Id



Активный участник


Покинул форум
Сообщений всего: 4350
Дата рег-ции: Авг. 2008  
Откуда: Москва


Помог: 57 раз(а)




Если дело в том, что mysql рвет коннект при длительной неактивности, то можно коннектиться заново перед выполнением запроса.
 
 Top
vsll
Отправлено: 26 Апреля, 2011 - 17:57:09
Post Id


Частый посетитель


Покинул форум
Сообщений всего: 530
Дата рег-ции: Февр. 2011  


Помог: 10 раз(а)




Champion пишет:
Если дело в том, что mysql рвет коннект при длительной неактивности
да походу дело в этом, Champion если не сложно, pls надоело уже ... куда реконнект лучше вклинить, я уже ничего не соображаю на сегодня

(Отредактировано автором: 26 Апреля, 2011 - 18:08:54)

 
 Top
Champion Супермодератор
Отправлено: 26 Апреля, 2011 - 18:07:55
Post Id



Активный участник


Покинул форум
Сообщений всего: 4350
Дата рег-ции: Авг. 2008  
Откуда: Москва


Помог: 57 раз(а)




Vasiliya пишет:
Champion если не сложно, pls надоело уже
Ну я же написал
Champion пишет:
то можно коннектиться заново перед выполнением запроса.
, то бишь mysql_connect перед mysql_query вставить
(Добавление)
А можно поставить тайм-аут и 5, и даже 3 секунды. Нафига медленные прокси нужны? За 3 секунды не получилось - всё, значит не получилось.
 
 Top
vsll
Отправлено: 26 Апреля, 2011 - 18:12:35
Post Id


Частый посетитель


Покинул форум
Сообщений всего: 530
Дата рег-ции: Февр. 2011  


Помог: 10 раз(а)




Champion пишет:
А можно поставить тайм-аут и 5, и даже 3 секунды. Нафига медленные прокси нужны? За 3 секунды не получилось - всё, значит не получилось.
это из таблицы bad_proxy только, для опытов )))
это понятно что реконнект перед запросом, но нужно же наверное какое-то условие ещё чтобы абы зря не реконнектиться? или я ошибаюсь?

(Отредактировано автором: 26 Апреля, 2011 - 18:13:15)

 
 Top
Champion Супермодератор
Отправлено: 26 Апреля, 2011 - 18:21:53
Post Id



Активный участник


Покинул форум
Сообщений всего: 4350
Дата рег-ции: Авг. 2008  
Откуда: Москва


Помог: 57 раз(а)




Да не, не нужно. Можно конечно засекать время между предыдущим и текущим mysql_query с пом. microtime() или time, но можно и не заморачиваться.
А еще можно mysql рестартануть с wait_timeout побольше. Или попробовать поменять ее запросом сразу после коннекта: set wait_timeout=2345.
 
 Top
Мелкий Супермодератор
Отправлено: 26 Апреля, 2011 - 21:43:01
Post Id



Активный участник


Покинул форум
Сообщений всего: 11900
Дата рег-ции: Июль 2009  
Откуда: Россия, Санкт-Петербург


Помог: 615 раз(а)




Vasiliya, возможно, имеет смысл сохранять результат проверки в массив и скидывать его в базу через каждые n проверок (штук 15-30). Т.е. сделали 20 проверок, подключились к БД, сохранили, отключились, делаем следующие.
Или, если set_time_limit можно в ноль выставить - то вообще сделать всю работу, а результат в самом конце сохранить.

(Отредактировано автором: 26 Апреля, 2011 - 21:44:22)



-----
PostgreSQL DBA
 
 Top
vsll
Отправлено: 27 Апреля, 2011 - 10:22:34
Post Id


Частый посетитель


Покинул форум
Сообщений всего: 530
Дата рег-ции: Февр. 2011  


Помог: 10 раз(а)




Мелкий пишет:
Или, если set_time_limit можно в ноль выставить - то вообще сделать всю работу, а результат в самом конце сохранить.

Снять ограничение времени выполнения скрипта set_time_limit(0) не удалось, так так см скрин. Я действительно, попробовала, как мёртвому припарка... Где-то 8-9 проксей пропускает, если больше, то закрывает соединение (если таймаут > 5с), кстати такое подозрение, что соединение исчерпывает лимит времени, если натыкается на живой прокси, но с какой-нибудь бурдой первым значением массива вместо ip адреса, может preg_match не самое лучшее решение в такой ситуации?

Вот это
CODE (htmlphp):
скопировать код в буфер обмена
  1. возможно, имеет смысл сохранять результат проверки в массив и скидывать его в базу через каждые n проверок (штук 15-30)
мне кажется мудрое решение, но какие функции здесь нужно задействовать, если можно пример, не обязательно с расшифровкой или писать под мой код
Прикреплено изображение (Нажмите для увеличения)
mysql.gif

(Отредактировано автором: 27 Апреля, 2011 - 10:26:46)

 
 Top
Страниц (2): [1] 2 »
Сейчас эту тему просматривают: 1 (гостей: 1, зарегистрированных: 0)
« Работа с сетью »


Все гости форума могут просматривать этот раздел.
Только зарегистрированные пользователи могут создавать новые темы в этом разделе.
Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.
 



Powered by PHP  Powered By MySQL  Powered by Nginx  Valid CSS  RSS

 
Powered by ExBB FM 1.0 RC1. InvisionExBB