Заранее извиняюсь за большой текст, но уж больно много вопросов стоит. Буду очень признателен, если хотя бы на часть вопросов получу ответ.
Постановка задачи
Есть WEB-сайт с большим количеством посетителей (написан с использованием ZOPE). Есть отдельный сервер, на котором должна крутиться программа (которую нужно написать), которая выдает некоторую информацию из БД посетителям сайта. Решено разместить эту программу на отдельном сервере из-за соображений масштабируемости/отказоустойчивости. К программе предъявляются высокие требования по производительности, она должна обслуживать около 200 запросов в секунду. Поскольку информация из БД обновляется относительно редко, то при каждом запросе клиента обращаться к БД нет надобности (да и не получилось бы при таких требованиях к производительности), т.е. информация из БД должна загружаться по мере обновления и сидеть где-то в памяти. Платформа, на которой будет стоять программа, — Linux (пока не решено какой, но в принципе без разницы), БД – MySQL (это уже точно). Язык программирования – С++.
Мое видение решения
Программа представляет собой постоянно запущенный демон. Демон прослушивает какой-либо TCP порт. На сайте, при заходе клиента создается сокет, который посылает определенный сигнал с параметрами запроса на машину с демоном. Демон получает параметры запроса, создает отдельный поток, в котором обрабатывается запрос и выдается результат клиенту. Кроме того, при обновлении БД в режиме on-line демону будут посылаться специальные запросы с требованием обновить кэш в памяти (либо всю информацию, либо только часть). Эти запросы будут посылаться с использованием тех же сокетов. Кэш в памяти должен обновляться без прерывания нормальной работы программы.
Вопросы 1. Общая архитектура системы
Как по вашему мнению, способна такая архитектура (сокеты+потоки) обеспечить требуемую производительность (200 запросов в секунду)? Может какую-нибудь CORBA использовать?
2. Требования к аппаратной части
Нужны ли какие-то особые аппаратные ресурсы для данной архитектуры (например, что-то вроде этого: «для поддержки 200 сокетов одновременно нужно как минимум 1 Гб RAM»)?
3. Требования к программной среде
Есть ли какая-то определенная ОС *nix (возможно платная), на которой именно эта архитектура работала бы наиболее оптимизировано? Например, я слышал, что в некоторых ОС потоки и сокеты работаю более оптимизировано.
4. Требования к системе разработки
Поскольку я до этого писал в основном только для Win-платформ, то хотелось бы писать код на Win2K, в Visual Studio, а окончательно компилировать его уже на Linux. В связи с этим вопрос: можно ли программу для Unix написать и получить какой-то промежуточный build целиком на Win-платформе (хотя бы для проверки ошибок компиляции), учитывая то, что в программе используются Linux-специфичные операторы? Рассмотрим к примеру fork для функционирования в режиме демона. Понятно, что ни о каком fork-е Windows и не слышал, и при компиляции ругнется, но может можно как-то переписать заголовочные файлы с Linux на Windows, или же как-то написать какие-то заглушки (а может уже готовые есть)? Или же лучше писать код сразу на Linux?
5. Выбор среды разработки, если писать код на Linux машине
Пока смотрю в сторону Anjuta. Возможно посоветуете другую среду?
Обязательные требования:
— Бесплатна
— Поддержка проектов (чтобы из множества с-файлов получить один исполняемый без возни с параметрами g++)
— Пошаговый отладчик
— Автозаполнение и подсвечивания кода
— Простота освоения (есть ограничения по времени разработки)
Желательные требования:
— Механизм автодокументирования кода
— Отсутствие в необходимости дополнительно ставить на Linux какую-либо GUI подсистему (KDE, GNOM и т.п.)
6. Механизм взаимодействия Web-сервера и демона
Пока остановился на механизме сокетов, с точки зрения производительности демона этот выбор оправдан? Какие еще есть механизмы взаимодействия двух программ на разных компьютерах (на обоих Linux)?
7. Выбор протокола обмена информацией между Web-сервером и демоном
Остановился на TCP-соединениях, по идее UDP протокол быстрее работать должен, из-за отсутствии относительно долгого этапа установления соединения, может использовать UDP?
8. Механизм распараллелирования обработки запросов
После получения запроса демон создает отдельный поток для обработки каждого запроса. Не будет ли проблем с производительностью при наличии одновременно 200 выполняющихся потоков? Как лучше организовать многопоточность: каждый раз создавать новый или как-то использовать существующие неиспользованные (т.е. использовать пул потоков)? Какие механизмы реализации многопоточности наиболее эффективны?
9. Управление демоном
Какими механизмами можно управлять демоном, т.е., например, если потребуется перезагрузить демон, как это лучше сделать, чтобы демон знал, что его перегружают и успел сохранить свои несохраненные данные?
10. Реализация кэша с данными в памяти
Предполагается хранить около десяти небольших по объему таблиц БД в памяти. Как это реализовать хранение, с помощью массивов/списков? Есть ли наиболее эффективные с точки зрения производительности динамические массивы в с++? Где лучше расположить кэш, я слышал, что есть какая-то «Shared Memory», надо располагать его там? Или может просто обойтись одним классом-синглетоном?
11. Механизмы блокировки данных кэша при многопоточности
Есть ли какие-либо встроенные механизмы блокировок в *nix-ах (как, например, mutex-ы в Win32)? Как наиболее эффективно организовать блокировку данных при многопоточности?
12. Пример такого рода программы
Желательно не приводить код какого-либо монстра типа Apache, а увидеть что-нибудь небольшое, чтобы можно было легко разобраться, реализирующее какие-либо части из представленных вопросов.
