LINUX.ORG.RU

Вопрос о nginx unit / асинхронных запросах / запросах в процессе

 , , , ,


0

4

Вот вышел nginx unit, говорят все круто, можно делать асинхронные запросы и все такое. Я немного растерян и не могу понять, что именно эта штука делает. Если тут есть те, кто регулярно читает рассылки этой конторы, то может подскажите, что из этого можно реализовать этой штукой? А то вроде бы и можно, и вроде бы из другой сказки. Или может кто знает, куда задать эти вопросы, но при этом не платить деньги?

1. Реализовать индикатор загрузки файлов и указать скорость загрузки. Да, есть отдельные плагины как к nginx, так и к php в частности, но это чужой код и я должен зависеть от него. А собственный обработчик - никак, ведь мой код выполняется лишь после загрузки всех файлов целиком.

2. Обрабатывать контент и управлять соединением в процессе запроса. Допустим на Ютуб лью 10 гиговый файл, он мне сразу начинает показывать превьюшки, с первых секунд заливки. Я тоже так хочу, а если мне заливают некропедозоопорно, то я хочу как-то дропнуть коннект, но не заносить клиента в iptables.

3. К нам пришел запрос от веб-формочки, нам надо как-то процессить присланные файлы, хотя бы тумбинашки от них посчитать. В принципе, тумбинашку сгенерить не долго и это часто делают в основном скрипте, тем самым задерживая исполнение реквеста и отдачу «ок, все впорядке». А я хочу процессить картинки в отдельном треде, чтобы одновременная заливка 500 картинок не положила мне сервер, но в этом случае я получаю condition race, так как пользователь вернется на страничку раньше, чем я успею ее обновить. Хотелось бы какой-то инструмент, чтобы я мог как-то тормознуть отдачу результата клиенту, но при этом сам скрипт-обработчик мог бы спокойно завершиться/завершить цикл и приступить к новому запросу. В общем, хочу в обработчике запросов делать тяжелые задачи и чтобы мне за это ничего не было.

4. Ко мне на файлообменник заливают файл весом в 10 гигов, не быстро так, а часов за 5. Это может быть плохая скорость у пира, где-то по пути проблемы, или у меня большой iowait, не суть важно. Почему бы мне этот файл не попробовать раздавать еще до того, как он окончательно будет долит? Скажем, мне успели залить 10 мегабайт, они уже где-то лежат на моем винте, почему бы их не отдать новоприбывшим с полной скоростью, а остаток не скормить за оставшиеся 5 часов со скоростью заливальщика? По идее, процесс один, все данные для этого есть, просто я не знаю как сервить такие вот обновляемые файлы.

5. Ну и всякие мультиплексоры тоже хочу, такие как realplexor или что там теперь пришло ему на смену? Куча клиентов присоединяется к ресурсу и ждут событий, а когда событие произошло - получают одно или несколько штук сразу. Чтобы посылать несколько событий, неплохо бы чтобы скрипт посылающий события мог бы сделать некий flush() и все ушло разом, а не 10 байт через 10 запросов.

Вот все это можно сделать в вашем юните? Или нет? Может есть какие-то другие решения? Просто обработчики запросов легко бы решили все эти проблемы, но у меня нету такого API. Когда-то давно начинал писать вебсервер где запросы просто складировались в память и дальше рассылались уведомления на мотив epoll, но запрокрастинировал и бросил.

NGINX Unit не имеет никакого отношения к вашим вопросам - это совсем про другое.

NGINX Unit более логично и удобно решает проблему корректного «горячего» обновления версий backend-части. Ну и вопросы конфигурации-администрирования backend-сервисов, реализованных с использованием различных платформ (PHP, Golang, ...), должны, по идее, порешаться в сторону упрощения.

Какого-то супер ускорения обработки запросов здесь не обещается. Да и откуда? Всё остается по-старому - для высоконагруженных сервисов нужно выбирать правильную платформу (Golang, обещали добавить NodeJS). Разве что, распределение нагрузки по ядрам процессора как-нибудь могут оптимизировать.

vinvlad ()
Ответ на: комментарий от vinvlad

Что касается ваших вопросов, вам нужно погуглить на тему «read raw post data». К примеру, постить можно в iframe, а проверять текущее состояние загрузки с помощью AJAX. Что-то типа этого...

Ну и для приема в raw-режиме может потребоваться специфичная backend-часть.

vinvlad ()

ведь мой код выполняется лишь после загрузки всех файлов целиком

Дай угадаю. Пхпшник?

redixin ★★★★ ()
Ответ на: комментарий от vinvlad

Какого-то супер ускорения обработки запросов здесь не обещается. Да и откуда?

Ускорение можно получить за счет обработки одновременно кучи запросов, уходя от парадигмы «один запрос - один цикл исполнения». Переложить часть работы на клиентский скрипт, пусть сам решает как будет лучше. Ну и фичастость, на чем мне вот указанные фичи делать?

hukicif ()
Ответ на: комментарий от vinvlad

К примеру, постить можно в iframe, а проверять текущее состояние загрузки с помощью AJAX. Что-то типа этого...

Это клиент, это не интересно в данной дискуссии.

Ну и для приема в raw-режиме может потребоваться специфичная backend-часть.

Вот о ней речь и идет. На чем ее делать? В принципе, на древнем CGI я мог бы все это сделать (кроме мультиплексора), но акселераторы ставят крест на всем этом.

hukicif ()
Ответ на: комментарий от redixin

Дай угадаю. Пхпшник?

Пишу на примерно десятке языков, в том числе писал код на ПХП. Сделал на нем примерно пару-тройку эталонных проектов, которые были достаточно известны в узких кругах. Но пехапешником себя не считаю.

hukicif ()
Ответ на: комментарий от hukicif

Ну и для приема в raw-режиме может потребоваться специфичная backend-часть.

Вот о ней речь и идет. На чем ее делать? ...

В принципе, можно на NodeJS склепать. Вот простенький пример сервера, принимающего POST-данные в raw-режиме:

const http = require('http');

const server = http.createServer((req, res) => {
    if (req.method === 'POST') {
        // Handle post info...        
        collectRequestData(req, result => {
            res.end('POST LENGTH: ' + result);
        });
    }
    else {
      res.end(`
        <!doctype html>
        <html>
        <body>
            <form action="/" method="post" enctype="multipart/form-data">
                <input type="file" name="photo" /><br />
                <button>Upload File</button>
            </form>
        </body>
        </html>
      `);
    }
});
server.listen(3000);

function collectRequestData(request, callback) {
	let raw = [];
	request.on('data', chunk => {
		raw.push(chunk);
		console.log('on: '+chunk.length);
	});
	request.on('end', () => {
		let x = Buffer.concat(raw).toString();
		console.log('end: total = '+x.length);
		callback(x.length);
	});
}

При большом загружаемом файле обработчик request.on('data',...) будет получать данные POST-запроса отдельными порциями. Ну и естественно, потребуется какой-то парсер для входного потока в формате «multipart/form-data».

vinvlad ()
Ответ на: комментарий от hukicif

... ну и естественно, в POST-запрос нужно включать какой-то уникальный идентификатор загрузки, если хотите сбоку проверять состояние загрузки - по этому самому идентификатору.

vinvlad ()
Ответ на: комментарий от hukicif

... Вот о ней речь и идет. На чем ее делать?

Посмотри еще Golang - там, по идее, тоже должна быть возможность чтения тела POST-запроса в raw-режиме.

vinvlad ()

... Хотелось бы какой-то инструмент, чтобы я мог как-то тормознуть отдачу результата клиенту, но при этом сам скрипт-обработчик мог бы спокойно завершиться/завершить цикл и приступить к новому запросу. В общем, хочу в обработчике запросов делать тяжелые задачи и чтобы мне за это ничего не было.
...
... Почему бы мне этот файл не попробовать раздавать еще до того, как он окончательно будет долит? Скажем, мне успели залить 10 мегабайт, они уже где-то лежат на моем винте, почему бы их не отдать ...
...
Ну и всякие мультиплексоры тоже хочу, такие как realplexor или что там теперь пришло ему на смену? Куча клиентов присоединяется к ресурсу и ждут событий, а когда событие произошло - получают одно или несколько штук сразу...

Собственно, за NGINX могут болтаться произвольные backend-сервисы на HTTP / FastCGI / WebSocket протоколах — это если требуется через один и тот же домен и порт всё гонять. А так... для твоих хотелок подойдут любые фрэймворки, где для работы с сокетами используется асинхронный ввод-вывод и обработчики отдельных сетевых соединений не привязаны жёстко к своим собственным выделенным потокам/процессам операционной системы (обрабатывать каждое соединение отдельным thread-ом — дороговато будет при большой нагрузке). Для начала, присмотрись поплотнее к Golang и NodeJS и к ихним API-шкам – они ведут себя вполне гуманно в плане расходов памяти и процессорного времени, ну и держать одновременно огромадное количетво соединений могут. Если не подойдет, то можешь пониже опуститься — на C++ (плюс правильная библиотечка) уж точно все твои хотелки решаемы.

Ключевые слова: асинхронный фрэймворк, зелёные потоки, асинхронный ввод-вывод, миллион одновременных соединений :).

Как-то так...

vinvlad ()
Ответ на: комментарий от vinvlad

Мы кажется говорим о разном. Какая разница, какой язык используется за nginx, если он, как акселератор, сначала сожрет ВЕСЬ запрос? Или предлагается все эти ваши ноды/голанги голой попой в интернеты выставлять?

Еще раз: я не ищу язык или фреймверк. Пусть это будет Баш, чтобы уж наверняка. Я ищу технологию, которая позволит мне быстро и асинхронно обслуживать массу клиентов.

И я не хочу кучу гринтредов/обычных тредов. Я хочу, к примеру, так: один тред читает события от вебсервера (по http, http/2, spdy, quic, websockets), быстро-быстро что-то делает, к примеру заполняет данные в базу данных и ОСТАВЛЯЕТ КЛИЕНТА ВИСЕТЬ ДАЛЬШЕ, рядом второй тред видит сигнал от первого и начинает заниматься чем-то тяжелым, пережимать картинки или видео, нарезать видео на скриншоты и так далее. И когда второй тред закончил, первый тред (или даже сам второй) отвечает ВИСЯЩЕМУ клиенту «Ок, вот тебе редирект» - всего 2 треда и никакой порнографии.

hukicif ()
Ответ на: комментарий от hukicif

Все что ты описал элементарно делается на любом языке (не уверен насчет mod_php и php_fpm)

Достаточно знать как работает http и fastcgi, wsgi или что там у тебя есть еще.

redixin ★★★★ ()
Ответ на: комментарий от hukicif

Мы кажется говорим о разном. Какая разница, какой язык используется за nginx, если он, как акселератор, сначала сожрет ВЕСЬ запрос? Или предлагается все эти ваши ноды/голанги голой попой в интернеты выставлять?

Не совсем понимаю, в каком смысле здесь используется слово «акселератор». К примеру, HTTP-протокол по своей спецификации - полудуплексный. Сначала веб-обозреватель в рамках одного HTTP-соединения загружает огромный файл на сервер (отправляет запрос) и только потом начинает читать ответ - и никак иначе. Даже если вы начнете гнать ответ по сокету раньше приема всего тела HTTP-запроса, это вам ничем не поможет - пользователь ничего не увидит в веб-обозревателе до окончания закачки файла. Так что, некоторые из перечисленных хотелок в принципе не решаются в рамках выполнения одного HTTP-соединения. Если же речь идет о WebSocket-протоколе, то там можно гонять данные туда-сюда различными порциями сколько угодно, поэтому вы можете придумать свой собственный протокол поверх WebSocket-а. NGINX проксирует это дело прозрачно в обоих направлениях.

И я не хочу кучу гринтредов/обычных тредов ...

«Зелёный» поток Golang и обычный линуксовый thread - это две большие разницы. Вы просто для начала почитайте, как работают движки Golang и NodeJS - насколько меньше они жрут ресурсов памяти и процессора и почему. Это и есть технологии быстрого и одновременного обслуживания большого числа клиентов (в отличии от PHP).

vinvlad ()
Ответ на: комментарий от hukicif

И какой протокол мне поможет?

Все зависит от того, какой клиент предполагается использовать на стороне пользователя. Если это не веб-обозреватель, а какая-то самописная софтинка, которую тоже предполагается реализовывать с нуля, то вы можете придумать поверх TCP любой удобный протокол, который решает ваши хотелки. Если же речь идет об использовании каких-то готовых клиентов, работающих по конкретным протоколам, то изучайте эти протоколы.

Или предлагается все эти ваши ноды/голанги голой попой в интернеты выставлять?

Нисколько не возбраняется ) Это же обычные платформы программирования, не завязанные на какой-то конкретный протокол. Вы можете клепать на них произвольные серверные продукты в рамках того, что позволяют их API-шки и движки.

vinvlad ()
Ответ на: комментарий от redixin

Отлично, сейчас ты реализуешь хотя бы один пункт из списка, но сделаешь это так, чтобы зажатая клавиша F5 не положила тебе сервер. Если взять древний Apache и CGI, то я тоже так смогу, но подобные шедевры череваты использовать в продакшене. Впрочем, я жду продолжение вашего позора.

hukicif ()
Ответ на: комментарий от vinvlad

Не совсем понимаю, в каком смысле здесь используется слово «акселератор».

Ну как же? Его же писали изначально с расчетом на то, чтобы прикрыть задницу тормозному и толстому Апачу. Вся акселерация (и популярность) достигалась за счет того, что тупой (т.е. легковесный) nginx вычитывал сначала весь запрос клиента, дальше ворочался толстый апач, nginx быстро вычитывал ответ, в этот момент толстый апач мог завершить задачу, а клиенту ответ скармливал уже nginx в час по чайной ложке. А раз nginx сначала должен вычитать весь запрос, то все описанные задачи становятся в принципе невозможными. И вот появился новый способ взаимодействия с бекендом, тут то возможно что-то и поменялось?

Так что, некоторые из перечисленных хотелок в принципе не решаются в рамках выполнения одного HTTP-соединения.

Про «совсем одно соединение» речи и не шло. А сами фичи так или иначе реализованы и не раз, к примеру та же индикация загрузки файла успешно отсылает запросы с нужным токеном и получает ответы. Другой вопрос, что это все реализовано зачастую или где-то в проприетарных решениях (как в случае с ютубом), или в виде хаков к серверу (существующие плагины), а вот чтобы можно было и написать СВОЮ РЕАЛИЗАЦИЮ, то такого не видно.

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

Жрать меньше можно относительно чего-то. А у меня ничего нет. Сравнивать технологию с пехапе - себя не уважать.

Все зависит от того, какой клиент предполагается использовать на стороне пользователя. Если это не веб-обозреватель, а какая-то самописная софтинка, которую тоже предполагается реализовывать с нуля, то вы можете придумать поверх TCP любой удобный протокол, который решает ваши хотелки. Если же речь идет об использовании каких-то готовых клиентов, работающих по конкретным протоколам, то изучайте эти протоколы.

Браузер. Вопрос был риторическим.

Нисколько не возбраняется ) Это же обычные платформы программирования, не завязанные на какой-то конкретный протокол. Вы можете клепать на них произвольные серверные продукты в рамках того, что позволяют их API-шки и движки.

А потом приходит Вася и скриптом из нескольких строк кладет мне сервер. Так что возбраняется.

hukicif ()
Ответ на: комментарий от hukicif

череваты

чреваты

Впрочем, я жду продолжение вашего позора.

Лол

redixin ★★★★ ()
Ответ на: комментарий от hukicif

А раз nginx сначала должен вычитать весь запрос, то все описанные задачи становятся в принципе невозможными.

4.2.

Это все от нехватки знаний характерной для пхпшников.

Я даже не знаю что тебе посоветовать почитать, т.к. читать нужно еще очень много.

redixin ★★★★ ()
Ответ на: комментарий от hukicif

redixin: Все что ты описал элементарно делается на любом языке ...

Ну это, конечно, не совсем так - надо еще грамотно пользоваться API-шками, которые имеются в наличии (а их может и не быть).

Отлично, сейчас ты реализуешь хотя бы один пункт из списка, но сделаешь это так, чтобы зажатая клавиша F5 не положила тебе сервер.

Ну, если вы нажмете F5 на какой-нибудь картинке или статичной HTML-ке, то NGINX и не заметит. Даже на слабеньком по нынешнем временам сервере 10000 запросов в секунду для него при правильной настройке Linux - не проблема.

F5 не положит сервер и в том случае, если вы начнете грузить в цикле страничку, формируемую динамически с помощью NodeJS или Golang. Единственное, если при этом будут осуществляться запросы к объемной базе данных и у вас быстрый канал связи с инетом, то могут возникнуть тормоза и отказы соединения с БД. Но сервер при правильной настройке не ляжет.

vinvlad ()
Ответ на: комментарий от vinvlad

Ну это, конечно, не совсем так - надо еще грамотно пользоваться API-шками, которые имеются в наличии (а их может и не быть).

Я не встречал серверной либы которая бы не позволяла читать тело запрса аки файл. Хотя может ТС встречал, он же еще на девяти языках пишет помимо пхп.

Опять же не уверен насчет mod_php и php_fpm. От этих макак можно ожидать любой глупости. А на голом пхп такое сделать можно, благо он умеет в сокеты.

Я когда то давно у другана пхпшника вызвал шок когда у меня codeigniter через сокет заработал в 50 раз быстрее чем через mod_php. Правда я там разбирал не голый хттп, а fastcgi через nginx.

redixin ★★★★ ()
Ответ на: комментарий от hukicif

Ну как же? Его же писали изначально с расчетом на то, чтобы прикрыть задницу тормозному и толстому Апачу. Вся акселерация (и популярность) достигалась за счет того, что тупой (т.е. легковесный) nginx вычитывал сначала весь запрос клиента, дальше ворочался толстый апач, nginx быстро вычитывал ответ, в этот момент толстый апач мог завершить задачу, ...

Совершенно неверное представление об NGINX. Это просто веб-сервер, заточенный на максимально быструю выдачу статики (картинки, html, js и пр.) за счет максимального использования доступных ресурсов процессора. Работу backend-части он не ускоряет.

... Другой вопрос, что это все реализовано зачастую или где-то в проприетарных решениях (как в случае с ютубом), или в виде хаков к серверу (существующие плагины), а вот чтобы можно было и написать СВОЮ РЕАЛИЗАЦИЮ, то такого не видно.

А кто вам мешает написать свою реализацию? Для этого при правильном выборе «инструмента» нет никаких препятствий.

Жрать меньше можно относительно чего-то. А у меня ничего нет. Сравнивать технологию с пехапе - себя не уважать

Я имею в виду, что Golang и NodeJS работают приблизительно так же оптимально как и NGINX - и в NGINX и в этих движках для работы с сокетами используется асинхронный ввод-вывод, нет лишних простоев процессора и нет избыточных переключений контекста между линуксовыми thread-ами. К примеру, в NodeJS вся логика вообще выполняется в рамках одного потока (thread-а).

А потом приходит Вася и скриптом из нескольких строк кладет мне сервер. Так что возбраняется.

Не положит - не так-то это и просто ) Читайте...

vinvlad ()
Ответ на: комментарий от redixin

Ну это, конечно, не совсем так - надо еще грамотно пользоваться API-шками, которые имеются в наличии (а их может и не быть).

Я не встречал серверной либы которая бы не позволяла читать тело запроса аки файл...

Apache и NGINX реализованы на C, но эффективность выдачи статики у них весьма разная - разные принципы реализации и использование разных API.

vinvlad ()
Ответ на: комментарий от hukicif

Ну как же? Его же писали изначально с расчетом на то, чтобы прикрыть задницу тормозному и толстому Апачу. Вся акселерация (и популярность) достигалась за счет того, ...

NGINX конечно слегка ускоряет обработку backend-запросов за счет более оптимальной работы с сокетами и более оптимального использования процессора. Но не так, чтобы принципиально... У него другие полезные фишки имеются.

vinvlad ()
Ответ на: комментарий от vinvlad

Причем тут статика? Мы вроде про аплоад говорим.

И да, расскажите уже ТСу кто нибудь про proxy_request_buffering

redixin ★★★★ ()
Ответ на: комментарий от vinvlad

А кто вам мешает написать свою реализацию? Для этого при правильном выборе «инструмента» нет никаких препятствий.

Писать, конечно же, в виде плагина к серверу и от него зависеть?

Не положит - не так-то это и просто ) Читайте...

Я уже не знаю что и кого читать. Мое представление о мире расходится с тем, что мне тут пишут.

hukicif ()
Ответ на: комментарий от hukicif

Писать, конечно же, в виде плагина к серверу и от него зависеть?

Конечно же НЕТ! Что вам дались эти плагины! Если в NGINX сделали такой конкретный плагин, то это вовсе не значит, что такой же функционал нельзя реализовать самому в backend-части. Просто чтобы делать такие «фишечки», backend-часть должна быть реализована с учетом возможности поддержки достаточно большого количества запросов в секунду и достаточно большого количества параллельно поддерживаемых соединений - соответственно, должна быть правильно выбрана платформа для её реализации. Вот я вам и предложил пару типовых вариантов, которые в настоящее время используются для таких целей.

Я уже не знаю что и кого читать. Мое представление о мире расходится с тем, что мне тут пишут.

Значит, нужно немного подправить свои представления. Если не доверяете тому, что здесь говорится, то почитайте что-нибудь в другом месте - ключевые поисковые фразы для Google я вам уже указал.

Ну а чтобы самому «пощупать ручками» доступные теперь скорости обработки запросов, поставьте, к примеру, себе на сервер NodeJS, напишите тестовое HTTP-приложение и прогоните тест его производительности с помощью Linux-утилиты httperf.

vinvlad ()
Ответ на: комментарий от hukicif

Я уже не знаю что и кого читать. Мое представление о мире расходится с тем, что мне тут пишут.

Вот почитайте, к примеру:

http://romanlovetext.blogspot.ru/2012/08/nodejs.html

Только учтите, что в этом примере NodeJS используется в кластерном режиме. Фактически, запускается несколько worker-процессов - по числу процессорных ядер сервера, - поскольку сам движок NodeJS однопотоковый (так же и NGINX работает - там вы тоже указываете в конфигурации число worker-процессов). Для вашей задачи с upload-ом это существенный момент, поскольку вам нужно где-то хранить текущее состояние загрузки файлов и предоставлять эти данные обработчикам других HTTP-запросов, которые будут задействованы в работе индикаторов загрузки. Ну т.е. для HTTP-запросов этих двух типов вам нужно:

1) либо использовать какой-то выделенный NodeJS-процесс со своим портом и проксировать в него соответствующие HTTP-запросы из NGINX. Следствие - эти запросы будут отрабатываться на одном ядре;

2) либо как-то извращаться и хранить состояние загрузки в разделяемой памяти.

Первый вариант реализовать, конечно, проще.

vinvlad ()
Ответ на: комментарий от vinvlad

то это вовсе не значит, что такой же функционал нельзя реализовать самому в backend-части.

Ура, вы подарили мне лучик надежды!

Просто чтобы делать такие «фишечки», backend-часть должна быть реализована с учетом возможности поддержки достаточно

Я говорю с евангелистом Ноды? Или визитером каких-то семинаров? То, что вы не программист, я уже понял.

поддержки достаточно большого количества запросов в секунду и достаточно большого количества параллельно поддерживаемых соединений - соответственно

(бормотание про сношения и родственников)

А бесконечный цикл, у нас, конечно же тоже выполнится быстрее на этих платформах?

hukicif ()
Ответ на: комментарий от hukicif

Я говорю с евангелистом Ноды? Или визитером каких-то семинаров?

Нет конечно ) На ноду мне плевать - я просто привел вам пример платформ, которые можно легко пощупать, и на которых многие решают проблему высокой нагрузки. Пишите на чем угодно, хоть на С - тут у вас полная свобода. Лично я в последние годы в основном работаю на C/С++ и частично на PHP, Javascript.

То, что вы не программист, я уже понял.

Хамить незнакомым людям не надо. Особенно, если сами знаниями не блещете. Возможно - и даже скорее всего, - вы и на свете живете поменьше, чем я программирую :)

А бесконечный цикл, у нас, конечно же тоже выполнится быстрее на этих платформах?

А кто вас заставляет выполнять бесконечный цикл? )) Глупые вопросы задаете, батенька...

Удачи.

vinvlad ()
Ответ на: комментарий от vinvlad

можно легко пощупать, и на которых многие решают проблему высокой нагрузки.

Щупать я предпочитаю себя за сиську и за другие места. Высокие нагрузки конечно хорошо, но вопросы были не про них. Жаль, что вы не умеете читать.

Хамить незнакомым людям не надо. Особенно, если сами знаниями не блещете. Возможно - и даже скорее всего, - вы и на свете живете поменьше, чем я программирую :)

С телепатией у вас тоже большие проблемы

hukicif ()
Ответ на: комментарий от hukicif

Высокие нагрузки конечно хорошо, но вопросы были не про них. Жаль, что вы не умеете читать.

Вот ваши слова - перечитайте:

1. Реализовать индикатор загрузки файлов и указать скорость загрузки ...

… А я хочу процессить картинки в отдельном треде, чтобы одновременная заливка 500 картинок не положила мне сервер, ...

5. Ну и всякие мультиплексоры тоже хочу, такие как realplexor или что там теперь пришло ему на смену? Куча клиентов присоединяется к ресурсу и ждут событий, а когда событие произошло - получают одно или несколько штук сразу.

Ну и для приема в raw-режиме может потребоваться специфичная backend-часть.

Вот о ней речь и идет. На чем ее делать?

Еще раз: я не ищу язык или фреймверк. Пусть это будет Баш, чтобы уж наверняка. Я ищу технологию, которая позволит мне быстро и асинхронно обслуживать массу клиентов.

Отлично, сейчас ты реализуешь хотя бы один пункт из списка, но сделаешь это так, чтобы зажатая клавиша F5 не положила тебе сервер.

А потом приходит Вася и скриптом из нескольких строк кладет мне сервер. Так что возбраняется.

Вот все это можно сделать в вашем юните? Или нет? Может есть какие-то другие решения?

Разве здесь не идет речь, в том числе, и о высокой нагрузке?

Вам русским языком и вполне доходчиво объяснили, на чем можно без лишних хлопот реализовать ваши хотелки, перечисленные в начале топика. Вам указали не языки - вам указали конкретные технологии, которые включают в себя нужные API-шки и «движки», подходящие для быстрого и оптимального решения ваших задач.

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

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

vinvlad ()

На всякий случай, если вы чего-то недопоняли насчет NGINX Unit...

NGINX Unit – это не технология программирования каких-то задач. Это просто контейнер веб-приложений, реализованных на определённом наборе языков с соответствующими API-шками и «движками». А вот эти конкретные сочетания языков + API + «движков» - это уже конкретные технологии программирования (иными словами «фрэймворки»). Эти же самые технологии программирования («фрэймворки») доступны для использования и без NGINX Unit — в виде запускаемых на сервере автономных сервисов (демон-процессов). Некоторые такие сервисы могут работать в качестве backend-сервисов, стоящих позади NGINX веб-сервера (не путать с NGINX Unit) — к примеру, таким способом работает PHP-FPM. Другие сервисы могут принимать входящие соединения и непосредственно из Интернета - без каких-либо прокси-прокладок. Это зависит от конкретного назначения приложений.

Когда стоит задача чего-то там реализовать, выбирается конкретный «фрэймворк» (язык + API + движок) исходя из соответствующих требований к функционалу, а также, хотелок по части удобства программирования и сопровождения.

vinvlad ()
Ответ на: комментарий от vinvlad

у него так и остался динамический конфиг по ссылке ? Я конечно понимаю что это модно и молодежно но как контролировать то что конфиг применился ?

Jopich1 ()
Ответ на: комментарий от hukicif

Ну и еще, насчет вашего вопроса:

На чем ее (backend-часть) делать? В принципе, на древнем CGI я мог бы все это сделать (кроме мультиплексора), но акселераторы ставят крест на всем этом.

Сейчас на смену CGI пришел протокол FastCGI. Так что, вы с таким же успехом можете нынче сделать автономный backend-сервис, который будет запускаться как обычный линуксовый демон-процесс и взаимодействовать с NGINX (или другим веб-сервером) по FastCGI, пущенному поверх TCP или Unix сокетов. Поддержка FastCGI API есть во многих языках программирования.

Можно попробовать на FastCGI и мультиплексор забабахать — просто таймауты выполнения HTTP-запроса надо будет увеличивать в настройках веб-сервера для соответствующих URL-к. Ну или WebSocket-протокол задействовать для этой цели — он нормально проксируется NGINX-ом.

Что касается выполнения веб-приложений в среде NGINX Unit, то здесь нет такой свободы, которую дает взаимодействие через FastCGI, и нужно просто выбирать подходящую платформу из списка поддерживаемых (там обмен данными идет как-то хитро - через разделяемую память).

vinvlad ()
Ответ на: комментарий от Jopich1

у него так и остался динамический конфиг по ссылке ? Я конечно понимаю что это модно и молодежно но как контролировать то что конфиг применился ?

Не знаю - наверное, путем повторного чтения curl-ом через API :) Поди, сообразят потом какую-нибудь утилитку добавить.

vinvlad ()
Ответ на: комментарий от hukicif

Мы кажется говорим о разном. Какая разница, какой язык используется за nginx, если он, как акселератор, сначала сожрет ВЕСЬ запрос? ...

Чтобы у вас не было столь упрощенного представления о работе NGINX, почитайте описание настроечных директив:
http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html#fastcgi_request_bu...
http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_request_buffering

А лучше просто все странички:
http://nginx.org/ru/docs/http/request_processing.html
http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html
http://nginx.org/ru/docs/http/ngx_http_proxy_module.html

Без базовых знаний настройки NGINX нельзя принимать решений по части реализации backend-сервисов и вести какие-либо конструктивные разговоры на эту тему.

Ну и почитайте спецификацию FastCGI:
https://fastcgi-archives.github.io/FastCGI_Specification.html

Принципиальный момент здесь:

After a FastCGI process accepts a connection on its listening socket, the process executes a simple protocol to receive and send data. The protocol serves two purposes. First, the protocol multiplexes a single transport connection between several independent FastCGI requests. This supports applications that are able to process concurrent requests using event-driven or multi-threaded programming techniques. Second, within each request the protocol provides several independent data streams in each direction. This way, for instance, both stdout and stderr data pass over a single transport connection from the application to the Web server, rather than requiring separate pipes as with CGI/1.1.

vinvlad ()
Ответ на: комментарий от vinvlad

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

«Фрэймворк» - это слово, которое даже написать не каждый может правильно, обычно оно обозначает высер очередного Васи Пупкина, про который забудут на следующей неделе.

hukicif ()
Ответ на: комментарий от hukicif

Ну тогда, hukicif, пишите на Ассемблере ) И все протоколы, и асинхронный ввод-вывод, и всё прочее - ручками... Имеете полное право.

vinvlad ()
Ответ на: комментарий от hukicif

... это слово, которое даже написать не каждый может правильно

... Вы уж извините, что перепутал буквочку :) Я в основном техническую литературу на английском читаю. В сущности, это ведь не важно, какой термин использовать (API, библиотека или что еще). Важно - не изобретать заново велосипеды.

А еще очень важно - вести себя прилично по отношению к тем людям, которые искренне пытаются вам помочь, причем, бесплатно.

vinvlad ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.