Добрый день!
Работа проекта: существует сервер БД и проект который валит запросами эту БД, получает ответ и сохраняет данные в XML, после когда пользователь хочет увидеть отчет - XML тулится с XSL и выдает XHTML код.
Проблема: Очень долго отрабатывает формирование XML и чтение после его создания.
Что вижу я:
1. Долго отрабатывают запросы которых 10 и каждый из них имеет по 4-5 JOINов
2. Данные хранятся в файле и долго туда пишутся, так как они составляют порядка 10Mb.
3. Так как проект работает с DOM, есть мнение что DOM тяжко работать с такими объемами и он тупит, решение: использовать SAX.
Что вы думаете по этому всему поводу. Задача оптимизировать проект.
новые сообщения
ответы на мои сообщения
избранное
скрытые темы
случайный топик
открыть всё в новых вкладках
Форум → Программирование → PHP для идиотов → Хранение больших объемов данных
Хранение больших объемов данных
-
Сообщения:
25
Репутация:
N
Группа:
Кто попало
-
Сообщения:
135
Репутация:
N
Группа:
Кто попало
25 апреля 2008 г. 16:13, спустя 2 часа 43 минуты 48 секунд
Что вы думаете по этому всему поводу. Задача оптимизировать проект.
Круто.. :D -
Сообщения:
843
Репутация:
N
Группа:
Джедаи
26 апреля 2008 г. 0:32, спустя 8 часов 19 минут 19 секунд
Название СУБД, ее дамп и прочую инфу придумать самому? -
Сообщения:
5
Репутация:
N
Группа:
Кто попало
26 апреля 2008 г. 8:49, спустя 8 часов 17 минут 2 секунды
Что ж, были и у меня подобные проблемы.
вариантов решения чють больше чем несколько:-)
1. Мускул плохо обрабатывает сложные запросы, следовательно лучше разбить один сложный запрос на несколько простых, выполняемых последовательно.
2. Делать `двухслойную` БД. В первом слое производится анализ запроса и координация второго слоя, во втором - большое количество таблиц уже обработанных JOINами. Минус этого варианта увеличение объема баз, усложнение управления и координации.
3. Поменять БД. Практика показывает не менее 30% запросов дублируются. То есть, при большом объеме запросов , имеет смысл поставить СУБД которая будет выдавать такие запросы из кеша. Например Oracle.
4. Чисто админский путь. Соеденить сервак БД и HTTP не через общую сеть, а кроссовером, чтоб никто не мешал обмену информации.
Думаю пока достаточно:-) -
Сообщения:
25
Репутация:
N
Группа:
Кто попало
26 апреля 2008 г. 12:34, спустя 3 часа 45 минут 28 секунд
Спасибо за советы. Но я думаю решил эту проблему следущим образом: После профайлинга я обнаружил что 60% времени тратиться на формирование XML и последующею запись в фаил.
Отчет сразу не формируется, а на запрос с LIMIT выводится сразу XHTML страничка. А уже сли конечно нужно сохранить репорт то прийдется подождать и отчет будет сохранятся в XHTML и XLS по выбору.
То есть часть XML и XSL и последующея XSL трансформация удаляется из проекта.
Что думаете? -
Сообщения:
4306
Репутация:
N
Группа:
в ухо
26 апреля 2008 г. 19:58, спустя 7 часов 23 минуты 30 секунд
Бред во всех пунктах … ))))
Что ж, были и у меня подобные проблемы.
вариантов решения чють больше чем несколько:-)
…
Пожалуйста, авторизуйтесь, чтобы написать комментарий!