• Бенчмарк HTML парсеров

      Переписывал в островке кусок одного сервиса с Python на Erlang. Сам сервис занимается тем, что скачивает по HTTP значительное количество однотипных HTML страниц и извлекает из них некоторую информацию. Основная CPU нагрузка сервиса приходится на парсинг HTML в DOM дерево.

      Сперва захотелось сравнить производительность Erlang парсера mochiweb_html с используемым из Python lxml.etree.HTML(). Провел простейший бенчмарк, нужные выводы сделал, а потом подумал что неплохо было бы добавить в бенчмарк ещё парочку-другую парсеров и платформ, оформить покрасивее, опубликовать код и написать статью.
      На данный момент успел написать бенчмарки на Erlang, Python, PyPy, NodeJS и С в следующих комбинациях:
      • Erlang — mochiweb_html
      • CPython — lxml.etree.HTML
      • CPython — BeautifulSoup 3
      • CPython — BeautifulSoup 4
      • CPython — html5lib
      • PyPy — BeautifulSoup 3
      • PyPy — BeautifulSoup 4
      • PyPy — html5lib
      • Node.JS — cheerio
      • Node.JS — htmlparser
      • Node.JS — jsdom
      • C — libxml2 (скорее для справки)

      В тесте сравниваются скорость обработки N итераций парсера и пиковое потребление памяти.

      Интрига: кто быстрее — Python или PyPy? Как сказывается иммутабельность Erlang на скорости парсинга и потреблении памяти? Насколько быстра V8 NodeJS? И как на всё это смотрит код на чистом C.
      Читать дальше →
    • Так как же удалить миллионы файлов из одной папки?


        Феерическая расстановка точек над i в вопросе удаления файлов из переполненной директории.

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

        Для тех, кто не в курсе проблемы, краткое описание: если вы случайно создали в одной директории огромное количество файлов без иерархии — т.е. от 5 млн файлов, лежащих в одной единственной плоской директории, то быстро удалить их не получится. Кроме того, не все утилиты в linux могут это сделать в принципе — либо будут сильно нагружать процессор/HDD, либо займут очень много памяти.

        Так что я выделил время, организовал тестовый полигон и попробовал различные средства, как предложенные в комментариях, так и найденные в различных статьях и свои собственные.
        Читать дальше →
      • Самая короткая запись асинхронных вызовов в tornado v2, или патчим AST

          Меня очень заинтересовала статья Самая короткая запись асинхронных вызовов в tornado или патчим байткод в декораторе, не столько с практической точки зрения, сколько с точки зрения реализации.
          Всё-таки модификация байткода в рантайме это слишком опасная и ненадежная операция. И уж наверняка не поддерживаемая альтернативными интерпретаторами Python.

          Попробуем исправить этот недостаток способом, который для этого предназначен куда больше и который применяется для схожих целей во многих других языках (я точно встречал в Lisp или Erlang). Этот способ — модификация Абстрактного синтаксического дерева (AST) программы.
          Читать дальше →
          • +31
          • 3,8k
          • 4
        • Уязвимость в стандартной функции glob() как угроза для FTP-серверов

            Сайт SecurityReason сообщает об обнаружении опасной ошибки в реализации библиотечной функции glob() из стандартной библиотеки языка C (libc) на множестве платформ.

            Эта функция предназначена для получения списка файлов, чьи имена удовлетворяют заданному шаблону. Ошибка заключается в том, что ограничение на выдачу функции, задаваемое переменной GLOB_LIMIT, не действует в случае задания некорректных путей в шаблоне. Такими некорректными значениями могут быть, например, «*/../*/../*foo» или «{..,..,..}/*/{..,..,..}/*bar». При этом вызов функции glob() может исчерпать всю доступную память процесса.

            Особенную опасность данная ошибка представляет для (S)FTP-серверов, особенно с разрешенным анонимным доступом. Очевидно, запрос на листинг файлов с вышеприведенной маской приводит к скорому отказу в обслуживании FTP-сервера.

            Уязвимости подвержены, по последним данным, как минимум следующие ОС: OpenBSD 4.7, NetBSD 5.0.2, FreeBSD 7.3/8.1, Oracle/Sun Solaris 10, а также все версии Linux с GLIBC. Уязвимость пока что устранена только в NetBSD; компании и сообщества, занимающиеся разработкой вышеперечисленных (за исключением NetBSD) операционных систем, пока не дают никакой информации; именно поэтому уязвимость классифицируется как «0-day». Сообщается также, что vsftpd не подвержен уязвимости.

            Желающим попробовать уязвимость в действии могу предложить набрать в bash консоли команду наподобие
            ls ../../*/../*/*/../../*/*/*/*

            Можно эксплуатировать, например, из PHP:
            php -r 'print glob("../../*/../*/*/../../*/*/*/*");'

            или Python
            python -c 'import glob; glob.glob("../../*/../*/*/../../*/*/*/*")'
            и из любого другого языка, обращающегося к этой функции.

            Оригинальный отчет об уязвимости тут: securityreason.com/securityalert/7822