Сориентируйте по производительности
Имеет смысл ковырять дальше или больше не выжму?Ковырять-то понятно что, вопрос зачем это надо, сколько времени не жалко и т.п.
Скажем так, если я уже достиг 80% возможного и дальше я буду оставшиеся 20% получать все более непропорциональным геморроем, то больше не надо. Здесь мне хотелось бы оценить как раз, где я нахожусь. Интерес уже скорее спортивный и исследовательский, потому что заданные мне параметры пиковой нагрузки я обеспечу на этой машине балансировщиком нжинкса и 4-5 процессами-обработчиками
Дальнейший геморрой имхо выйдет дороже еще одной железки.
У тебя сейчас epoll на epollе, можно написать модуль к nginxу и выпилить питон вовсе. Можно на lua, можно на перле или с++, можно свой костыль вместо нгинкса написать. Наверно еще можно системные настройки ковырять.
У тебя сейчас epoll на epollе, можно написать модуль к nginxу и выпилить питон вовсе. Можно на lua, можно на перле или с++, можно свой костыль вместо нгинкса написать. Наверно еще можно системные настройки ковырять.
потыкай perf, если конечно в диск ты не упёрся. python вполне может стать узким местом.
Окей, всем спасибо
если конечно в диск ты не упёрсяЧойто не понял что такого он должен писать в лог чтоб упереться в диск.
В диск, да, вряд ли. Разве что драйвер какой-нибудь generic вдруг и работает как-то "неоптимально". На вход поступает не более 128*3+4~400 байт. В лог пишется не более 500 байт на запрос. В среднем же раза в три-четыре меньше.
смотря как и куда писать. если логов много и на каждый звать fsync то легко
ещё можно позвать fallocate и саллоцировать много места за концом файла — тогда аппенд будет всегда быстрым.
ещё можно позвать fallocate и саллоцировать много места за концом файла — тогда аппенд будет всегда быстрым.
Ты с ВМК?
Если только debi-an не сотворил очередной идиотизм, то затык,
если есть, в этом:
> python wsgi-приложение
Вынеси питон к чёрту и замени его плюсами. Если у тебя
приложение действительно простое, как ты утверждаешь,
это не должно быть сложно.
Проверить пропускную способность диска не настолько сложно: man dd, man time.
Не знаю, как в твоём линуксе, в операционных системах ps(1) и top(1)
дают немного понять, что происходит с процессом. Опять же, если подозреваешь
диск, перенеси файл на mfs и отключи подкачку.
Вообще, если ты ничего не скрыл, проверить пропускную способность твоих подсистем
довольно просто: переделать твой скрипт, чтобы он просто считал число пришедших запросов,
заставить тот же скрипт постоянно писать одно и то же значение в лог, без wsgi,
написать такую же прогу на сях, проверить, сравнить, приделать к ней регулярные выражения,
проверить, сравнить, и т.д. Быстрее будет самому сделать, если это действительно важно.
---
"Истина грядёт --- её ничто не остановит!"
если есть, в этом:
> python wsgi-приложение
Вынеси питон к чёрту и замени его плюсами. Если у тебя
приложение действительно простое, как ты утверждаешь,
это не должно быть сложно.
Проверить пропускную способность диска не настолько сложно: man dd, man time.
Не знаю, как в твоём линуксе, в операционных системах ps(1) и top(1)
дают немного понять, что происходит с процессом. Опять же, если подозреваешь
диск, перенеси файл на mfs и отключи подкачку.
Вообще, если ты ничего не скрыл, проверить пропускную способность твоих подсистем
довольно просто: переделать твой скрипт, чтобы он просто считал число пришедших запросов,
заставить тот же скрипт постоянно писать одно и то же значение в лог, без wsgi,
написать такую же прогу на сях, проверить, сравнить, приделать к ней регулярные выражения,
проверить, сравнить, и т.д. Быстрее будет самому сделать, если это действительно важно.
---
"Истина грядёт --- её ничто не остановит!"
заставить тот же скрипт постоянно писать одно и то же значение в лог, без wsgi,Это долгий путь и он не гарантирует какой-либо достоверности получаемого результата, особенно если постоянно какие-то факторы упускаются (не замечаются).
написать такую же прогу на сях, проверить, сравнить, приделать к ней регулярные выражения,
проверить, сравнить, и т.д. Быстрее будет самому сделать, если это действительно важно.
Лучше двигаться от общих оценок, например, от оценок:
сколько максимум байт в секунду может обработать процессор,
сколько максимум байт в секунду может быть считано/записано в память,
сколько максимум можно байт записать на диск в секунду,
сколько максимум байт в секунду может быть считано с сети и т.д.
Дальше оцениваются эти факторы для своей задачи, рассчитывается, что из этих факторов является определяющим (bottleneck-ом и ищутся причины в следствии которых максимум не был достигнут на определяющих факторах.
3) обрабатывается около 7000 запросов в секундуЧем это значение у тебя сейчас лимитируется?
Процессор загружен на 100%?
Процессы не успевают быстрее переключаться?
что-то еще?
Вынеси питон к чёрту и замени его плюсами. Если у тебя
приложение действительно простое, как ты утверждаешь,
это не должно быть сложно.
Проверить пропускную способность диска не настолько сложно: man dd, man time.
Не знаю, как в твоём линуксе, в операционных системах ps(1) и top(1)
дают немного понять, что происходит с процессом. Опять же, если подозреваешь
диск, перенеси файл на mfs и отключи подкачку.
Вообще, если ты ничего не скрыл, проверить пропускную способность твоих подсистем
довольно просто: переделать твой скрипт, чтобы он просто считал число пришедших запросов,
заставить тот же скрипт постоянно писать одно и то же значение в лог, без wsgi,
написать такую же прогу на сях, проверить, сравнить, приделать к ней регулярные выражения,
проверить, сравнить, и т.д. Быстрее будет самому сделать, если это действительно важно.
можно написать модуль к nginxу и выпилить питон вовсе. Можно на lua, можно на перле или с++, можно свой костыль вместо нгинкса написать. Наверно еще можно системные настройки ковырять.
я из леса
Ответ на сообщениеТ.е. угадал правильно, ок.
На луа навряд ли получится быстрее, чем с питоном,
а вот без питона очень возможно. Причём без костылей,
костыль здесь --- питон.
---
"Истина грядёт --- её ничто не остановит!"
а вот без питона очень возможно. Причём без костылей,
костыль здесь --- питон.
---
"Истина грядёт --- её ничто не остановит!"
> Это долгий путь и он не гарантирует какой-либо достоверности
> получаемого результата, особенно если постоянно какие-то факторы
> упускаются (не замечаются).
У тебя, видимо, очень большой опыт таких оптимизаций.
Практика показывет, что даже в относительно несложных случаях
почему-то приходится обращаться именно к этому, а не к "оценкам,"
как ты предлагаешь. А уж здесь это нифига не долгий путь, учитывая
то, как данные перемещаются между компонентами.
> Дальше оцениваются эти факторы для своей задачи, рассчитывается,
> что из этих факторов является определяющим (bottleneck-ом
> и ищутся причины в следствии которых максимум не был достигнут
> на определяющих факторах.
Ты вот здесь расчитал хоть что-нибудь? Данных, вообще-то, достаточно
для первых прикидок.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
> получаемого результата, особенно если постоянно какие-то факторы
> упускаются (не замечаются).
У тебя, видимо, очень большой опыт таких оптимизаций.
Практика показывет, что даже в относительно несложных случаях
почему-то приходится обращаться именно к этому, а не к "оценкам,"
как ты предлагаешь. А уж здесь это нифига не долгий путь, учитывая
то, как данные перемещаются между компонентами.
> Дальше оцениваются эти факторы для своей задачи, рассчитывается,
> что из этих факторов является определяющим (bottleneck-ом
> и ищутся причины в следствии которых максимум не был достигнут
> на определяющих факторах.
Ты вот здесь расчитал хоть что-нибудь? Данных, вообще-то, достаточно
для первых прикидок.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
У тебя, видимо, очень большой опыт таких оптимизаций.да, большой.
Ты вот здесь расчитал хоть что-нибудь? Данных, вообще-то, достаточно для первых прикидок.В данном случае, используется стек технологий, с которым у меня малый опыт работы, и нет готовых данных по производительности каждого узкого места. Что не позволяет дать однозначный ответ, какое узкое место ограничивает производительность всей задачи, и как это место можно расшить.
Соответственно, я и предложил ТС начать оптимизацию с диагностирования, какое узкое место (из стандартных) ограничивает производительность всей задачи.
Вот это:
> да, большой.
противоречит вот этому:
> В данном случае, используется стек технологий, с которым у меня малый опыт работы
Не говоря уж о том, что по описанию понятно, что происходит внутри этого "стека технологий."
Тут даже не важно знать, что конкретно используют gevent или nginx, хоть select(2).
А уж вот это:
> и нет готовых данных по производительности каждого узкого места.
вообще весело.
Да, готовых данных нет, и что? Ты оптимизируешь по готовым табличкам?
А если их нет, то как?
> Соответственно, я и предложил ТС начать оптимизацию с диагностирования
Ты написал бред про "оценки" пропускной способности памяти,
процессора и т.д., это не считается диагностированием.
Ежу понятно, что самое большее, что можно из этого выжать,
это оценку сверху, а она никого не интересует. Это то же самое,
что оценивать скорость полёта самолёта исходя из соображений,
что он не может двигаться быстрее скорости света.
---
"Дебилы, несмотря на замедленность и конкретность мышления,
низкий уровень суждений, узкий кругозор, бедный запас слов
и слабую память, способны к приобретению некоторых знаний
и профессиональных навыков."
> да, большой.
противоречит вот этому:
> В данном случае, используется стек технологий, с которым у меня малый опыт работы
Не говоря уж о том, что по описанию понятно, что происходит внутри этого "стека технологий."
Тут даже не важно знать, что конкретно используют gevent или nginx, хоть select(2).
А уж вот это:
> и нет готовых данных по производительности каждого узкого места.
вообще весело.
Да, готовых данных нет, и что? Ты оптимизируешь по готовым табличкам?
А если их нет, то как?
> Соответственно, я и предложил ТС начать оптимизацию с диагностирования
Ты написал бред про "оценки" пропускной способности памяти,
процессора и т.д., это не считается диагностированием.
Ежу понятно, что самое большее, что можно из этого выжать,
это оценку сверху, а она никого не интересует. Это то же самое,
что оценивать скорость полёта самолёта исходя из соображений,
что он не может двигаться быстрее скорости света.
---
"Дебилы, несмотря на замедленность и конкретность мышления,
низкий уровень суждений, узкий кругозор, бедный запас слов
и слабую память, способны к приобретению некоторых знаний
и профессиональных навыков."
А если их нет, то как?Строятся по ходу, ничего сложного в этом нет, времени такое построение занимает мало, но при этом резко сокращает время оптимизации каждой конкретной задачи
Ежу понятно, что самое большее, что можно из этого выжать,если ты или еж не могут выжать большего, то это не означает, что все не могут.
это оценку сверху, а она никого не интересует.
Тут даже не важно знать, что конкретно используют gevent или nginx, хоть select(2).Если у ТС используются regexp-ы с backtracking-ом, то всё это не важно, т.к. основным узким местом будет доступ из процессора к памяти при обработке regexp-ов, а так же само использование алгоритмов backtracking-а
> Строятся по ходу, ничего сложного в этом нет, времени такое
> построение занимает мало, но при этом резко сокращает время
> оптимизации каждой конкретной задачи
А если они всю равно дают большое расхождение, то что?
Чудо, если ты страдаешь дефицитом внимания, то перечитывай то,
что ты написал. Хотя бы иногда:
DG> Это долгий путь и он не гарантирует какой-либо достоверности
DG> получаемого результата, особенно если постоянно какие-то
DG> факторы упускаются (не замечаются).
Что дадут твои таблицы, если при их построении "постоянно
какие-то факторы упускаются (не замечаются)?"
Например, каким образом ты откроешь, что нужно менять реализацию
сопоставления с регулярными выражениями? Кстати, заодно объясни,
что ты собираешься делать с обычными "безоткатными" регулярными
выражениями, если всё таки упрётся в них.
---
"Quae medicamenta non sanat, ferrum sanat,
quae ferrum non sanat, ignis sanat."
> построение занимает мало, но при этом резко сокращает время
> оптимизации каждой конкретной задачи
А если они всю равно дают большое расхождение, то что?
Чудо, если ты страдаешь дефицитом внимания, то перечитывай то,
что ты написал. Хотя бы иногда:
DG> Это долгий путь и он не гарантирует какой-либо достоверности
DG> получаемого результата, особенно если постоянно какие-то
DG> факторы упускаются (не замечаются).
Что дадут твои таблицы, если при их построении "постоянно
какие-то факторы упускаются (не замечаются)?"
Например, каким образом ты откроешь, что нужно менять реализацию
сопоставления с регулярными выражениями? Кстати, заодно объясни,
что ты собираешься делать с обычными "безоткатными" регулярными
выражениями, если всё таки упрётся в них.
---
"Quae medicamenta non sanat, ferrum sanat,
quae ferrum non sanat, ignis sanat."
А если они всю равно дают большое расхождение, то что?Значит те таблицы которые ты построил не адекватны решаемым тобой задачам.
> Что дадут твои таблицы, если при их построении "постоянно какие-то факторы упускаются (не замечаются)?"
Потому что при наличие двух оценок: нижней и верхней, с последующим их уточнением и соответствующим сближением одной с другой локализуется упускаемый фактор и точка его присутствия
> Например, каким образом ты откроешь, что нужно менять реализацию сопоставления с регулярными выражениями?
Когда таблица показывает, что есть большие разрывы между тем, что есть, и тем что должно быть.
> Кстати, заодно объясни что ты собираешься делать с обычными "безоткатными" регулярными
выражениями, если всё таки упрётся в них.
Сначала проверю, что оно действительно того стоит, а потом воткну какой-то частный генератор regexp-ов, которая по максимуму использует особенности именно данного набора регулярных выражений и возможности именно данного компьютера.
>> А если они всю равно дают большое расхождение, то что?
> Значит те таблицы которые ты построил не адекватны решаемым тобой задачам.
Это констатация факта, что делать-то собираешься?
Если ты ещё не понял, поясняю: ты потратил кучу времени на составление таблиц,
которые оказались неадекватны, код приложения при этом не изменился,
то есть производительность не поменялась, никакие альтернативные варианты
ты при этом не проверил.
>> Кстати, заодно объясни что ты собираешься делать с обычными
>> "безоткатными" регулярными выражениями, если всё таки упрётся в них.
> Сначала проверю, что оно действительно того стоит, а потом
> воткну какой-то частный генератор regexp-ов, которая по
> максимуму использует особенности именно данного набора
> регулярных выражений и возможности именного данного
> компьютера.
У тебя же оценка сверху не достигается, значит, оно того стоит,
какой "частный генератор" ты собираешься впихивать (в питон, да)
и, самое главное, почему это займёт меньше времени?
---
"Дебилы, несмотря на замедленность и конкретность мышления,
низкий уровень суждений, узкий кругозор, бедный запас слов
и слабую память, способны к приобретению некоторых знаний
и профессиональных навыков."
> Значит те таблицы которые ты построил не адекватны решаемым тобой задачам.
Это констатация факта, что делать-то собираешься?
Если ты ещё не понял, поясняю: ты потратил кучу времени на составление таблиц,
которые оказались неадекватны, код приложения при этом не изменился,
то есть производительность не поменялась, никакие альтернативные варианты
ты при этом не проверил.
>> Кстати, заодно объясни что ты собираешься делать с обычными
>> "безоткатными" регулярными выражениями, если всё таки упрётся в них.
> Сначала проверю, что оно действительно того стоит, а потом
> воткну какой-то частный генератор regexp-ов, которая по
> максимуму использует особенности именно данного набора
> регулярных выражений и возможности именного данного
> компьютера.
У тебя же оценка сверху не достигается, значит, оно того стоит,
какой "частный генератор" ты собираешься впихивать (в питон, да)
и, самое главное, почему это займёт меньше времени?
---
"Дебилы, несмотря на замедленность и конкретность мышления,
низкий уровень суждений, узкий кругозор, бедный запас слов
и слабую память, способны к приобретению некоторых знаний
и профессиональных навыков."
ты потратил кучу времени на составление таблиц,я не тратил.
> У тебя же оценка сверху не достигается, значит, оно того стоит,
Это твой вывод, а не мой или чей-то еще.
ТС, например, сразу сказал, что его устраивает 20% разрыв, если его устранение требует серьезных телодвижений.
> какой "частный генератор" ты собираешься впихивать (в питон, да)
и в чем проблема? имеющийся в питоне обработчик regexp-ов явно не на питоне написан.
> и, самое главное, почему это займёт меньше времени?
Потому что будет решаться только та задача, которая требует решения.
Например, если предложенное тобой переписывание на C++ заведомо дает совокупный эффект меньше 15% на задаче ТС, то нафига его тогда делать, исходя из условий ТС?
В общем, упирался я в проц (точнее в ядро). Манипуляции с кодом обработчиков практически ничего не приносили, так что действительно либо вообще переписывать на низкоуровневом языке, либо избавляться от звена wsgi. Либо и то и то.
Порадовало, что работа с файлом (даже переоткрывая файл каждый раз) практически не влияет на производительность всей системы в целом.
ЗЫ А что за минусомет по треду прошелся? )
Порадовало, что работа с файлом (даже переоткрывая файл каждый раз) практически не влияет на производительность всей системы в целом.
ЗЫ А что за минусомет по треду прошелся? )
>> ты потратил кучу времени на составление таблиц,
> я не тратил.
То есть, трудозатраты на составление волшебных табличек ты не учитываешь?
>> У тебя же оценка сверху не достигается, значит, оно того стоит,
> Это твой вывод, а не мой или чей-то еще.
> ТС, например, сразу сказал, что его устраивает 20% разрыв,
> если его устранение требует серьезных телодвижений.
Как ты собираешься установить по табличкам, что оно потребует "серьёзных телодвижений?"
>> какой "частный генератор" ты собираешься впихивать (в питон, да)
> и в чем проблема? имеющийся в питоне обработчик regexp-ов явно не на питоне написан.
Чем и как быстро ты собираешься его заменить?
>> и, самое главное, почему это займёт меньше времени?
> Потому что будет решаться только та задача, которая требует решения.
Задача, вообще-то, стояла увеличить пропускную способность,
а не заменить библиотеку регулярных выражений.
---
"Университет развивает все способности, в том числе и глупость."
> я не тратил.
То есть, трудозатраты на составление волшебных табличек ты не учитываешь?
>> У тебя же оценка сверху не достигается, значит, оно того стоит,
> Это твой вывод, а не мой или чей-то еще.
> ТС, например, сразу сказал, что его устраивает 20% разрыв,
> если его устранение требует серьезных телодвижений.
Как ты собираешься установить по табличкам, что оно потребует "серьёзных телодвижений?"
>> какой "частный генератор" ты собираешься впихивать (в питон, да)
> и в чем проблема? имеющийся в питоне обработчик regexp-ов явно не на питоне написан.
Чем и как быстро ты собираешься его заменить?
>> и, самое главное, почему это займёт меньше времени?
> Потому что будет решаться только та задача, которая требует решения.
Задача, вообще-то, стояла увеличить пропускную способность,
а не заменить библиотеку регулярных выражений.
---
"Университет развивает все способности, в том числе и глупость."
> либо избавляться от звена wsgi.
Если есть время, можно и правда посмотреть, как пишутся модули nginx.
---
"Не надо читать много книг."
Если есть время, можно и правда посмотреть, как пишутся модули nginx.
---
"Не надо читать много книг."
В общем, упирался я в проц (точнее в ядро). Манипуляции с кодом обработчиков практически ничего не приносили, так что действительно либо вообще переписывать на низкоуровневом языке, либо избавляться от звена wsgi. Либо и то и то.Если поставить пустой обработчик: без всяких проверок возвращается пустая страница, то как меняется кол-во обработанных запросов, и загрузка процессора?
То есть, трудозатраты на составление волшебных табличек ты не учитываешь?Если таблицу заполнять по требованию, то заполнить требуется только несколько ячеек в направлении изменения кода.
Это занимает много меньше времени, чем само изменение кода.
> Как ты собираешься установить по табличкам, что оно потребует "серьёзных телодвижений?"
Функцию на сколько можно увеличить производительность за какой объем телодвижений, тоже можно представить в табличной форме.
количество обработанных вырастает на 2-5%, проц все также в полной загрузке
количество обработанных вырастает на 2-5%, проц все также в полной загрузкеЕсли оставить всё тоже самое, но убрать питон и возвращать пустую страницу без обработки, то как меняются эти же показатели?
2кб статику нжинкс отдает на уровне 40000 запросов в секунду, если ты об этом.
2кб статику нжинкс отдает на уровне 40000 запросов в секунду, если ты об этом.а минимальную динамику? например, взять урл как строку и вернуть кол-во букв a в запросе?
Оставить комментарий
tipnote
Имеется машина:1) Xeon E3 1230 3.2 GHz (8 Cores With HT) - 1x1000GB HDD - 8192MB RAM
на ней крутится
2) Debian 2.6.32-5-amd64, nginx, gevent, python wsgi-приложение
Приложение занимается приемом данных формы, простейшей regexp-валидацией и записью в лог-файл
по замерам ab с одного ядра (один процесс)
3) обрабатывается около 7000 запросов в секунду
Имеет смысл ковырять дальше или больше не выжму?