Здравствуйте уважаемые форумчане! Помогите разобраться с архитектурой системы.

Вариант 1

Имеется система тестирования знаний, которая делится на два интерфейса: web-интерфейс (для пользователей) и windows-приложение (для админа). Web-интерфейс работает на Apache+PHP. Каждый тест представляет отдельный файл, который является отдельной SQLite базой, а также есть общая база данных SQLite, где хранится общая информация (тесты, пользователи, результаты). При запуске пользователем тестирования, весь тест целиком загружается в сессию PHP (массив $_SESSION). Сами сессии хранятся в виде файлов. В процессе тестирования все данные читаются и пишутся в сессии, а после окончания тестирования сохраняются в базы SQLite. Кроме этого, каждый ответ пользователя фиксируется в SQLite и каждые 7 секунд каждый браузер JavaScript-ом посылает запрос, который пишет в общую базу информацию, которая нужна, чтобы проинформировать систему о своем присутствии, чтобы система знала, кто ещё жив, а кто отвалился (например, закрыл браузер).

Результат использования:
Уже при небольшом числе подключений (~10-20) на среднем компьютере возникла огромная нагрузка на процессор, память и жесткий диск. Задержки при переключении между вопросами стали недопустимо большими.
После этого были внесены изменения:

Вариант 2
Была убрана фиксация ответов пользователя в процессе тестирования в базу SQLite. Все данные сохраняются разом после завершения тестирования. Информационное сообщение браузерами теперь отправляется не каждые 7 секунд, а каждые 45 секунд. Фактически при запуске тестирования данные загружаются из SQLite в сессию PHP и затем вся работа идет только с этими сессиями, там хранится все (вопросы, варианты ответов, ответы).

Результат использования:
Большая нагрузка на жесткий диск, т.к. файлы сессий хранятся на жестком диске, и порой могут весить до 3 Мб. Причем каждый раз, когда пользователь дает ответ или переключается между вопросами, то вся сессия из файла загружается PHP в память, а затем пишется обратно в файл. Насилие жесткого диска огромно, а также он тянет за собой процессор, но там ещё допустимая нагрузка и память допустимо расходуется. Также имеется проблема когда несколько пользователей пишут в SQLite свои результаты. При работе из PHP проблема не заметна, т.к. там выстраивается очередь, а вот когда админ работает в Windows-интерфейсе, то у него могут возникать сообщения о том, что база заблокирована, т.к. SQLite на самом деле не подходит для многопользовательской работы!
После этого были внесены изменения:

Вариант 3
В качестве базы для хранения общих данных вместо SQLite была выбрана FireBird. Сессии PHP теперь журналируются в redis (кешируются в ОЗУ), а не хранятся на жестком диске.
Результат использования:
Нагрузка на жестак только при запуске тестирования и окончании (запросы в базы тестов SQLite). Общие данные теперь в FireBird поэтому проблем блокировок нет. Нагрузки на жесткий диск теперь нет, т.к. работает redis. Увеличился расход ОЗУ, но допустимо

Т.е. система услажнилась от первоначального варианта. Было Apache+PHP+SQLite, теперь Apache+PHP+SQLite+FireBird+redis.
При этом каждый тест остается в отдельном SQLite. Сделать приложение администратора с возможностью работать удаленно сложно. А такие требования возникли. Конечно можно извратиться и усложнить все ещё сильней.
Но возникает мысль – Зачем все так было усложнять?! Может быть можно было использовать классическую схему, когда все всегда читается и пишется в клиент серверную СУБД FireBird или PostgreSQL. Но тогда будут постоянные SQL запросы на чтение и запись.
Если хранить все только в одной БД на PostgreSQL? Каждый раз когда пользователь читает вопрос, то загружать его несколькими SELECT, а когда дает ответ делать UPDATE и не париться с этими SQLite, сессиями и т.д. Т.е. вопрос в следующем: Потянет ли самая классическая немудренная схема следующую максимальную нагрузку:
200 подключений, каждое из которых делает каждую секунду 2 запроса select (читает вопрос и варианты ответа) и 1 update (пишет ответ) на таблицы до 10000 записей.
Компьютер средний 2-4 гига ОЗУ, средний процессор, HDD 7200 оборотов.
Опытные администраторы СУБД скажите, пожалуйста, PostgreSQL или FireBird потянут 200 update-ов и 400 select-ов в секунду на такой машине или лучше оставить то извращение (сессии, redis), которое было сделано?

Gluk (Kazan)Надеюсь вы в курсе, что SQLite блокирует БД целиком на каждую пишущую транзакцию?

Поэтому ту БД, что многопользовательская мы заменили на FireBird. Но систему теперь сложно развивать, тесты хранятся в отдельных SQLite, результаты тестирования тоже в отдельных SQLite, а общая база FireBird. Все разрозненно. Ещё намудрили с этими сессиями. Хотя тут не ясно, т.к. может и правильно сделали, т.к. нагрузки в процессе тестирования на жесткий диск вообще нет! Но зато память жрется. Мы хотим сделать, чтобы админ мог через Windows-приложение коннектица к БД удаленно. С общей базой нет проблем (FireBird), а то, что каждый тест в отдельной SQLite - тут сложности, т.к. нужно удаленно передавать весь файл, а потом его возвращать. Для нужно какое-то средство самому писать, либо задействовать Apache и PHP. Поэтому возникла мысль, что мы ну слишком все усложням, т.к. при классической схеме таких проблем вообще бы не было, одна база и все на мази, но может по нагрузке все провалилось бы ...

BlackEricexecoma,
сколько у вас клиентов?
Объем данных, число запросов в секунду?

Как я писал, система должна работать, при максимальной нагрузке:

200 активнейший подключений - каждое 2 select и 1 update в 1-2 секунды на таблицы до 10000 записей - и это в процессе тестирования, т.к. при запуске тестов возникает вообще множество select-ов, а по окончанию множество insert-ов и update-ов. Я не знаю, вообще тут возможно дать ответ на мой вопрос, скорее всего нужно проводить испытания. Я просто подумал, что может у кого-нибудь уже есть опыт, который позволяет оценить производительность клиент-серверных СУБД на обычных ПК, и сможет дать ответ на вопрос - (не)потянет.

Таблоид, спасибо за ценную информацию!

ScareCrowавторПри запуске пользователем тестирования, весь тест целиком загружается в сессию PHP (массив $_SESSION).
авторкаждые 7 секунд каждый браузер JavaScript-ом
рыдалЪ.
налицо полное непонимание работы php.
Бери ужо Memcached DB и не парься.

А что там может быть не понятного? А Memcached это гамно. Memcached не позволяет загружать большие объекты (вроде больше метра, т.к. у них какие-то сложности с индексами возникли) и ещё к тому же падает при большой нагрузке и сильном расходе памяти теряя все данные без возможности восстановления. А также когда ему не хватает памяти, то он начинает удалять наиболее старые данные, а тут ничего удалять нельзя. Все это проверенно как раз на этой системе. У redisa пока такого не было замечено, тем более он умеет сливать данные на хард (например, регулярно по времени) и после сбоя их восстанавливает.

ScareCrowа, еще mongobd можно. оно тоже все в памяти держит.
а по хорошему меняй архитектуру. на каждый аякс запрос подсасывать только в сессию по 3 метра - это жесть. вали то что не нужно в каждом чихе в память/файлы и читай оттуда по мере надобности.

Хочется, чтобы все хранилось красиво в одном месте одной базе, а не в куче баз двух разных СУБД, сессиях, кеше и т.д. Т.к. проект невозможно развивать дальше, наращивать функционал и т.д. Поэтому и возникли такие вопросы..