Здравствуйте, vb-develop, Вы писали:
S>>От одного клиента?
VD>Была потребность отправлять через веб-сервисы до сотни запросов в секунду от одного клиента. Работало медленно в первую очередь из-за синхронности запросов. Думаю использование keep-alive могло решить эту проблему.
Здравствуйте, Sinclair, Вы писали:
S>>ага — пример заслал я на сервер запросы в последовательности q1, q2, q3...а на сервере оказываеца запрос S>>q1 выполняется долше всего... S>Открывай несколько параллельных коннектов.
Уж лучше сразу вернуть статус "ОК" (типа, принято в очерель) + послать потом N команд типа, вернуть результат первого выполненного (или результаты M-выполненых запросов) запроса. Но это еще один протокол сверху получается.
Здравствуйте, Shabi, Вы писали:
S>Здравствуйте, vb-develop, Вы писали:
S>>>От одного клиента?
VD>>Была потребность отправлять через веб-сервисы до сотни запросов в секунду от одного клиента. Работало медленно в первую очередь из-за синхронности запросов. Думаю использование keep-alive могло решить эту проблему.
S>как бы не наоборот...ухудшило
S>Во-вторых, HTTP устроен так, что "не надо платить за то, чего не используешь". Если модные сервисы от него не нужны, то накладные расходы на заголовки HTTP близки к нулю.
Небольшая мысль вслух того, кто чувствует эти нулевые накладные расходы ежемесячно.
Сервер линеечек (картинки такие для женских форумов, показывают временную шкалу в виде симпотичного изображения): обрабатывает запрос GET и в ответ отдает небольшой GIF. Никаких модных сервисов, все просто как три копейки. Входящий трафик в месяц -- более ста гигов. Еще раз: СТО ГИГАБАЙТ ЗАГОЛОВКОВ HTTP! А если бы заголовки были бинарными, то этот объем можно было бы сократить в разы, если не на порядок. Вот такие накладные расходы на заголовки HTTP, близкие к нулю...
Я вообще не понимаю этого тяготения к текстовым данным. Хоть убей. Это то же самое, что использовать в программе исключительно строковые переменные. Только неопытным новичкам такое простительно (еще PHP-шникам с JS-никами, но у них и выбора-то нет), а тут нате вам, парсите текст, переводите числа в строки а строки в числа вместо того чтобы просто взять и считать несколько байт в соответствующий контейнер. Зачем? Неужели до сих пор кто-то думает что пользователь сам будет вводить текст запроса? Может он еще и TCP-фрейм должен руками вбить?
В качестве примера победы разума над текстом могу формат PDF вспомнить, который изначально тоже был весь из себя такой текстовый, но когда стало понятно что ни один нормальный человек никогда его руками набивать не станет, а текстовое кодирование бинарного содержания жрет много места, его взяли и сделали бинарным (хотя заголовок все равно оставили текстовым, залипли ребята).
Тут проблема не в текстовой природе. Все-таки жать по серьезному информацию нельзя, так как она обрабатывается оборудованием. А проблема в объеме информации. Тебе всегда нужно узнавать что какие CLR установлены, или форматы в Accept? Тебе нужно знать кто есть referer? Но вся эта требуха передается.
А текст хорош тем, что его легко расширять и вставлять туда можно все что угодно. Бинаризация — только сильно усложнит сам протокол без особого выйгрыша.
Здравствуйте, Curufinwe, Вы писали:
C>Здравствуйте, Mamut, Вы писали:
GZ>>>Тебе нужно знать кто есть referer?
M>>На этом весь SEO держится Знать надо
C>Who is f**ing SEO?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vb-develop, Вы писали:
VD>>Была потребность отправлять через веб-сервисы до сотни запросов в секунду от одного клиента. Работало медленно в первую очередь из-за синхронности запросов. Думаю использование keep-alive могло решить эту проблему. S>Могло. Если lag существенный по сравнению со временами обработки сервера/простоя на клиенте.
Ну да, сервер удаленный, время отклика порядка 40-50 мс. Хотя я еще не до конца понимаю как на ws клиенте такое реализовать. Все-таки подразумевается синхронный запрос к серверу. А это больше на асинхронные похоже.
Здравствуйте, Mamut, Вы писали:
M>На этом весь SEO держится Знать надо
И что из этого? Разве нельзя получать нужную информацию другим запросом? К тому же, получение referer — не гарантировано. Многие прокси их отрубают в целях безопасности.
Здравствуйте, Mamut, Вы писали:
GZ>>И что из этого? Разве нельзя получать нужную информацию другим запросом? M>Каким?
Да например, при первом запросе, сервер проверяет какие параметры есть в хедере, ну например, установлен ли Java или CLR. Если данной информации нет, то он возвращает запрос с каким-то не 200-ым кодом, и говорит что для работы с сайтом нужна такая-то информация в хедере. Клиент вставляет повторяет запрос уже с информацией о версии Java или CLR. Также он вставляет данную информацию для всех запросов на данный сайт.
GZ>>>И что из этого? Разве нельзя получать нужную информацию другим запросом? M>>Каким? GZ>Да например, при первом запросе, сервер проверяет какие параметры есть в хедере, ну например, установлен ли Java или CLR. Если данной информации нет, то он возвращает запрос с каким-то не 200-ым кодом, и говорит что для работы с сайтом нужна такая-то информация в хедере. Клиент вставляет повторяет запрос уже с информацией о версии Java или CLR. Также он вставляет данную информацию для всех запросов на данный сайт.
Не представляю, как это сделать так, чтобы оно работало Например, если мне вдруг понадобился какой-то заголовок, то я просто напишу в любом месте своего кода что-нить типа headers('HTTP_REFERER'). А в предложеном варианте как минимум усложняются анализаторы языков программирования, которые должны вычленить все запросы, на каждый запрос устроить общение с клиентом (предположим, что у нас диалог двунаправленый, а не однонаправленый, как сейчас)...
Здравствуйте, Shabi, Вы писали:
_>>Я вообще не понимаю этого тяготения к текстовым данным. Хоть убей. S>...эти все подлянки из юниксов вестимо...задолбало такое наследие
Полностью солидарен. Юниксоидам традиционнно влом писать модули конфигурации своих программ (даже для комстроки) и они переложили задачу формирования конфигурационных данных на юзера. В итоге все конфиги текстовые, но каждый со своим уникальным и часто совершенно придурочным синтаксисом. В одном имя и значение разделены пробелом, в других символом равенства, в третих двоеточием, в четвертых исключительно табуляцией (за последнее вообще убивать на месте нужно). Аналогично с коментариями, придумывают все что бог на душу положит.
Вот вся это свистопляска и перекочевала в протоколы. Тут конечно могут возразить что мол архитектуры ЭВМ бывают разные, с разной разрядностью и разной последовательностью байт в слове и что бинарные данные будут соответствовать только одной из них. Это все конечно так, но дело в том, что текстовые данные не соответствуют вообще ни одной. Никакая операция приведения разрядности и перестановки байт не сравнится с парсингом псевдочеловеческого исходника с последующим преобразованием строкового представления числа в бинарное. А про объемы я уже говорил выше.
говорится о 100 гигабайтах заголоков ХТТП. Какую долю они составляют от общего трафика
Более 5% (еще примерно столько же заголовочного мусора уходит в каждом ответе, в итоге имеем около 10% оверхеда). Однако дело в том что хостинг-провайдеры ой как не любят входящий трафик! Лютой ненавистью ненавидят просто. И их можно понять, ведь входящий трафик это прямые обытки, в отличии от исходящего.
HB>А, все понял. Не совсем "несколько запросов одновременно"; просто возможность послать следующий запрос, не дожидаясь ответа на предыдущие, так?
Почти, по идее можно и так:
Здравствуйте, Mamut, Вы писали:
M>Не представляю, как это сделать так, чтобы оно работало Например, если мне вдруг понадобился какой-то заголовок, то я просто напишу в любом месте своего кода что-нить типа headers('HTTP_REFERER'). А в предложеном варианте как минимум усложняются анализаторы языков программирования, которые должны вычленить все запросы, на каждый запрос устроить общение с клиентом (предположим, что у нас диалог двунаправленый, а не однонаправленый, как сейчас)...
Нет — однонаправленный. Если посмотришь на Microsoft безопасность, то она обходится двумя односторонними вызовами.
Ну еще раз:
1. Эксплорер направляет запрос на страницу
2. Сервер знает что для отображения данной страницы нужно наличие Java5. Он отправляет в ответ только Http заголовок, например с параметром, Required: Java5 и кодом возврата 333.
3. Эксплорер увидев код 333, читает required и если у него зарегистрирована Java5, то оно добавлет в Http заголок информацию о поддержке Java5, и отправляет тот же запрос заново.
4. Сервер увидев что в запросе все нужные параметры есть — начинает обработку.
Если информация клиентом уже указана, то это один запрос. Не указана — два запроса. Но зато все адресно, и расширяемо. Так можно указывать заказывать информацию технического характера. И это управляется сервером, а не клиентом.
M>Имхо, слишком сложно без явных выгод.
Выгоды в принципе есть. У меня в заголовке пересылается информация о всех FW и Java. Да тут даже выйгрыш не в объеме, а в гибкости. Можно предоставлять больше информации о возможностях клиента.
M>>Не представляю, как это сделать так, чтобы оно работало Например, если мне вдруг понадобился какой-то заголовок, то я просто напишу в любом месте своего кода что-нить типа headers('HTTP_REFERER'). А в предложеном варианте как минимум усложняются анализаторы языков программирования, которые должны вычленить все запросы, на каждый запрос устроить общение с клиентом (предположим, что у нас диалог двунаправленый, а не однонаправленый, как сейчас)... GZ>Нет — однонаправленный. Если посмотришь на Microsoft безопасность, то она обходится двумя односторонними вызовами. GZ>Ну еще раз:
[skip]
Думаю, Михаил (misha_irpen) за такие запросы туда-сюда просто порэжет на куски, да
M>>Имхо, слишком сложно без явных выгод. GZ>Выгоды в принципе есть. У меня в заголовке пересылается информация о всех FW и Java. Да тут даже выйгрыш не в объеме, а в гибкости. Можно предоставлять больше информации о возможностях клиента.
Возможно. Но ту схему надо еще продумывать и продумывать. Особенно придумывать защиту от дурака-программиста
_>Я вообще не понимаю этого тяготения к текстовым данным. Хоть убей. Это то же самое, что использовать в программе исключительно строковые переменные. Только неопытным новичкам такое простительно (еще PHP-шникам с JS-никами, но у них и выбора-то нет), а тут нате вам, парсите текст, переводите числа в строки а строки в числа вместо того чтобы просто взять и считать несколько байт в соответствующий контейнер. Зачем? Неужели до сих пор кто-то думает что пользователь сам будет вводить текст запроса? Может он еще и TCP-фрейм должен руками вбить?
Не согласен, можно даже сказать — категорически не согласен. Во-первых, текстовый протокол избавляет тебя от некоторых платформенных различий, вроде little/big endian, тех же выравниваний. Во-вторых, серьезно упрощает отладку, когда достачно взглянуть на сессию, чтобы идентифицировать проблему. А с бинарным протоколом протрешь до дыр спецификацию, и без нее как без рук. А если еще уволишься, и новому человеку придется разбираться со всей этой байдой, ууу.... Админам может быть удобно. Возможно я вымирающий вид, но я до сих пор использую telnet клиент для тестов и отладки, очень удобно (в случае текстового протокола). С парсингом текста вообще никаких проблем не вижу, если протокол грамотно спроектирован — пишутся легко и просто на ура, а можно и автогенераторами воспользоваться.
В общем, мой опыт говорит о том, что по-умолчанию нужно использовать текстовый формат, и только в случае крайней необходимости — бинарный.
Знать надо
