Дано: База 1С 7.7 в которой 1Cv7.md — 1,8 Mb 52 DBF общим объёмом 122 Mb
Измеряю время открытия печально известного справочника "Номенклатура" в разных средах (в режиме "Предприятие", конечно). Во всех случаях используются диски с интерфейсом SATA300. RAID во всех случаях интегрированный в мат. плату (Fake-RAID) Intel MatrixRAID, со стандартным размером блока в 64 Kb. Программный RAID во FreeBSD 7.x тормозней любого "аппаратного" Fake-RAID.
Среда — Время открытия
- Ethernet (100 Mbit): FreeNAS 0.7.4919, UFS + SoftUpdate, RAID 0+1 (BDE Crypt); Samba 3.0.37,1 - 15 мин 15 сек
- Ethernet (100 Mbit): FreeBSD 7.0, UFS + SoftUpdate, RAID 0+1 (BDE Crypt); Samba 3.0.37,1 - 15 мин 13 сек
- Ethernet (100 Mbit): FreeBSD 7.0, UFS + SoftUpdate (No Crypt); Samba 3.0.37,1 — 9 мин 12 сек
- Ethernet (100 Mbit): Windows 2003 R2 Server Standard, RAID 1 (No Crypt), NTFS; SMB — 7 мин 13 сек
- Ethernet (100 Mbit): Windows XP Pro SP3, NTFS; SMB — 14–20 сек
- Ethernet (100 Mbit): FreeBSD 7.0, UFS + SoftUpdate, RAID 0+1 (BDE Crypt); NFS — 13–18 сек
- Ethernet (100 Mbit): ALT Linux 4.1 Desktop, Ext3; Samba 3.0.30-alt3 — 14–17 сек
- Ethernet (100 Mbit): Linux Kubuntu 9.04, Ext3; Samba 3.3.2 — 13–16 сек
- USB: Windows 2003 R2 Server Standard, Transcend StoreJet 2.5" SATA, NTFS; USB 2.0 — 8 сек
- RAM: Windows 2003 R2 Server Standard, SuperSpeed RamDisk 8.0.4.0 — 7 сек
- HDD: Windows 2003 R2 Server Standard, локально, с того же диска (NTFS) что и 1С 7.7 — 5-6 сек
- Без расчёта остатков при выводе справочника, в любом варианте — 1 сек
Для варианта "по-ethernet" самым быстрым оказался вариант NFS. Монтирование диска под Windows 2003 R2 Server происходит командой: "mount 192.168.0.X:/mnt/nfs N:" Считается что NFS-диск можно оптимизировать подобрав размер блока через rsize/wsize, проверяем:
Размер блока — Время открытия
- 32 — 14 сек
- 16 — 13 сек
- 8 — 14 сек
- 4 — 13 сек
- 2 — 14 сек
- 1 — 14 сек
Как видим, влияния никакого — просто погрешность измерений. Аналогичные результаты были получены как по всем возможным оптимизациям Samba, так и UFS. Ряд параметров, типа включения async (асинхронного доступа) к диску приводит наоборот к замедлению. Все системы перечисленные выше "заоптимизированы" т. е. настроены максимально возможно оптимально. По-умолчанию, результаты будут хуже.
Выводы: Наиболее приемлимым для работы 1С 7.7 является вариант локальной работы, когда база 1С и сама 1С находятся на одном и том же носителе физически. Вариант работы с RAM-диска можно считать практически аналогичным по производительности. Если имеется необходимость хранения баз отдельно, то наиболее производительной окажется работа с подключенным USB-винчестером. При этом достигается дополнительная безопасность за счёт его съёмности.
При использовании сторонних хранилищ через Ethernet (100 Base-TX) относительно приемлимыми являются файловые системы NTFS для Win и ext3 для Linux, а файловая система UFS2 для BSD категорически неприемлима без использования схемы RAID 0+1, включённого SoftUpdate для партиции с хранилищем и дополнительной оптимизации. Посмотрим, может быть UFS3 сможет составить конкуренцию, но пока предпосылок для этого нет. Для сетевого доступа могут быть использованы SMB, Samba или NFS, при этом родной SMB для Windows проигрывает Samba для Linux со включёнными блокировками.
Во всех случаях желательно полностью или частично (если это возможно) отказаться от расчёта остатков при выводе справочников (в частности, справочника "Номенклатура") путём удаления этого поля из критичных справочников в Конфигураторе (в конце-концов несложно построить отдельный отчёт специально). В этом случае для пользователей наступает "счастье" в виде "летающей" 1С. Существуют и другие здесь не рассмотренные и чисто программные способы оптимизации вывода справочника "Номенклатура". По понятным причинам они менее эффективны т. к. не считать ничего для 1С: всё-таки быстрей чем считать хоть что-то с использованием любого алгоритма.
