Python-сообщество

alexx11
o7412369815963 О! респект и уважуха что разобрался, а теперь ответь на вопрос пожалуйста, если не sleep а поиск из массива вставить, ну как из предыдущего примера, то второй клиент зависнет или нет?

Time taken for tests:   62.128 seconds
Time per request:       6212.754 [ms] (mean)

Concurrency Level:      5
Time taken for tests:   31.933 seconds
Complete requests:      5
Failed requests:        3
   (Connect: 0, Receive: 0, Length: 3, Exceptions: 0)
Write errors:           0
Total transferred:      1103 bytes
HTML transferred:       153 bytes
Requests per second:    0.16 [#/sec] (mean)
Time per request:       31932.981 [ms] (mean)
Time per request:       6386.596 [ms] (mean, across all concurrent requests)
Transfer rate:          0.03 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    4   3.0      6       6
Processing: 25680 30679 2794.1  31927   31932
Waiting:     6368 21794 9707.2  25678   31927
Total:      25681 30682 2796.0  31933   31933

Concurrency Level:      5
Time taken for tests:   13.177 seconds
Complete requests:      5
Failed requests:        1
   (Connect: 0, Receive: 0, Length: 1, Exceptions: 0)
Write errors:           0
Total transferred:      1104 bytes
HTML transferred:       154 bytes
Requests per second:    0.38 [#/sec] (mean)
Time per request:       13177.003 [ms] (mean)
Time per request:       2635.401 [ms] (mean, across all concurrent requests)
Transfer rate:          0.08 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    8  11.6      8      25
Processing: 11740 12729 571.6  12962   13160
Waiting:    11740 12724 569.3  12953   13152
Total:      11741 12737 575.8  12962   13177

Concurrency Level:      2
Time taken for tests:   5.734 seconds
Complete requests:      2
Failed requests:        1
   (Connect: 0, Receive: 0, Length: 1, Exceptions: 0)
Write errors:           0
Total transferred:      441 bytes
HTML transferred:       61 bytes
Requests per second:    0.35 [#/sec] (mean)
Time per request:       5734.235 [ms] (mean)
Time per request:       2867.117 [ms] (mean, across all concurrent requests)
Transfer rate:          0.08 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:  4866 5300 614.0   5734    5734
Waiting:     4866 5300 614.1   5734    5734
Total:       4866 5300 614.1   5734    5734

Concurrency Level:      5
Time taken for tests:   13.482 seconds
Complete requests:      5
Failed requests:        0
Write errors:           0
Total transferred:      1105 bytes
HTML transferred:       155 bytes
Requests per second:    0.37 [#/sec] (mean)
Time per request:       13481.948 [ms] (mean)
Time per request:       2696.390 [ms] (mean, across all concurrent requests)
Transfer rate:          0.08 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       1
Processing: 12058 12598 596.2  12682   13481
Waiting:    12058 12595 591.6  12682   13469
Total:      12059 12598 596.3  12682   13482

Concurrency Level:      10
Time taken for tests:   27.046 seconds
Complete requests:      10
Failed requests:        1
   (Connect: 0, Receive: 0, Length: 1, Exceptions: 0)
Write errors:           0
Total transferred:      2209 bytes
HTML transferred:       309 bytes
Requests per second:    0.37 [#/sec] (mean)
Time per request:       27045.770 [ms] (mean)
Time per request:       2704.577 [ms] (mean, across all concurrent requests)
Transfer rate:          0.08 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   14  11.1     12      28
Processing: 12530 22150 5626.7  25048   27043
Waiting:    12017 18411 5398.7  19916   27017
Total:      12559 22164 5626.2  25060   27045

И всё таки она крутится =) Значит несмотря на GIL можно вполне спокойно жить, и наслаждаться многозадачностью.

Дался вам этот GIL. Чаще всего его ругают те, у кого собственные руки кривые.

и вообще говорят gil есть во всех интерпретаторах (хотя это не так), но только питоновский ставят ребром и пытаются его улучшить.

Андрей Светлов
Дался вам этот GIL. Чаще всего его ругают те, у кого собственные руки кривые.

wikipedia
При своей работе основной интерпретатор Python постоянно использует большое количество потоково-небезопасных данных.

задался вопросом, повторить эксперимент с многопоточностью.
И выяснилась, одна неприятная весчь.
Конечно, тредов можно наплодить, НО процесс который их держит будет работать на одном ядре/процессоре.
Т.е. на четырех ядерном процессоре, mod_wsgi приложение в 4 потока будет работать, так будто доступно только одно ядро из четырех.

Да! Можно запустить четыре процесса, в каждом из которых будет несколько тредов, но в таком случае, расход памяти увеличится (каждый процесс будет кушать память отдельно)
Память для кеширования придется вывести из памяти процесса, так как кеш не будет общим для тредов из разных процессов.

Пробовал:
apache2 + mod_wsgi
nginx + mod_uwsgi
rocket (python based webserver)

Поправьте меня.
Расскажите как сделать чтобы треды в wsgi использовали бонус многопроцессорности.

> но в таком случае, расход памяти увеличится (каждый процесс будет кушать память отдельно)
нет, грубо говоря - память кушают треды, а не процессы.

> Память для кеширования придется вывести из памяти процесса, так как кеш не будет общим для тредов из разных процессов.
для этого есть мемкеш и подобные, и можно вывести не только из памяти процесса, но и из памяти сервера. т.е. на другой хост. например так использую при большой нагрузке, веб приложение запускают на нескольких серверах и у них ест общий “мемкеш”.

При маленькой нагрузке можно использовать обмен через БД.

> Расскажите как сделать чтобы треды в wsgi использовали бонус многопроцессорности.
На каждом ядре висят процессы, при появлении запроса на wsgi треде, раздаем всем процессам задачи. Но для веба это не нужно. Веб - это интерфейс. А тяжелую нагрузку отдаем “фоновому роботу” который не wsgi.

Спасибо за ответ.

o7412369815963
>
> Расскажите как сделать чтобы треды в wsgi использовали бонус многопроцессорности.
На каждом ядре висят процессы, при появлении запроса на wsgi треде, раздаем всем процессам задачи. Но для веба это не нужно. Веб - это интерфейс. А тяжелую нагрузку отдаем “фоновому роботу” который не wsgi.

Отредактировано (Июнь 17, 2011 07:53:17)

Термин “high-load” обычно относят к нагрузке от наплыва пользователей, большого кол-ва обращений. А мы здесь начали говорить о том как проц. загрузить - например можно запустить архивирование dvd фильма.

>А где можно узнать подробнее про отдачу фоновым роботам
Я в некоторых проектах использую xml-rpc, в некоторых “общение через базу”. При этом wsgi приложение не висит и ждет, а отрабатывает за 0,001сек - выводить текущий статус задачи/ процент выполнения.

> Хочу придумать high-load велосипед,
Сначала нужно определиться с целью (проектом).

Например то же архивирование dvd:
1) Прилетел запрос в wsgi, запускаем .sh скрипт, клиенту возвращаем “идет запуск”.
2) Этот скрипт в файлик пишет “идет архивирование” и запускает многопоточный архиватор, который грузит все ядра. После окончания архивирования, скрипт пишет в файлик “завершено”.
3) При очередном обращении клиента (можно по таймеру авторефреш страницы), wsgi приложение отдает содержимое файлика.

В итоге получили то что вы хотели: клиент зашел на страницу, жмякнул кнопку - на сервере пошла нагрузка всех ядер, клиенту на экран выводится состояние обработки.

o7412369815963
Термин “high-load” обычно относят к нагрузке от наплыва пользователей, большого кол-ва обращений. А мы здесь начали говорить о том как проц. загрузить - например можно запустить архивирование dvd фильма.

o7412369815963
>А где можно узнать подробнее про отдачу фоновым роботам
Я в некоторых проектах использую xml-rpc, в некоторых “общение через базу”. При этом wsgi приложение не висит и ждет, а отрабатывает за 0,001сек - выводить текущий статус задачи/ процент выполнения.

Отредактировано (Июнь 17, 2011 15:09:28)