Как такой сайт, как rambler, так быстро обслуживает динамический контент? Даже быстрее, чем Yahoo (у которого есть сервер в моей стране - Юго-Восточной Азии; у rambler его нет).
Это чисто способность Nginx? Где я должен искать, чтобы узнать о таких возможностях?
В значительной степени новичок здесь, я считаю, что serverfault.com, если он обслуживается из Nginx, будет намного быстрее IIS 7 (при условии, что время доступа к базе данных будет одинаковым в обоих случаях). Это справедливое предположение?
Редактировать:
Сообщение от Карла с использованием Nginx перед IIS7
Вы можете увидеть этот презентация для обзора внутреннего устройства nginx. Основное отличие заключается в асинхронной обработке запросов вместо использования потоков, как это делает Apache. Вы можете посмотреть на эта документация также.
Как такой сайт, как rambler, так быстро обслуживает динамический контент? ... Это исключительно возможности Nginx? Где я должен искать, чтобы узнать о таких возможностях?
Это практически не имеет ничего общего с используемым веб-сервером - и nginx, и IIS, и Apache «достаточно быстры» и обычно выполняют свою работу за миллисекунды. nginx намного быстрее, чем Apache, но это просто означает, что владельцу сайта потребуется меньше серверов для части веб-обслуживания - nginx не передает данные вам быстрее.
Менее важная часть - скорость на стороне сервера., то есть время, необходимое для создания HTML. Более важная часть - производительность внешнего интерфейса., под которыми я подразумеваю HTML, CSS, Javascript и изображения, их количество, размер и их правильную доставку (сжатие HTTP, кеширование).
Конечно, скорость на стороне сервера по-прежнему важна, я не говорю, что ее следует игнорировать или что это не имеет значения. Но, как правило, это наименьшая часть скорости работы конечного пользователя - работа на стороне сервера часто выполняется менее чем за 500 миллисекунд, но страница не готова до того, как пройдут 3000-5000 миллисекунд. Большая часть этого времени уходит на загрузку ресурсов внешнего интерфейса (CSS, Javascript, изображения).
Стив Содерс выполнял первоначальную работу в Yahoo, сейчас он работает в Google. Его первая книга «Высокопроизводительные веб-сайты». это лучшая отправная точка для изучения создания быстрых веб-сайтов. Тот же материал, что и в его книге, можно найти в этот видео разговор, и эти правила дизайна. Однако я считаю, что книгу легко читать и гораздо легче понять.
Вы можете запускать сайты через Тестер WebPageTest.org - это даст вам хорошее представление о внешней части этих сайтов и о том, почему они работают быстрее или медленнее.
Я считаю, что serverfault.com, если он обслуживается из Nginx, будет намного быстрее IIS 7 (при условии, что время доступа к базе данных будет одинаковым в обоих случаях). Это справедливое предположение?
Нет, это недоразумение. :-)
Nginx чаще используется для балансировки нагрузки других приложений / серверов и обслуживания статического контента, чем в качестве полноценного сервера.
Например, вы можете написать приложение, используя одну из многих фреймворков Python, и сделать так, чтобы nginx был интерфейсом для многих экземпляров этого (возможно, распределенного по нескольким машинам). В этом случае nginx выполняет две задачи: он напрямую обрабатывает запросы статического контента, такого как изображения и таблицы стилей (и благодаря своей конструкции он делает это очень быстро) и передает динамические запросы приложению, распределяя нагрузку между всеми известными ему экземплярами. Это очень популярная конфигурация и в сообществе Ruby on Rails.
Есть две другие возможные причины, по которым Рамблер может показаться вам быстрее, чем местный сервис Yahoo. Во-первых, у локального Yahoo PoP может просто не хватить ресурсов для обслуживания количества запросов, которые он получает быстрее, поэтому, возможно, простое добавление дополнительного оборудования (при условии, что программное обеспечение хорошо масштабируется таким образом) ускорит его (но, предположительно, разница не стоит затрат на обслуживание дополнительного комплекта, иначе Yahoo сделала бы это). Другая большая разница может заключаться в бэкэнде, а не в веб-сервере - две службы, несомненно, будут иметь очень разные структуры базы данных, и даже в противном случае они вряд ли будут выполнять точно такое же разнообразие запросов (и количество аппаратное обеспечение, предназначенное для архитектуры базы данных, также окажет значительное влияние).
Анализ того, почему одна служба быстрее другой (в целом или в определенных обстоятельствах), обычно не дает однозначного ответа - существует множество способов разработать приложение, которое предназначено для масштабирования для многих тысяч пользователей, каждый со своим собственные преимущества, проблемы и компромиссы, и даже если учесть все эти различия, каждый сайт будет иметь разную динамику базы пользователей, плюс есть проблемы с сетью, которые тоже не зависят от дизайнеров.
nginx, возможно, но более масштабируемая архитектура с разумной балансировкой нагрузки перед серверами статического контента / генераторами динамического контента. если вы действительно хотите получить отличное впечатление от конечных пользователей, вам, вероятно, следует переместить контент ближе к «глазам» - используйте CDN.
если интересует тема - загляните этот и который и .. ну - гугл; -]
Лучшие сайты используют ускорители приложений, такие как Zeus ZXTM - они могут кэшировать динамические ответы во многих случаях, что, очевидно, приносит большую пользу.
Вот хорошее объяснение: http://www.aosabook.org/en/nginx.html
Мне трудно увидеть сбой сервера намного быстрее (возможно, у SO могут быть проблемы с загрузкой из-за трафика?), Поскольку здесь, в ЕС, по моему маршруту уже происходит мгновенная загрузка страницы. Это намного быстрее и быстрее, чем на большинстве местных новостных сайтов и так далее.
Большинство очевидных проблем со временем загрузки и задержкой возникает между сервером и конечным пользователем imo, а не с фактической производительностью сервера (если кто-то неправильно рассчитал или спроектировал что-то). Различные сайты могут быть маршрутизированы по-разному, и есть большая вероятность, что для меня локальный сайт в стране будет иметь большую задержку, чем что-либо на всей планете - все зависит от такого количества переменных, что вы не можете сказать, что это решается просто с помощью службы обновить / переключить, если вы не знаете, где проблема для конкретного использования (r) ...
Очевидно, что кеширование различных типов на сервере имеет большое значение, но, насколько мне известно, все эти сайты уже делают это.