none
Архитектура масштабируемого сервера. RRS feed

  • Вопрос

  • Очень хочется разработать масштабируемый сервер на .Net. Посоветуйте архитектуру. Чужой велосипед не хочу, хочу свой.
    24 января 2011 г. 9:29

Ответы

  • Насчет других издержек многопоточности - у меня сейчас на машине запущено около 1000 потоков в 70 процессах. Издержек не наблюдаю :)

    Эмпирически подбирать количество потоков, чтобы они больше проводили времени в работе, а не в переключении. Никаких особых рецептов и никаких издержек многопоточности в общем виде нет, IMHO.


    My blog
    24 января 2011 г. 11:08

Все ответы

  • Архитектура зависит от типа приложений, которое будет хостить сервер. Если это одинокое десктоп приложение (судя по тому, что вопрос задан в Настольных ПК) - то никакой масштабируемости не нужно  :)
    My blog
    24 января 2011 г. 9:37
  • Некоторые рекомендации по построению архитектур клиент-серверных приложений (в том числе и настольных) есть в бесплатной книге "Руководство Microsoft по проектированию архитектуры приложений". Скачать можно здесь .
    24 января 2011 г. 9:50
  • Как я понял термин "маштабируемость" трактуется везде по разному, в одном случае это лёгкое наращивание мощности, в другом это способность работать при высоких нагрузках. Я имел ввиду второй вариант, т.е. все издержки связанные с использованием многопоточности нужно свести к минимуму.
    24 января 2011 г. 9:57
  • Если речь идет о сетевом сервере, то можете посмотреть статью Преимущества быстродействующих сокетов в .NET, там рассматриваются 3 варианта архитектуры сервера, их плюсы/минусы, даются советы куда посмотреть дальше, как можно еще оптимизировать работу.


    Для связи [mail]
    24 января 2011 г. 10:24
  • Некоторые рекомендации по построению архитектур клиент-серверных приложений (в том числе и настольных) есть в бесплатной книге "Руководство Microsoft по проектированию архитектуры приложений". Скачать можно здесь .

    За книгу спасибо, не маленько не то. Как я решил делать.  У сервера будет один рабочий поток который будет брать из очереди команды и их выполнять. Все остальные объекты будут создавать команды и класть их в очередь. Проблема в том что создание команд будет происходить в многопоточной среде, а значит будут издержки многопоточности. Вот как это обойти?
    24 января 2011 г. 10:26
  • Насчет других издержек многопоточности - у меня сейчас на машине запущено около 1000 потоков в 70 процессах. Издержек не наблюдаю :)

    Эмпирически подбирать количество потоков, чтобы они больше проводили времени в работе, а не в переключении. Никаких особых рецептов и никаких издержек многопоточности в общем виде нет, IMHO.


    My blog
    24 января 2011 г. 11:08
  • Насчет других издержек многопоточности - у меня сейчас на машине запущено около 1000 потоков в 70 процессах. Издержек не наблюдаю :)

    Эмпирически подбирать количество потоков, чтобы они больше проводили времени в работе, а не в переключении. Никаких особых рецептов и никаких издержек многопоточности в общем виде нет, IMHO.


    My blog

    Ну это как сказать... Меня на одном форуме несколько лет назад за многопоточный Web-сервер камнями закидали. Правда и взамен ничего не предложили.
    24 января 2011 г. 11:36
  • IIS и Apache - многопоточные вебсервера :) Можно было привести это в качестве аргумента :)


    My blog
    24 января 2011 г. 11:43
  • В некоторых случаях многопоточность может быть во вред приложению. Но точно не в случае веб-серверов.
    24 января 2011 г. 11:47