ФБП: Сеpвеp 3.02. Первые впечатления



Posted by Анатолий Анимица on June 20, 1999 at 08:20:14:

In Reply to: Финансы без пpоблем:Сеpвеp 3.02 posted by Аpкадий Водяник, ЗАО Хакеpс Дизайн on June 19, 1999 at 20:39:30:

AAA

Привожу первые результаты оценочного тестирования сервера "Финансы без проблем" v.3.02.

Вид мнемосхемы после старта приведен ниже. Машина P166MMX 64M, база отчасти видна на мнемосхеме, общий объем - примерно 30МБ (вместе с *.txa и служебными файлами).

Замечания по степени важности.

1. Все работает так, как описано. Отклонений не замечено.

2. Все старые файлы были заблаговременно удалены переименованием директории \TXA и созданием новой и пустой.

3. Старт сервера на версии от 20.04 выполнялся примерно за 2 минуты (6 месяцев, видно, сколько операций). Старт 3.02 с созданием всех документов заново - около 4000 единиц хранения - занял около 20 минут. Рестарт - около 6 минут.

4. Причина. В реализации 3.02. не лучшим образом реализовано подавление генерации пустых документов - паразитных файлов длиной 0 байт, которые в моих реализациях подавлялись просто блокировкой вывода в файл упреждающим образом. Даже без всяких попыток открытия. Здесь же многострочные операции порождают паразитные пары файл длиной 0 и дескриптор к нему. В результате вместо 4000 актуальных файлов и 4000 дескрипторов к нему создано около 20000 файлов и соответственно дескрипторов, что заметно замедляет сервер и ухудшает его реактивность при последующих инжекциях данных в прошлое. В реальном времени, естественно, все как и раньше. Реактивность даже улучшилась, очевидно, за счет удержания контекста в размерах, не допускающих свопинга. Все-таки вручную действительно не всегда можно точно и неизбыточно задать размер контекста.

5. При пересчете после вмешателства в прошлое (инжекции операции в 1 января) сервер вынужден открывать и тестировать 20000 дескрипторов. У меня вместо этого контролируется значение сигнатуры такого же содержания в extrd.dat. Замедление - 200 секунд на 20000 дескрипторов (10ms на 1). Хорошо согласуется с частотой вращения диска. Видно, что проблема с архитектурой PC и Windows. Упреждающее чтение в дисковый кэш улучшит дело, но не настолько.


6. Резюме. Работать можно уже сейчас. Ничего не разваливается. Но я бы посоветовал пока воздержаться.

7. Предложение. Считаю возможным предложить отказаться от идеи дескриптора первичного документа и вернуться к реализованному мной хранению информации о создании ПД в строке сигнатуры в extrd.dat. Это не только уменьшит размер базы в целом, но и увеличит общую надежность за счет снижения нагрузки на файловую систему Windows 98 и NT. Тестирование проводилось на машине с FAT16, с NTFS не раньше среды удастся провести, поэтому проблема полупустых кластеров тоже дает себя знать. И последнее. Формирование по-старому сигнатуры в extrd.dat позволяет при случае использовать более тонкие ситуации "перегенерировать документ и выпустить его релиз", зависимые от прошлого, характеристических сумм и так далее, что в принципе ограничено структурой дескриптора в новом механизме ПД в версии сервера 3.02.


8. С другой строны, методы никак не противоречат друг другу и могут комбинироваться. Но новая методика снижает верхнюю границу масштабируемости (против оценочной в 500000 файлов за год в динамике с конторлем на старте сервера до примерно 50000 и то на самых быстрых PC - скажем, PII-350 256 MB.

А результаты в высшей степени любопытные. Ни за что бы не подумал еще год назад, что мы будем легко говорить об автоматическом администрировании десятков тысяч файлов и сетовать о недостижимости порога в полмиллиона!


Полюбуйтесь на картинку



Финансы без пpоблем: Сеpвеp 3.02 (C)1995-99 Хакеpс Дизайн, http://www.hdru.com
________________________________________________________________________________
Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Итого
2489 1368 1317 1633 1347 881 9035
----------------------------------ta----------------------------------

D' 30000 _________________________________________····························
+------------------------------------------------------------------------------+
¦ Ожидание ¦Новая опеpация¦Удаление ¦Извлечение списка¦Выполнение фоpмы¦Дpугое¦
+----------+--------------+----------+-----------------+----------------+------¦
¦ SU¦··············¦··········¦·················¦················¦······¦
¦ B1¦··············¦··········¦·················¦················¦······¦
¦ B2¦··············¦··········¦·················¦················¦······¦
¦ M1¦··············¦··········¦·················¦················¦······¦
¦ A1¦··············¦··········¦·················¦················¦······¦
¦ A2¦··············¦··········¦·················¦················¦······¦
¦ A3¦··············¦··········¦·················¦················¦······¦
¦ A4¦··············¦··········¦·················¦················¦······¦
¦ MG¦··············¦··········¦·················¦················¦······¦
¦ S¦O KEY=FAAN-697¦··········¦·················¦R SKLAD ¦······¦
+------------------------------------------------------------------------------+

Метка:"1999" в 1999. Сегодня 20 июня 1999
Быстpые факты: Да. Быстpый ged: Да. Пpиоpитет: обычный. Кэш фоpм: Да.



ААА


Пpишедшие ответы: