какой webserver/mod/technique следует использовать для обслуживания всего из памяти?

Question

У меня есть много поисковых строк, из которых я буду генерировать мой ответ.

Я думаю, что IIS с Asp.net позволяет мне сохранять статические поисковые таблицы в памяти, которые я могу использовать для быстрого ответа на мои ответы.

Существуют ли, кроме того, решения non .net, которые могут делать то же самое?

Я посмотрел на fastcgi, но я думаю, что это запускает X процессов, каждый из которых может обрабатывать Y-запросы. Но процессы по определению защищены друг от друга. Я могу настроить fastcgi на использование всего 1 процесса, но имеет ли это последствия масштабируемости?

что-либо с использованием PHP или любого другого интерпретируемого языка не будет летать, поскольку он также связан с cgi или fastcgi?

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

Решение может работать под WIndows или Unix ... это не имеет большого значения. Единственное, что имеет значение, так это то, что будет много запросов (100/сек сейчас и возрастет до 500/сек в год), и я хочу уменьшить количество веб-серверов, необходимых для его обработки.

Текущее решение выполнено с использованием PHP и memcache (и случайного попадания на сервер SQL-сервера). Хотя это быстро (для php в любом случае), Apache имеет реальные проблемы при передаче 50/сек.

Я поставил щедрость на этот вопрос, так как я не видел достаточно ответов, чтобы сделать правильный выбор.

На данный момент я рассматриваю Asp.net или fastcgi с C (++).

Answer 1

Похоже, вы должны использовать хранилище данных с ключевыми значениями в памяти, например Redis, если вы планируете использовать несколько веб-серверов в будущем, а не обязательно использовать централизованное хранилище. Redis особенно идеален в этом сценарии, поскольку он поддерживает расширенные структуры данных, такие как списки, наборы и упорядоченные наборы. Его также довольно быстро, он может получить 110000 SETs/second, 81000 GET/сек в ящике Linux начального уровня. Check the benchmarks. Если вы спуститесь по этому маршруту, у меня есть c# redis client, который упростит доступ.

Для использования общей памяти вам нужен сервер приложений, который «всегда работает» в том же процессе. В этих случаях вы можете использовать статические классы или общий кэш приложений. Наиболее популярными «серверами приложений» являются любые контейнеры сервлетов Java (например, Tomcat) или ASP.NET.

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

Answer 2

Прежде всего, позвольте мне попытаться думать с вами на ваших прямых вопросов:

- Для выполнения, что вы прицеливания на, я бы сказал, что требуют общего доступа к памяти для поиска столов является излишеством. Например, разработчики memcache по ожидаемой производительности: «На быстрой машине с очень высокой скоростью сети (или локальном доступе - ред.) Memcached может легко обрабатывать 200 000 запросов в секунду.«

- В настоящее время вы, вероятно, ограничены cpu-time, так как вы генерируете каждую страницу динамически. Если это вообще возможно: кеш, кеш, кеш! Загрузите свою первую страницу и перестройте ее только раз в минуту или пять минут. вошедших в систему пользователях, кэш-страницы, к которым пользователь может перейти снова в своем сеансе. Например: где 50 запросов не слишком плохо для динамической страницы, обратный прокси-сервер, такой как лак, может обслуживать thousands статических страниц a . второй на довольно посредственные сервер Мой лучший намек будет смотреть в настройки обратного прокси-сервера с помощью varnish или squid

. - если вам все еще нужно создать много страниц динамически, используйте php accelerator, чтобы избежать необходимости компилировать php каждый раз, когда скрипт запущен. Согласно w ikipedia, это увеличение производительности в 2-10 раз.

- mod_php - это самый быстрый способ запуска php.

- Помимо использования fastcgi, вы можете написать модуль apache и иметь свои данные в общем пространстве памяти с самим веб-сервером. Это может быть очень быстро. Тем не менее, я никогда не слышал, чтобы кто-нибудь делал это для повышения производительности, и это очень негибкое решение.

- Если вы переходите на более статический контент или переходите по пути fastcgi: lighthttpd быстрее, чем apache.

- Все еще не достаточно быстро? in-kernel webservers, такой как TUX, может быть очень быстрым.

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

Посмотрите на презентацию this на архитектуре facebook, а также презентацию о создании «масштабируемых веб-сервисов», содержащей некоторые примечания по дизайну flickr.

Кроме того, в facebook перечислены impressive toolset, которые они разработали и внесли свой вклад. Более того, они делят заметки на своих architecture. Некоторые из их улучшающих производительность трюков:
- некоторые улучшающие производительность настройки до memcache, такие как memcache-over-udp.
- hiphop является компилятором php-to-optimized-C++. Инженеры Facebook утверждают, что сокращение использования процессора на 50%.
- внедряйте интенсивные вычислительные услуги на «более быстрый язык» и проводя все вместе, используя thrift.