Поставьте LiveHTTPHeaders, включите сайдбар. Зайдите один раз на страничку. Нажмите не «Обновить», а в адресной строке ещё раз. Насладитесь тем, что запроса к серверу вообще не было. :) «Обновить» в большинстве браузеров означает безусловный приказ перезагрузить страничку, забив на кеш, что и показывает Firebug.
Ну, в большинстве случаев, 1 килобайта под заголовки хватает. Но если нет, действительно, надо увеличить размер буфера заголовков директивой client_header_buffer_size. Естественно, это скажется на количестве памяти, потребляемой nginx, поскольку, AFAIK, этот объём памяти резервируется на каждый запрос.
Конечно, количество переменных лучше свести к минимуму, однако, в случае сколько-то большого конфига (локаций хотя бы на 30), вы замучаетесь писать этот алиас с одним и тем же путём 30 раз. А если внезапно понадобится переложить document root в другой каталог, так и вообще проклянёте всё-всё-всё. Некошерно делать поиск и замену по всем местам конфига, там где можно просто завести переменную, тем более, что оверхед в данном случае стремится к нулю.
Ну, собственно, апач, который висит на порту 9999 (или любом другом), может выполнять и CGI-скрипты на PHP (или уж, всё-таки, под mod_php — это быстрее). Или я не понял вопроса?..
Честно говоря, мне кажется более интересной, в плане сборки большого расшариваемого стораджа, как-раз AoE. Дело в том, что у неё значительно меньший сетевой оверхед, в отличие от iSCSI. Хотя, конечно, преимуществом iSCSI остаётся возможность маршрутизации пакетов, и бОльшая гибкость в настройке.
Тут есть две проблемы — техническая, и организационная.
Техническая состоит в том, что база покамест не настолько качественна, чтобы ей можно было гордиться (по моему мнению). К сожалению, у нас намного меньше ресурсов и финансовых возможностей, чем у Яндекса, и, тем более, у Гугла. Насколько мне известно, на текущий момент, на каждого нашего разработчика приходится 5-6 человек в Яндексе. И мы не можем позволить себе просто купить компанию — владельца прав на спутниковые карты, как это сделали Яндекс и Гугл. Но Рамблер старается улучшать и развивать свои сервисы, в том числе и данные по географии, насколько это в наших силах.
Организационная проблема — в том, чтобы убедить руководство в том, что это вообще нужно, и подготовить данные для выкладки в публичном формате. В относительно большой организации, получить все необходимые разрешения довольно непросто. Я попробую завтра поговорить с руководством на эту тему, если эти данные действительно кому-то интересны, но, боюсь, выкладка в публичный доступ маловероятна в ближайшее время.
Хотел бы заметить что это не официальная запись в блоге Рамблера. Это мои личные впечатления от работы с картой. Если вам что-то не нравится, не читайте мой блог. Он ни в коем случае не отражает позицию Рамблера, или какой-то его прогресс в работе с гео-данными.
Боюсь, что не могу этого сделать. Я занимался этим по работе, и она является собственностью компании. Хотя, возможно, через некоторое время мы сделаем для неё открытый, или полу-открытый API. :)
>В начале статьи есть концептуальная ошибка где про «работает так быстро». Способен обслуживать большое число соединений и при этом шевелиться — да, но обычно raw-производительность именно по отдаче данных и выюзыванию канала в плешку у обычных серверов бывает выше, чем у асинхронных.
Не согласен. Это возможно, только в том случае, если у вас очень мощные проц и память, и относительно слабый канал. В таких условиях, возможно, многопоточный (например) сервер сможет чуть более эффективно использовать всю ширину канала. Но в противоположном случае — слабый проц, мало памяти, широкий канал — более эффективен будет именно асинхронный сервер.
Это так, хотя бы потому, что переключение между единицами планирования в операционной системе не может знать всех подробностей о каждом из потоков, которые будут выполняться. Она может опираться только на статистику, если этот поток уже выполнялся ранее. А вот state-машина прекрасно осведомлена о состоянии каждого из обслуживаемых подключений, и может, основываясь на этой информации, более оптимально выбирать следующее обслуживаемое подключение. Собственно говоря, по той же причине, user-space треды менее надёжны, но зато в разы более эффективны, чем треды, которые обслуживаются ОС. Вам не надо переключать тяжёлые контексты вне основной единицы планирования, сбрасывать кеш процессора, и прочая, и прочая.
> «количество переключений между контекстами выполнения минимизируется» и «практически нет необходимости в синхронизации процессов или потоков» — неверны. И, если у вас достаточно нагруженные сайты, то вы можете заметить, как nginx грузит процессор
Речь шла про сравнение с поточными и процессными моделями. В случае с nginx нагрузка будет меньше, чем если бы сервер обслуживал запросы в несколько потоков. Разумеется, nginx грузит процессор, и разумеется, в нём есть довольно большой простор для оптимизации, но это отдельная, довольно долгая песня. :)
> Если быть более точным, то они верны только в том случае, когда nginx работает одним процессом, а когда дело доходит до SMP, то в нем используется и локинг и есть переключения контекста, которых Игорь, в принципе, может избежать, но пока он почему-то этим не занимался.
Ну, вероятно, потому, что у него есть основная работа, и её немало. :) А совсем без переключений контекста, даже в случае SMP-системы не обойтись. Мы ведь живём не в идеальном мире… :)
> Например, можно сделать так, чтобы сервер использовал не единственную системную очередь (kqueue), а отдельную для каждого процесса/потока (и соответственно cpu). При этом пусть слушающий сокет и будет только в одной из них, зато можно новые установленные соединения распределять между потоками не добавляя запросов на нотификацию событий о них в одну общую очередь, а наоборот — раскидывая их по собственным kqueue каждого потока.
Мне эта идея кажется неплохой, но её реализация, вероятно, потребует немало времени, поскольку придётся переписывать всё, включая API модулей. Да и, если подумать, блокировки пока не являются «бутылочным горлышком», поскольку всё-равно, большая часть времени сервера уходит на ожидание сетевого ввода-вывода,
Техническая состоит в том, что база покамест не настолько качественна, чтобы ей можно было гордиться (по моему мнению). К сожалению, у нас намного меньше ресурсов и финансовых возможностей, чем у Яндекса, и, тем более, у Гугла. Насколько мне известно, на текущий момент, на каждого нашего разработчика приходится 5-6 человек в Яндексе. И мы не можем позволить себе просто купить компанию — владельца прав на спутниковые карты, как это сделали Яндекс и Гугл. Но Рамблер старается улучшать и развивать свои сервисы, в том числе и данные по географии, насколько это в наших силах.
Организационная проблема — в том, чтобы убедить руководство в том, что это вообще нужно, и подготовить данные для выкладки в публичном формате. В относительно большой организации, получить все необходимые разрешения довольно непросто. Я попробую завтра поговорить с руководством на эту тему, если эти данные действительно кому-то интересны, но, боюсь, выкладка в публичный доступ маловероятна в ближайшее время.
Не согласен. Это возможно, только в том случае, если у вас очень мощные проц и память, и относительно слабый канал. В таких условиях, возможно, многопоточный (например) сервер сможет чуть более эффективно использовать всю ширину канала. Но в противоположном случае — слабый проц, мало памяти, широкий канал — более эффективен будет именно асинхронный сервер.
Это так, хотя бы потому, что переключение между единицами планирования в операционной системе не может знать всех подробностей о каждом из потоков, которые будут выполняться. Она может опираться только на статистику, если этот поток уже выполнялся ранее. А вот state-машина прекрасно осведомлена о состоянии каждого из обслуживаемых подключений, и может, основываясь на этой информации, более оптимально выбирать следующее обслуживаемое подключение. Собственно говоря, по той же причине, user-space треды менее надёжны, но зато в разы более эффективны, чем треды, которые обслуживаются ОС. Вам не надо переключать тяжёлые контексты вне основной единицы планирования, сбрасывать кеш процессора, и прочая, и прочая.
> «количество переключений между контекстами выполнения минимизируется» и «практически нет необходимости в синхронизации процессов или потоков» — неверны. И, если у вас достаточно нагруженные сайты, то вы можете заметить, как nginx грузит процессор
Речь шла про сравнение с поточными и процессными моделями. В случае с nginx нагрузка будет меньше, чем если бы сервер обслуживал запросы в несколько потоков. Разумеется, nginx грузит процессор, и разумеется, в нём есть довольно большой простор для оптимизации, но это отдельная, довольно долгая песня. :)
> Если быть более точным, то они верны только в том случае, когда nginx работает одним процессом, а когда дело доходит до SMP, то в нем используется и локинг и есть переключения контекста, которых Игорь, в принципе, может избежать, но пока он почему-то этим не занимался.
Ну, вероятно, потому, что у него есть основная работа, и её немало. :) А совсем без переключений контекста, даже в случае SMP-системы не обойтись. Мы ведь живём не в идеальном мире… :)
> Например, можно сделать так, чтобы сервер использовал не единственную системную очередь (kqueue), а отдельную для каждого процесса/потока (и соответственно cpu). При этом пусть слушающий сокет и будет только в одной из них, зато можно новые установленные соединения распределять между потоками не добавляя запросов на нотификацию событий о них в одну общую очередь, а наоборот — раскидывая их по собственным kqueue каждого потока.
Мне эта идея кажется неплохой, но её реализация, вероятно, потребует немало времени, поскольку придётся переписывать всё, включая API модулей. Да и, если подумать, блокировки пока не являются «бутылочным горлышком», поскольку всё-равно, большая часть времени сервера уходит на ожидание сетевого ввода-вывода,