Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
Программирование. Ступени успешной карьеры. Авторы: Кузнецов М.В., Симдянов И.В. PHP. Практика создания Web-сайтов (второе издание). Авторы: Кузнецов М.В., Симдянов И.В. Самоучитель MySQL 5. Авторы: Кузнецов М.В., Симдянов И.В. MySQL 5. В подлиннике. Авторы: Кузнецов М.В., Симдянов И.В. Объектно-ориентированное программирование на PHP. Авторы: Кузнецов М.В., Симдянов И.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Форум PHP

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум Структурный форум

тема: Проверка мобильного номера
 
 автор: Filsh   (04.04.2013 в 15:25)   письмо автору
 
 

Динамически формирую регулярное выражение для проверки телефона
'UKR' => array(
            'prefixes' => array('8', '38', '\+38'),
            'length' => array(10),
        )


если страна Украина например, то берется этот конфиг и с него делается регулярка
/^(8|38|\+38)(\d{10})$/

все отлично работало, до той поры, пока не понадобилось мне делать массовую проверку очень большего количества номеров,
порядка 10 000 за один запрос и регулярка стала показывать неадекватное время выполнения - 10с.

Как ее можно оптимизировать?

  Ответить  
 
 автор: Filsh   (04.04.2013 в 15:33)   письмо автору
 
   для: Filsh   (04.04.2013 в 15:25)
 

кажется я не в ту ветку запостил тему), переместите пожалуйста в Регулярные выражения, у кого есть права)

  Ответить  
 
 автор: confirm   (04.04.2013 в 16:07)   письмо автору
 
   для: Filsh   (04.04.2013 в 15:25)
 

Большого количества, это в смысле списка номеров и т.п., или это такое количество запросов?

  Ответить  
 
 автор: Filsh   (04.04.2013 в 16:18)   письмо автору
 
   для: confirm   (04.04.2013 в 16:07)
 

список номеров, эксперементальным методом было определенно, что в 5 мб помещается 50 000 записей(с доп информацией)

я хочу сделать загрузку списка контактов, и после дать возможность этот список редактировать(предпросмотр), а потом сохранить.
Поэтому сначала весь список(до 5Мб) сохраняется в спец. таблицу, с ней делаются манипуляции по редактированию,
а потом при нажатии на сохранить это все копируется в основную базу, уже валидированные данные

тестировал на списке номеров в 10 000, он проганяется почти за 10 сек!! + запись в базу = очень долго((

  Ответить  
 
 автор: confirm   (04.04.2013 в 16:30)   письмо автору
 
   для: Filsh   (04.04.2013 в 16:18)
 

Не надо расчетов сколько во что поместится.
Если у вас уже есть готовый список, это одна проблема, но если это вы добавляете номера в этот список, то трудно представить себе, что вы только после ввода 50000 номеров будете производить запись. Максимум хватит терпения на ввод может быть сотни. И если второе, то почему при записи в базу не происходит их проверка (следовательно в дальнейшем необходимость в ней отпадает), а потом, огромный массив их?

  Ответить  
 
 автор: Filsh   (04.04.2013 в 16:39)   письмо автору
 
   для: confirm   (04.04.2013 в 16:30)
 

все чуть не так
загрузка будет с csv
есть клиенты, допустим этот клиент загрузил большой список в формате csv, я его сразу в базу отправлять не хочу,
а вдруг там что то не валидное, поэтому пробегаюсь по каждой записи, валидирую их, и всю пачку кладу в отдельную таблицу
помечая строки с ошибками. Потом клиенту делается грид этих данных, типа предпросмотр, где он может каждую запись редактировать.
Когда все ошибки исправлены, он может сохранить этот список(просто переливаем в основную таблицу).

Так вот ограничение я сделал до 5мб, и на этом количестве скрипт завершает свою работу по таймауту, потому нужно оптимизировать узкие места)

  Ответить  
 
 автор: confirm   (04.04.2013 в 16:51)   письмо автору
 
   для: Filsh   (04.04.2013 в 16:39)
 

>я его сразу в базу отправлять не хочу, а вдруг там что то не валидное, поэтому пробегаюсь по каждой записи, валидирую их

Не кажется ли вам это странным - с одной стороны вы чего-то боитесь, с другой стороны, боясь все таки делаете проверку? Почему же не проверить сразу?

Это на какой-то кошмар похоже, ей богу - вы можете представить себе пользователя, который бы за один раз смог проверить 10000 номеров? Наверное же надо щадить их, и отдавать в таком случае порциями, а это уже гораздо меньшая нагрузка.

Но дело даже не в этом - на кой ляд вообще это нужно, если правила определяет не пользователь а вы? По идее должна быть таблица регионов: Россия, Украина,.... и нужно всего лишь раз проверить (пусть и рег. выражениями) на соответствие региона, помещать принятый номер в базу с указанием региона его (1 - Россия, 2 - Украина, 3 - ....), и возвращать пользователю сразу на редактирование то, что не отвечает условиям?

  Ответить  
 
 автор: Filsh   (04.04.2013 в 17:09)   письмо автору
 
   для: confirm   (04.04.2013 в 16:51)
 

>Не кажется ли вам это странным - с одной стороны вы чего-то боитесь, с другой стороны, боясь все таки делаете проверку? Почему же не проверить сразу?

>Это на какой-то кошмар похоже, ей богу - вы можете представить себе пользователя, который бы за один раз смог проверить 10000 номеров? Наверное же надо щадить их, и отдавать в таком случае порциями, а это уже гораздо меньшая нагрузка.

ну хорошо, этот момент я еще обдумаю, может вы и правы конечно

>По идее должна быть таблица регионов: Россия, Украина,....

это все есть, и вставляется оно по регионам

но тем не менее, даже если я буду сразу вставлять 10 000 в базу, то они долго обрабатываются и часть вины в этом, судя по всему, в регулярке.

  Ответить  
 
 автор: Filsh   (04.04.2013 в 17:16)   письмо автору
 
   для: Filsh   (04.04.2013 в 17:09)
 

просто если регулярку не получится оптимизировать, то буду что то думать другое
щас добавил игнорирование регистра, но скорости это не добавило
/^(8|38|\+38)(\d{10})$/i

  Ответить  
 
 автор: confirm   (04.04.2013 в 17:26)   письмо автору
 
   для: Filsh   (04.04.2013 в 17:16)
 

А зачем числам регистр? Код чисел не зависит от регистра.

  Ответить  
 
 автор: Filsh   (04.04.2013 в 17:38)   письмо автору
 
   для: confirm   (04.04.2013 в 17:26)
 

да, но я подумал что регулярное выражение будет на пару тактов процессора быстрее работать, если явно указать не обращать внимание на регистр)

  Ответить  
 
 автор: confirm   (04.04.2013 в 17:43)   письмо автору
 
   для: Filsh   (04.04.2013 в 17:38)
 

А что значит не "не обращать внимание на регистр"? Наверное же не плюнуть и принять как есть, так ведь? Не обращать внимание, это значит вычитать из кода "лишние" биты и проверять соответствие, а это время, так что...

  Ответить  
 
 автор: Filsh   (04.04.2013 в 18:02)   письмо автору
 
   для: confirm   (04.04.2013 в 17:43)
 

зачем вы придераетесь? вы же поняли что я имел ввиду... и все таки как быстрее с i, или без нее?

  Ответить  
 
 автор: confirm   (04.04.2013 в 18:18)   письмо автору
 
   для: Filsh   (04.04.2013 в 18:02)
 

А с чего вы взяли, что я придираюсь? )
Ну сами подумайте, быстрее ли будет не учитывать регистр, если для этого требуется преобразование каждого байта и его проверка, тем более, что для чисел в этом нет необходимости?

  Ответить  
 
 автор: confirm   (04.04.2013 в 17:25)   письмо автору
 
   для: Filsh   (04.04.2013 в 17:09)
 

Давайте исходить из того, что большой объем информации неструктурированной и подлежащей обработке, это в любом случае время.
Могу привести пример - мне требовалось из документа Word, представляющего собой перевод с китайского на русский, удалить китайский и английский, а также некоторые символы, затем просчитать длину строки каждой, и в итоге общую длину всех строк.
Сперва документ проходил определенное преобразование, затем разбивался на массив строк, удалялись возможные пустые элементы, а затем в цикле рег. выражениями удалялось лишнее, и производился подсчет.
Максимально полезных строк при этом (*не пустых) было более 3000. И все это происходило быстро.

Но ведь исходить надо не из этого, а из того, что у вас номера. Если бы ваш список был Маша, Даша, Петя, Коля..., согласитесь, что работать с таким списком было бы намного удобнее, чем 23642783423, 538209344... Представьте себя на месте пользователя, смогли бы вы редактируя такой список с огромным числом записей стопроцентно не допустить в нем ошибок? Вряд ли.

Не знаю о чем вы подумаете, но большой массив, это время, а значит нужен диалог с пользователем, и пусть он сразу загружает все, но отдавать ему на редактирование только частями. И делать это можно сразу при приеме документа, а работа на ошибками, это асинхронный диалог с сервером, и пользователю наглядно понятно статус обработки, и ошибок меньше. Ну или потом редактирование частями, правда в этом случае "редактирование", по идее, должно подразумевать нечто иное, например, удаление или добавление одного (нескольких) номеров, редактирование самого номера и т.п..

  Ответить  
 
 автор: Саня   (13.04.2013 в 23:42)   письмо автору
 
   для: Filsh   (04.04.2013 в 15:25)
 

Вы уверены, что узкое место именно регулярка? Поставьте замеры времени выполнения и потребления памяти в контрольных точках скрипта. Таким образом можно понять какой кусок кода выполняется медленнее всего или потребляет большее количество памяти (или и то, и другое вместе). И тогда можно будет сужать область поиска — расставлять больше контрольных точек в транжирящем ресурсы куске кода. В итоге найдётся бутылочное горлышко, которое требует оптимизации.

PS
Международный код Украины всё же 380, а не 38 :)
Поправьте, иначе есть риск принять сербские (код 381), черногорские (382), хорватские (385) и ещё некоторе другие номера за украинские.

  Ответить  
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования