crower: (Default)
UPD. Решил почистить лишнюю лирику и оставить самый навар.

WWW::Curl документирован слабовато и большей частью отсылает на сайт курловой документации.

Чтобы заюзать NTLM-авторизацюи надо сделать:

$curl->setopt(CURLOPT_HTTPAUTH, CURLAUTH_NTLM);


Для простого POST с передачей параметров в теле запроса не надо пользоваться WWW::Curl::Form, как можно было бы подумать, глядя в доку. Нужно:

$curl->setopt(CURLOPT_POSTFIELDS, $data);
$curl->setopt(CURLOPT_POSTFIELDSIZE, length($data));
$curl->setopt(CURLOPT_POST, 1);

Если использовать WWW::Curl::Form, то курл будет заворачивать каждый параметр в отдельный Content-Disposition. Соответственно, это и накладные расходы, и не факт что CGI умеет их отттуда извлекать.
Хотя, зачем вручную считать размер мне не понятно. Почему это не мог бы сделать сам курл?
crower: (Default)
Ох и люблю же я что-нибудь такое сделать, чтобы ничего не делать. :) Ну, почти ничего не делать. Т.с.
воспользоваться былыми результатами повторно. :)

Есть на станции такие файлы, в которые она сохраняет команды между дампами. Зовут их RELCMDHDF, если что.
Новые создаются при каждом дампе, старые становятся не нужными и если специально не пошевелиться, плодятся годами. Место поедают, конечно, но файлы, в общем-то, не большие. Впрочем, технология выделения дискового пространства там чуточку другая, из-за чего места занимать они могут гораздо больше, чем реально используют. Если станция не сильно старая, то проблема нехватки места может так и не наступить. Скорее станцию заменят. :D
Но вот в рамках эксплуатации могут возникать сложности. Работает там конструкция типа кластера и в случае смены активного узла происходит синхронизация дисков. Сначала будет попытка сделать быстрый апдейт - только того, что изменилось после того как узел находился в забытьи. Если не получилось и процесс затягивается, то происходит переключение на длинный апдейт, то есть тупая синхронизация всего подряд, чуть ли не по кластерам. И чем больше всяких файлов валяется, тем вероятнее переключение на длинный процесс. Поэтому много лет назад, приехавший настройщик, тяжело вздохнут собрался поудалять древние файлы. Хорошо что он ленился. Я тогда про них ещё ничего не знал, а как узнал какое богатство собираются удалять, спохватился и уговорил что сам всё сделаю. Товарищ, конечно, обрадовался, потому что автоматизировать рутинные операции не умел, а команд вводить пришлось бы долго. А тут ему предлагают ничего не делать, но работа при этом сделается. В итоге, файлы эти я скачал, и только после этого удалил те что надо. Потом уже сделал нужные настройки, чтобы станция сама эти файлы и через даталинк отправляла, и удаляла старые. В результате получил архив вносившихся в станционные данные изменений. Зачем? Очень удобно отыскивать когда нечто делалось. Например, возникает вопрос: имеется странный маршрут, зачем и почему он сделан таким? Идеальным был бы электронный журнал, хоть и требовал бы дополнительных телодвижений на протоколирование всего подряд. Но начиналась эта работа слишком давно. Есть два шкафа толстых папок распоряжений, по которым эти изменения вносились. Но когда? И вот тут на помощь приходит RELCMDHDF.
Долгое время пользовался простым grep-ом. Потом прикрутил врапер для удобства. Со временем к враперу прикрутил отыскивание по TRLOG1FILE, в который вообще все диалоги со станцией пишу. Собирался было прикрутить скрипт на веб-страницу, но задумался … и решил, что нужно грузить всё это в БД. Глаза боятся, а руки делают.
В результате получил возможность быстрого поиска, удобного доступа (и не только мне), и сводной таблицы.
Сотрудники тоже оценили фичу. Теперь даже непонятно как можно было без этого обходиться. :)

И вот ещё одна станция оказалась под рукой. Всё ходил вокруг неё, облизывался. Вот только в отличие от нашей, доступа к даталинку нет. А без него файлы качать только через IOFAT. А это не совсем файлы. Точнее, чтобы получить оригинал, нужно его обработать. Старые командники оттуда таким образом я уже давно вытащил. Нужное искал обычным грепом, но это же оскорбляет эстетическое чувство. И вот вчера наконец набросал конвертилку из IOFAT в оригинальные файлики. Таблицы в базе, оказывается, я уже давно сделал и даже скрипты готовы. Так что осталось это дело только загрузить. Класс! Теперь только нюансы отлаживаю. То командные строки оказываются чрезмерно длинные. То внутриблочные счётчики команд решил вернуть.

В общем, сделал один раз, а удовольствие приносит многократно.
crower: (Default)

С оптимизацией получился облом.

Напомню, что была попытка соптимизировать запрос с select ... where date(field) in (...) group by .... Я в курсе, что конструкция field in (...) сама по себе дорогая, но вполне приемлема, если потеря скорости незначительна, а альтернатива может оказаться ещё дороже.

В моей ситуации потеря скорости оказалась слишком велика, чтобы её игнорировать.

Попробовал другое "дешёвое" решение — внедрить ограничение диапазона, где код where date(field)≥{min_time} and date(field)<{max_time} призван был сократить первоначальную выборку, и уже после этого работал бы var in (...). Нужно было планчик составить, но лениво. А потом оказалось что и var in лишний. С выборкой нужных дат в самом скрипте всё оказалась гораздо быстрее. И поначалу всё заработало как надо. И дело даже не в кешировании. Потому как регулярно, раз в час поступают новые данные.

Эффект был кажущимся из-за того, что на момент тестирования дат было не так много и group by на все эти даты не сильно тормозил. Но наступление события "С", ради которого весь этот сыр-бор, задержалось. И получилось что между первой и последней датой времени прошло настолько много, что быстродействие от экономии на отказе от var in полностью пожралось group by. Долгим и бессмысленным.

Ещё бы:

  • 4 таблицы: 1.2млн, 1.3млн, 26млн и 27млн записей.
  • интересующие данные (без уточнения по дате) составляют 64К, 10К, 130К и 20К записей.
  • в таблицах сидит timestamp, а выборку и результат нужно делать от функции по нему. Хоть через substr, хоть по date.

Можно было плюнуть и вернуться к старой схеме, но "мы не привыкли отступать"© и это оскорбляет эстетическое чувство.

Поэтому пришлось делать красиво и по-полной схеме. При обращении к странице, скрипт запрашивает данные, уже сгруппированные по дате и лежащие в специальной дочерней таблице. Если на определённую дату данных нет, то запрашиваются данные в родительской таблице. Если они оказываются полными за указанную дату (24 часа, 1440 минут или 86400 минут), то они вставляются в дочернюю таблицу и в следующий раз будут извлекаться оттуда. Считать их заново будет не нужно. Операция сия была необходима для одного определённого объекта, так что пухнуть дочерние таблицы не будут. При периодическом опросе данные за прошедшие дни обстчитываются постепенно, и только за текущий - постойнно. В результате подтормаживание составляет при пересчёте прошедших суток считанные доли секунды, а за текущую дату - даже не заметно. Всё-таки выборка по timestamp ≥ {time} and (timestamp < {time} + INTERVAL 1 DAY) гораздо быстрее, чем упоминавшиеся ранее конструкции. Да и group by нужно будет убрать, т.к. алгоритм и ткак каждый раз выдёргивает по одной строке.

Зато теперь всё классно. :)

crower: (Crower)
    Вот такой получился оптимизированный скрипт по вытаскиванию номерных диапазонов и конвертации их в CSV. Для дальнейшей загрузки в БД.
#!/bin/bash
proxy=http_proxy=http://bla-bla-bla/
 
date=`date +%Y%m%d`
opt='--header=Accept-Encoding:gzip'
 
for file in ABC-3 ABC-4 ABC-8 DEF-9
    do
    wget $opt -e $proxy http://www.rossvyaz.ru/docs/articles/${file}x.html -O ${file}x_$date.html.gz
    gzip -d -c ${file}x_$date.html.gz                                         | \
        sed -e "s/\s\?<\/td>\s\s\?/;/g;s/\s\s\?//;s/\s\?<\/td>\s<\/tr>\s\?//" | \
        grep -v "<"                                                           | \
        iconv -f windows-1251 &gt; txt/${file}x_$date.txt
    done

    В результате грузится вместо 22 метров полтора и не 6 минут, а менее полуминуты. Да, да - в телекоммуникационной компании с интернетом очень туго. Доступ получить - надо писать заявку и обосновывать нафига оно надо. В цехе одно рабочее место с доступом в инет есть - вот садись и выкачивай. Но:

  • (1) жутко тормозит,

  • (2) на винде,

  • (3) права на винду у айтишников и левого туда ни-ни,

  • (4) к корпоративным проксям доступ получить можно только через домен,

  • (5) диапазоны нужны на технологическом оборудовании, в технологической сети, отделённой от корпоративки файерволом, а этот инетовый комп включен в корпоративку,

  • (6) воткнуть usb в комп с инетом не получился "благодаря" политике безопасности,

  • (7...) почтой? Лотусовой? без клиента? лотус, правда, сносят в пользу мсэксченджа, но опять - чей экаунт там светить, кто будет клиетна устанавливать...

  • ... и ещё куча всякого геморроя.

  •     В итоге куда проще сделать левый тонкий канал.    
    За компанию обидно. :(
crower: (Crower)
Давным давно (лет 15 назад) были отсканены конспекты лекций. Качество мерзкое. Страницы просвечиваются насквозь. На оригинале некоторые записи читались очень плохо, а на скане и того хуже. Несколько раз принимался вычитывать, но стоило отложить, как вычитка куда-то девалась, забывалась и в следующий раз всё по-новому. А тут есть mediawiki-сервер, как-то собирал уже сканы (SgKP) в djvu - почему бы вычитку туда не перенести. И вычитывать удобно, и результаты не потеряются. Сейчас как раз потихоньку вычитываю одни ТУ. В оригинале они в десятке pdf и в случае чего искать очень неудобно.

В общем взялся за конвертацию конспектов и завяз. Оказывается формат оригинальных сканов (tif) тулзами так просто не читается. Помучился, повычислял дерево взаимосвязей и собрал:
#!/bin/bash
for ((i=1;i<=97;i++))
   do
   n=`printf "%03d" $i`
   echo $n
   tifftopnm $n.tif | pnmtojpg > $n.jpeg
   cpaldjvu $n.jpeg $n.djvu
   done

Ну и как положено в конце:
djvm -c Lectures.djvu 0*.djvu


Готово. Загружаем на сервер, генерим индекс и теперь можно хоть вмногером вычитывать.

Profile

crower: (Default)
crower

July 2017

S M T W T F S
      1
23 45678
910111213 1415
161718 19202122
23242526272829
3031     

Syndicate

RSS Atom

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 22nd, 2017 12:36 pm
Powered by Dreamwidth Studios