... или очередная религиозная война: многопотчность vs асинхронные событитя. БОльшая часть современных серверов приложений используют механизм многопоточности. Но, производительность всегда была, есть и будет одним из важных параметорв системы. Механизм асинхронных событий несомненно показывает лучшие результаты по производительности, но есть вопросы: -какую роль в ваших проектах играет производительность? -насколько удобна модель событий для реализаии приложений? -какое из приложений легче отлаживать?
HorstWessel, 1. Производительность играет роль в проектах на грани, т.е. когда на Celeron 400 вречную берешь FFT, и знаешь что лучше него проца не будет 2. Событийная модель - не факт, что удобна. На мой взгляд гораздо более удобна модель Back/Next или проще говоря визардная. Реализуется легко, логики - минимум, понятность - максимальная. 3. Легче отлаживать классику или визардную. Событийка (правильно реализованная) отлаживается на порядок сложнее. Вообще на мой взгляд MessageLoop - с одной стороны панацея, с другой - зло максимальное, это надо понимать однозначно. Если ты строишь сервак - не денешься никуда от лупа, если фронтенд - лучше визарда не бывает ничего. добавлено через 3 минуты Бляха муха, вот написал и понял, что поймут меня немногие... Братья, sorry, вспомнил детство.
Кажется меня не совсем так поняли. Или я не понял. Я приведу простой пример (это только пример) - например HTTP Proxy: С одной стороны его логика прозрачна: открываем сокет, запускаем читающий поток (он может блокироваться на чтении, может нет, не важно сейчас), как только приходит запрос, он начинает синхронно исполняться- делает запрос к оригинальному серверу, ответ пишет обратно в сокет. Все очень просто, но ясно что производительность такого приложения - 1 клиент на пока исполняется весь процесс. Теперь можно пойти дальше и создать обработчик, который запустить в отдельном потоке. То есть основной поток вычитывает данные и все что он делает это создает обработчик (с вычитанными данными) и запускает его на исполнение. В плане кодирования чуть сложнее, но производительность уже лучше. И так далее, далее, далее.... воевать с с синхронизацией и гонками потоков. Или есть еще один вариант - асинхронные события. Есть некоторый сервер который читает данные и генерит асинхронно события. Например, в случае с http прокси, читает из сокета и кидает событие Request, кому оно нужно его обрабатывают и кидают другое событие Response. В плане производительности и устойчивости второй вариант лучше - это факт. Мне сейчас хотелось бы узнать: кто работал с разными моделями - какая более удобна в плане реализации?
Переписывался я несколько лет назад с одним из разработчиков squid. Так вот он против всяких асинхронностей и потоков: ибо под СЕРЬЕЗНОЙ нагрузкой они дают сумашедший overhead на обработку. PS. Советую почитать доку на nginx...
Bob, А зачем их переключать - они идут себе каждый со своим приоритетом? Тем более что давно уже используются пулы потоков - то есть ресурсы на создание и удаление потоков оптимизированы. Анекдот по теме: Как вы отдыхаете? да я и не напрягаюсь
Рекомендуют промежуточный вариант. Повесить массив из ~64 сокетов на 1 поток и делать для него poll() или select(). Более хитрые вещи (если понадобятся) см. в доке к nginx, только они ОС-ориентированы. PS. Серьезная нагрузка начинается от 1-2 тысяч активных соединений
HorstWessel, 1. " ... обработчик, который запустить в отдельном потоке. То есть основной поток вычитывает данные и все что он делает это создает обработчик (с вычитанными данными) и запускает его на исполнение. .." 2. "... Или есть еще один вариант - асинхронные события. Есть некоторый сервер который читает данные и генерит асинхронно события. " с точки зрения процессора эти варианты идентичны. они различаются по модели программирования. однако и во втором случае если используются statefull объекты никто не отменял мороки по поводу внутренней синхронизации если модель асинхронных событий предполагает параллельность испорлнения. если же асинхронная модель модель преполагает помещение событий в очередь, то все нормально. поэтому, для обеспечения максимальной параллельности и избежания мороки по синхронизации доступа к данным состояния сейчас идет упор на сервисно-ориентированную модель программирования (если же нано сохранять некоторые промежуточные/"глобальные" данные используется понятие контекста). кстати в этой модели и программировать и отлаживаться намного легче. добавлено через 10 минут совсем забыл ответить на вопросы " ... -какую роль в ваших проектах играет производительность? ..," значительную "... -насколько удобна модель событий для реализаии приложений? ..." не очень удобна. гораздо лучше использовать сервера приложений и писать, ориентируясь на сервисы. -какое из приложений легче отлаживать? легче всего отлаживать "линейное" приложение. кстати, использование сервисного пожхода как раз и дает эффект линейности.
Во, об этом и есть вопрос. Какая модель предпочтительней? Это как раз плохо. Это самый простой способ синхронизации - в этом случае или обработчик, вынимающий события из очереди, может быть заблокирован кодом программиста или должен создавать новые потоки (и снова синхронизировать, только в другом масштабе) Представляет интерес вариант с "контекстом", потому что в рамках контекста события идут последовательно, не обгоняют друг друга. Тут не понял? Писать ориентируясь на сервисы стоит понимать как синхронные вызовы. А может быть я наооборот начал понимать что вы имели ввиду под stetfull. Вы имеете ввиду что при синхронном вызове объекта без состояния сервер приложения выберет экземпляр из пула? Это и есть параллелбность в вашем пониманиии? То есть код типа: someObject.doSomethingOne(blah-blah-blah) someObject.doSomethingTwo(blah-blah-blah)?