|
|
|
Вопрос архитектуры. Потянет ли СУБД нагрузку?
|
|||
|---|---|---|---|
|
#18+
Здравствуйте уважаемые форумчане! Помогите разобраться с архитектурой системы. Вариант 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), которое было сделано? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2011, 16:24 |
|
||
|
Вопрос архитектуры. Потянет ли СУБД нагрузку?
|
|||
|---|---|---|---|
|
#18+
Извените, я выбрал не тот раздел форума. Тема перемещена в другой раздел: http://www.sql.ru/forum/actualthread.aspx?tid=894648 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2011, 16:34 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=37522580&tid=1541951]: |
0ms |
get settings: |
6ms |
get forum list: |
18ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
182ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
| others: | 221ms |
| total: | 496ms |

| 0 / 0 |
