Analitycs

Показаны сообщения с ярлыком тесты. Показать все сообщения
Показаны сообщения с ярлыком тесты. Показать все сообщения

пятница, 24 февраля 2012 г.

Tornado AsyncHTTPTestCase: AssertionError: Async operation timed out after 5 seconds

Тестирование в Торнадо (особенно асинхронных сервисов) имеет много неочевидных нюансов.

Ситуация

Если ваш сервис внутри асинхронных обработчиков сам создает асинхронные задачи - например, для того чтобы забрать что-то с внешнего сервиса - в стиле

class MyAsyncHandler(tornado.web.RequestHandler):

    @tornado.web.asynchronous
    def get(self, *args, **kwargs):
        try:
            # тут чего то берем с внешнего сервера
            self.auth_request({})
        except Exception, ex:
            self.error('Async - %s'%ex)
            self.reply(None)


    def auth_request(self, params, callback=None):
        url = self.application.settings['external_service'] + '?' + urlencode(params)

        if not callback:
            callback = self._on_load

        http = httpclient.AsyncHTTPClient()
        http.fetch(url, callback, validate_cert=False)

    def _on_load(self, response):
        # обрабатываем полученные результат        
        pass

То при написании юнит-тестов через AsyncHTTPTestCase в подобном ключе по официальной документации(!!!)

class MyTestServer(AsyncHTTPTestCase):
    def get_host(self):
        return 'http://%s:%d'%(SERVER['host'], SERVER['port'])
    
    def get_app(self):
        myserver = MyServer()
        myserver.run(SERVER['host'], SERVER['port'])        

        return myserver.app # приложение Tornado
    
    def get_response_obj(self, url, **kwargs):
        if len(kwargs) > 0:
            url += '?' + urllib.urlencode(kwargs)
        
        logging.info('Request [%s]'%url)

        self.http_client.fetch(url, self.stop)
        response = self.wait()
        
        print response

        if response.body: 
            return response.body
        
        return None

При запуске тестов начинаем ловить потрясающие спецэффекты,

Traceback (most recent call last): 
  File "/home/xxxx/test_wait.py", line 9, in test_1 
    self.wait(timeout = 5) 
  File "/xxxxx/site-packages/tornado/ 
testing.py", line 169, in timeout_func 
    timeout) 
AssertionError: Async operation timed out after 5 seconds 

Лечится это добавлением в класс теста переопределенного метода get_new_ioloop

class MyTestServer(AsyncHTTPTestCase):
    ....
    
    def get_new_ioloop(self): 
        return ioloop.IOLoop.instance()  

Такие дела...

Тема в гуглогруппеGist с примером

вторник, 27 декабря 2011 г.

Twisted или Tornado - без разницы - все идиоты

Внимание - Важное сообщение для блоггеров-питонистов!


Если у вас появилась блестящая идея попробовать новый сфероконический тест, который показывает как Tornado уделывает Twisted - то выдохните. Выключите компьютер, погуляйте на улице и заодно - пересмотрите главную цель вашей жизни. Интернету не нужен еще один бессмысленный график производительности.

Похоже, что уже всем стало ясно что "матч века" - Twisted.web против Tornado от Friendfeed показал, что ни одна из сторон не особо победила, но и не особо проиграла - и в тоже время стопудово - что обе стороны выглядят достаточно глупо.


Во-первых, Twisted. Сейчас моя компания использует его за небольшую часть функциональности, потому что ТОГДА - это был самый простой способ, что мы нашли для отправки трафика через различные сетевые интерфейсы на Linux машинах. Мы никогда не имели с ним никаких проблем. Единственная причина, по которой мне необходимо его когда-нибудь тронуть - это чтобы увидеть, как что работает.

Тем не менее, Twisted, вероятно, самая запарная программная библиотека. Каждый раз, когда я открываю этот код, я чувствую, что я забрел в ночной бар на берегу Джерси, где все пьяные в хлам и уже давно сорвали свои рубашки. Twisted классная библиотека, но в тоже время - НЕДОСТАТОЧНО классная, чтобы действительно называться "Twisted". Это Python- программистская версия одежды и бейсболок Ed Hardy, которая все еще висит в стороне (модная вещь, которая не используется). Когда я копался в этом коде и мои коллеги спрашивают меня, что случилось, единственным адекватным ответом было я "НЕ СЕЙЧАС, шеф - я запускаю этот хренов реактор ".

Теперь вы можете понять, почему появилась и существует такая хрень, как Tornado.

Хотя я постоянно не рекомендую делать такие вещи как Tornado - Friendfeed все-таки ее сделали. Из тех графиков, которые я видел, Tornado просто незначительно быстрее, чем Twisted на обслуживании большого количества одновременных запросов. НЕЗНАЧИТЕЛЬНО. Очевидно, в Friendfeed полагали, что достаточно небольшая разница в скорости была достаточным основанием тратить свое время и что-то переписывать заново- что обычно и делает каждый разработчик, которому становится скучно на работе. Веб-фреймворк на Python? О боже - как это оригинально! Я думаю, что это один из последних уроков книжки "Изучи Python за 24 часа".

В Friendfeed потратили много времени, пытаясь оптимизировать количество запросов в секунду, отображаемого на графике, но, возможно, им следовало бы тратить больше времени на оптимизацию ВОТ ЭТОГО графика - вместо первого:

Во всяком случае, когда речь идет о выборе Twisted vs Торнадо для веб-фреймворка, я использую Django. Почему? Потому что это работает, и мое время ценно.

Достаточно вольный перевод вот этой заметки. Спасибо автору

Кстати, достаточно интересно пишет, хотя и многие слова приходится долго думать - перед тем как перевести на русский.

воскресенье, 25 декабря 2011 г.

Как оптимизировать сервер? - реальные данные - теория без практики мертва

Это судьба - вслед за вчерашней заметкой про оптимизацию выделенного сервера на сайте были опубликованы весьма интересные материалы, которые привели к росту просмотров страниц на 54 тысячи - это составляет рост примерно 140%.

Итак, график LI

Скачок достаточно большой, но давайте посмотрим, как машина, настроенная по описанным ранее методикам с этим справилась - на графиках Munin еще видны вчерашние значения, так что можно сравнить с ними (хотя бы на глаз).


Трафик, прокачанный через firewall - разумеется, вырос, причем - значительно



Процессы и потоки - увеличились



MySQL немного изменился в пределах погрешности; коннекты - не изменились.





Memcache немного подрос, но незначительно


А самое главное - ЦПУ и Load Average практически не изменились

Вывод

nginx с кешом HTML страниц сильно спасает от резких скачков нагрузки от незарегестрированных пользователей.

Рискну предположить, что создатели многих супер-пупер-мега-стартапов, постоянно падающих от пресловутого великого и ужасного Хабраэффекта, об этом не знают ;-)

З.Ы. Люблю, когда теоретические выкладки подтверждаются практическими данными.


вторник, 25 октября 2011 г.

Сравнение нагрузки PyCurl vs HTTPClientFactory+Deferred в сервисе на Twisted

Решил перевыложить с хабры свое небольшое старое исследование по поводу производительности Twisted при использовании  PyCurl и HTTPClientFactory - пусть лежит все в одном месте, раз уж начал активно писать в блог.

В процессе разработки одного проекта на Python+Twisted (распределителя запросов между несколькими СМС гейтами Kannel) пришлось переписать вызов URL различных сервисов с разных серверов c блокирующего вызова через PyCurl на неблокирующий (client.HTTPClientFactory + deferred). Чтобы иметь перед глазами реальные данные о нагрузке, решил дать много запросов и посмотреть на результаты

Описание теста

Использовался Jakarta/Apache Jmeter - очень полезная софтинка, к сожалению, почему-то применяют ее для тестов достаточно редко (может, просто не знают о ее существовании?), но мне она весьма нравится - ибо возможности у нее большие и даже краткое описание наврядли влезет в несколько постов - если кому интересно, могу потом пробежаться по ней вкратце.
В 200 потоков прогнано 100 запросов на один и тот же сервер, но со случайными данными (чтобы исключить кэширование). Прогонялось на обыкновенной рабочей машине с GUI под Ubunta — так, для примерной оценки.

Результаты теста

Одна ошибка — не справилась база, так что погрешностью можно пренебречь.

Графики распределения

Блокирующий (PyCurl)
Неблокирующий (deferred)

Итоги

Как видно из результата теста — при одинаковой нагрузке при использовании defered минимальное значение отклика сервера почти в 2.5 раза меньше (из-за отказа базы), а максимальное — меньше в два раза, чем у блокирующего. Среднее значение - также меньше в 2 раза.

Америку я, конечно, не открыл, но по-крайней мере — теперь на руках конкретные цифры по производительности. Надеюсь, кому-нибудь они пригодятся.