Http запросы — мы все это делаем неправильно

Делали что-то подобное

function curl_post_lookslikeasync($url, $params)
{
    foreach ($params as $key => &$val) {
      if (is_array($val)) $val = implode(',', $val);
        $post_params[] = $key.'='.urlencode($val);
    }
    $post_string = implode('&', $post_params);

    $parts=parse_url($url);

    $fp = fsockopen($parts['host'],
        isset($parts['port'])?$parts['port']:80,
        $errno, $errstr, 30);

    $out = "POST ".$parts['path']." HTTP/1.1\r\n";
    $out.= "Host: ".$parts['host']."\r\n";
    $out.= "Content-Type: application/x-www-form-urlencoded\r\n";
    $out.= "Content-Length: ".strlen($post_string)."\r\n";
    $out.= "Connection: Close\r\n\r\n";
    if (isset($post_string)) $out.= $post_string;

    fwrite($fp, $out);
    fclose($fp);
}

Пул есть, да. Вот это вроде рабочий вариант, как было я уже не вспомню сейчас.

Http запросы — мы все это делаем неправильно

Почему только я. Нас тут много. Вы все не уйметесь? Вам видео мало? Уже понятно, что вы тут самый умный, остальные несут чушь.
Щас еще скажите опять, что там в видео ни слова про http. Конечно, транспортный уровень ведь решает все проблемы keep-alive. Затестено на фавиконке, понимаю.

Http запросы — мы все это делаем неправильно

Уже было ))
Мы обработали не тот ответ, на который отправляли запрос. У нас залогиненые пользователи посмотрели чужой контент. Воспроизвести только сложно, нужна большая нагрузка.

Http запросы — мы все это делаем неправильно

CURL и напрямую через nginx, с помощью LUA — модули из сборки openresty.

Http запросы — мы все это делаем неправильно

Elasticsearch может так работать.
Не очень быстро, по сравнению с традиционными реляционными базами, но для документов подходит отлично. Она лучше, чем остальные подобные решения тем, что отлично масштабируется, скалируется в разных плоскостях, имеет встроенный полнотекстовый движок, встроенное гео и она практически неубиваемая в условиях геораспределенных данных.

Http запросы — мы все это делаем неправильно

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

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

Http запросы — мы все это делаем неправильно

База данных и очередь сообщений у меня по http работает, не не применимо ни разу )) Ну да ладно, это не про вас ))

Http запросы — мы все это делаем неправильно

вот видео.

Http запросы — мы все это делаем неправильно

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

При чем тут безделье админа, если производительность сервера от этого ну никак не зависит? От парней, которые покодить пришли, а не продукт разрабатывать, да, легко ))

Http запросы — мы все это делаем неправильно

Вы серьезно не понимаете? Что то, как вы назвали статью, применимо к широкому кругу задач, в том числе и серверных. И если заниматься посерьезнее вещами, чем вы описали, а например писать что-то серверное, да еще и под нагрузку, то будет ошибкой думать, что кипалайв решит все проблемы. Вы этого в статье не учли. Вот ваши функциональные тесты стали более лучше. А то, что они могут стать неадекватными в один момент или напрягут админа, вас ведь не касается, да?) Главное всем показать, что фавиконка стала быстрее качаться!)

Если вы не понимаете о чем я, то почему вы решили, что я недалекий человек?)

Http запросы — мы все это делаем неправильно

Это вы подумали, что я вас обезьяной назвал. Вообще так доклад Аверина назывался. Обижаться на такое не стоит, Сергей знатный конечно тролль, но очень умный и понятно все объясняет.

Как будто по теме статьи, да.
Про контент не будем, видно, что объяснять, как устроены нынешние страницы web2.0 будет сильно долго. Как и то, что операционной системе сильно пофигу, браузер у нее висит в ESTABLISHED и смотрит страницу, или сервис, который эту страницу генерит. Зато не пофигу на количество соединений в целом в системе.
Вам тут половина посетителей в коментах пытаются рассказать, что keep-alive — это круто, но с другой стороны все довольно печально и дорого.
Вот если бы вы статью назвали «как быстро скачать фавикон», не было бы споров.
А так, может это для вас будет открытием, но сервисы которые за вебсервером и которые генерят контент, тоже умеют общаться по http между собой. И там тоже можно включить keep-alive для http. Это же не только курл и браузер.

Http запросы — мы все это делаем неправильно

Что конкретно неадекватного? Я вам рассказал, как выглядит keep-alive со стороны сервера. Что конкретно вам не понравилось? Если вам неинтересно, не читайте )) Я понимаю, что фавикон тестить — это довольно круто и достойно статьи на хабре, но вы по-моему не представляете, сколько там вообще проблем вокруг всего этого.

И если интегрировать keep-alive в свой проект, то надо много считать и думать, иначе можно сильно опростоволоситься или попасть на бабло во всяких resource-cost хостингах ))

Http запросы — мы все это делаем неправильно

Как вы так, пишите скрипты и не понимаете, как в целом они работают? Круто! Удачи вам в этом нелегком деле )

Http запросы — мы все это делаем неправильно

Да ладно. Вы сейчас про http протокол, или про контент, который вы получили посредством такого протокола?
Я говорил про то, как это выглядит со стороны сервера.

Сервер, который обеспечивает keep-alive для клиента, он внутри тоже делами какими-то занят, нет?
— инициализация бекенда,
— бекенд лезет в базы,
— считаются и наполняются кеши,
— подсоединяются в работу различные сетевые сервисы,
— генерится контент.

Это все коннекции. Они не только на обработку веб-сервером «GET /» и разговор с браузером тратятся. Проблема в том, что веб-сервер, как таковой, имеет очень ограниченное число таких коннекций. WEB уже давно очень сложный и давно уже не визитка из серии «привет, я Вася, это моя страничка в интернет».

Http запросы — мы все это делаем неправильно

Помню, Сергей Аверин из Badoo про эту штуку рассказывал, про гранату в руках обезьяны.

Надо не забывать, что использование keep-alive и pconnect накладывает дополнительные требования к продукту и его разработке.
— клиент, протокол и сервер должны быть подготовлены
— в highload окружениях все это ведет себя не так, а иногда и совсем не так, как описано в мануалах.
— надо не забывать об ограничениях операционной системы, где крутится все это добро. Здесь от памяти, до сетевого стека.

Протокол надо делать stateful, например, чтобы всегда знать состояние полученного соединения и что там вообще происходит с payload. Также надо научиться сопоставлять запросы и ответы, из-за асинхронной природы сокетов. С базами данных будет тяжело, а также со всякими thrift и прочее.
Ну и почти любой инструмент у нас из коробки не готов к pconnect и к connection pooling.

В общем, не серебряная пуля, никак.

Не повторяйте моих ошибок на собеседовании

Про тимлида хорошо сказали!

Вышел финальный релиз PHP 5.5.0

А впиленные корутины не помогут?

Вышел финальный релиз PHP 5.5.0

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

Вышел финальный релиз PHP 5.5.0

А signal-based архитектура, очереди всякие и gearman тут не помогут?

Выбор распределенной файловой системы для Linux. Пару слов о Ceph и остальных

Есть механизм снапшотов на уровне блочного устройства.
У файлухи пока тоже есть, но, говорят, выпилят скоро.