какой веб-сервер / мод / технику я должен использовать, чтобы обслуживать все из памяти?

Question

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

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

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

- Все еще недостаточно быстро? встроенные веб-серверы , такие как TUX , могут быть очень быстрыми.

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

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

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