/ Регистрация

  1. Этот сайт использует файлы cookie. Продолжая пользоваться данным сайтом, Вы соглашаетесь на использование нами Ваших файлов cookie. Узнать больше.

Быстрые сервера или ...

Тема в разделе "Программирование", создана пользователем HorstWessel, 15.01.07.

  1. 15.01.07 #1
    HorstWessel

    HorstWessel Активный участник

    1.585
    0
    ... или очередная религиозная ****а: многопотчность vs асинхронные событитя.

    БОльшая часть современных серверов приложений используют механизм многопоточности. Но, производительность всегда была, есть и будет одним из важных параметорв системы. Механизм асинхронных событий несомненно показывает лучшие результаты по производительности, но есть вопросы:
    -какую роль в ваших проектах играет производительность?
    -насколько удобна модель событий для реализаии приложений?
    -какое из приложений легче отлаживать?
     
  2. 17.01.07 #2
    OEM

    OEM Почётный

    2.957
    1
    HorstWessel,
    1. Производительность играет роль в проектах на грани, т.е. когда на Celeron 400 вречную берешь FFT, и знаешь что лучше него проца не будет
    2. Событийная модель - не факт, что удобна. На мой взгляд гораздо более удобна модель Back/Next или проще говоря визардная. Реализуется легко, логики - минимум, понятность - максимальная.
    3. Легче отлаживать классику или визардную. Событийка (правильно реализованная) отлаживается на порядок сложнее.
    Вообще на мой взгляд MessageLoop - с одной стороны панацея, с другой - зло максимальное, это надо понимать однозначно. Если ты строишь сервак - не денешься никуда от лупа, если фронтенд - лучше визарда не бывает ничего.

    добавлено через 3 минуты
    Бляха муха, вот написал и понял, что поймут меня немногие... Братья, sorry, вспомнил детство.
     
  3. 17.01.07 #3
    AlTk

    AlTk Читатель

    10.692
    0
    не соглашусь по втрому пункту. программировать удобнее все-таки событийную модель.
     
  4. 18.01.07 #4
    HorstWessel

    HorstWessel Активный участник

    1.585
    0
    Кажется меня не совсем так поняли. Или я не понял. Я приведу простой пример (это только пример) - например HTTP Proxy:

    С одной стороны его логика прозрачна: открываем сокет, запускаем читающий поток (он может блокироваться на чтении, может нет, не важно сейчас), как только приходит запрос, он начинает синхронно исполняться- делает запрос к оригинальному серверу, ответ пишет обратно в сокет. Все очень просто, но ясно что производительность такого приложения - 1 клиент на пока исполняется весь процесс.
    Теперь можно пойти дальше и создать обработчик, который запустить в отдельном потоке. То есть основной поток вычитывает данные и все что он делает это создает обработчик (с вычитанными данными) и запускает его на исполнение. В плане кодирования чуть сложнее, но производительность уже лучше. И так далее, далее, далее.... воевать с с синхронизацией и гонками потоков.

    Или есть еще один вариант - асинхронные события. Есть некоторый сервер который читает данные и генерит асинхронно события. Например, в случае с http прокси, читает из сокета и кидает событие Request, кому оно нужно его обрабатывают и кидают другое событие Response.

    В плане производительности и устойчивости второй вариант лучше - это факт. Мне сейчас хотелось бы узнать: кто работал с разными моделями - какая более удобна в плане реализации?
     
  5. 18.01.07 #5
    Гость

    Гость Гость

    Переписывался я несколько лет назад с одним из разработчиков squid.
    Так вот он против всяких асинхронностей и потоков: ибо под СЕРЬЕЗНОЙ нагрузкой они дают сумашедший overhead на обработку.
    PS. Советую почитать доку на nginx...
     
  6. 18.01.07 #6
    HorstWessel

    HorstWessel Активный участник

    1.585
    0
    Альтернатива?

    Не понял чего дают
     
  7. 18.01.07 #7
    Bob

    Bob Активный

    21.795
    2
    HorstWessel,
    дают перегрузку на переключение между потоками
     
  8. 18.01.07 #8
    Vaulter

    Vaulter Активный участник

    1.621
    0
    так что, под СЕРЬЕЗНОЙ нагрузкой
    один поток справится лучше чем несколько чтоли????
     
  9. 19.01.07 #9
    HorstWessel

    HorstWessel Активный участник

    1.585
    0
    Bob,
    А зачем их переключать - они идут себе каждый со своим приоритетом?
    Тем более что давно уже используются пулы потоков - то есть ресурсы на создание и удаление потоков оптимизированы.


    Анекдот по теме: Как вы отдыхаете? да я и не напрягаюсь :)
     
  10. 24.01.07 #10
    Гость

    Гость Гость

    Рекомендуют промежуточный вариант. Повесить массив из ~64 сокетов на 1 поток и делать для него poll() или select(). Более хитрые вещи (если понадобятся) см. в доке к nginx, только они ОС-ориентированы.
    PS. Серьезная нагрузка начинается от 1-2 тысяч активных соединений :)
     
  11. 24.01.07 #11
    Гость

    Гость Гость

  12. 24.01.07 #12
    HorstWessel

    HorstWessel Активный участник

    1.585
    0
    Как вы себе это представляете?
    Это из другой оперы
     
  13. 24.01.07 #13
    AlTk

    AlTk Читатель

    10.692
    0
    HorstWessel,
    1. " ... обработчик, который запустить в отдельном потоке. То есть основной поток вычитывает данные и все что он делает это создает обработчик (с вычитанными данными) и запускает его на исполнение. .."
    2. "... Или есть еще один вариант - асинхронные события. Есть некоторый сервер который читает данные и генерит асинхронно события. "

    с точки зрения процессора эти варианты идентичны.
    они различаются по модели программирования. однако и во втором случае если используются statefull объекты никто не отменял мороки по поводу внутренней синхронизации если модель асинхронных событий предполагает параллельность испорлнения. если же асинхронная модель модель преполагает помещение событий в очередь, то все нормально. поэтому, для обеспечения максимальной параллельности и избежания мороки по синхронизации доступа к данным состояния сейчас идет упор на сервисно-ориентированную модель программирования (если же нано сохранять некоторые промежуточные/"глобальные" данные используется понятие контекста). кстати в этой модели и программировать и отлаживаться намного легче.

    добавлено через 10 минут
    совсем забыл ответить на вопросы
    " ... -какую роль в ваших проектах играет производительность? ..,"
    значительную
    "... -насколько удобна модель событий для реализаии приложений? ..."
    не очень удобна. гораздо лучше использовать сервера приложений и писать, ориентируясь на сервисы.
    -какое из приложений легче отлаживать?
    легче всего отлаживать "линейное" приложение. кстати, использование сервисного пожхода как раз и дает эффект линейности.
     
  14. 25.01.07 #14
    HorstWessel

    HorstWessel Активный участник

    1.585
    0
    Во, об этом и есть вопрос. Какая модель предпочтительней?
    Это как раз плохо. Это самый простой способ синхронизации - в этом случае или обработчик, вынимающий события из очереди, может быть заблокирован кодом программиста или должен создавать новые потоки (и снова синхронизировать, только в другом масштабе)

    Представляет интерес вариант с "контекстом", потому что в рамках контекста события идут последовательно, не обгоняют друг друга.
    Тут не понял? Писать ориентируясь на сервисы стоит понимать как синхронные вызовы. А может быть я наооборот начал понимать что вы имели ввиду под stetfull. Вы имеете ввиду что при синхронном вызове объекта без состояния сервер приложения выберет экземпляр из пула? Это и есть параллелбность в вашем пониманиии?
    То есть код типа:
    someObject.doSomethingOne(blah-blah-blah)
    someObject.doSomethingTwo(blah-blah-blah)?
     
  15. 25.01.07 #15
    Гость

    Гость Гость


    Исходники squid-а посмотрите. comm_poll.c
     
  16. 28.01.07 #16
    HorstWessel

    HorstWessel Активный участник

    1.585
    0
    Ох, да не об этом речь.
     
ST20000NM007D | узкие прикроватные тумбочки | киндюк это | туалетные столики с зеркалом и подсветкой | театр меридиан