Тема: Підвищення швидкодії CMS шляхом розділення даних між DB і DF
Підвищення швидкодії CMS шляхом розділення даних між DB і DF
В процесі професійної діяльності через мої руки пройшло більше 1000 безкоштовних CMS різного виконання і призначення. На перший погляд багато хто з них має порівняно високу швидкодію і функціональність. Але кожна моя спроба використати їх для професійного видання об'ємних документів тут же виявляла дуже істотні недоліки. Практично усі тестовані CMS мали два істотні недоліки, пов'язані з процесом редагування і зберігання публікованих матеріалів:
1) редагуванню піддається не одна сторінка, а відразу увесь документ, тому правка багатосторінкового документу перетворюється на справжній кошмар;
2) поступове заповнення документами сайту реально знижує швидкодію CMS, а наявність на сайті десятків тисяч документів взагалі робить її застосування неефективним.
Іншими словами, замість "надійного інструменту" для повсякденної роботи публіцист отримує "безкоштовну іграшку", яка ламається при першій же спробі серйозно пограти з нею.
Який реальний доход може принести CMS класу "безкоштовна іграшка"? Чесно кажучи, мені щиро шкода розробників подібних CMS, що згаяли свій творчий час на втілення сумнівної ідеї.
Чи можна обійти ці недоліки? Так, можна!
Відповідь заснована на особистому досвіді створення інформаційних систем Інтранет з великим об'ємом даних:
правильно розділити усю корисну інформацію між базою даних (DB) і файлами даних (DF)!
Усім відомо, що системи управління папками і файлами (FFMS) з'явилися значно раніше за системи управління базами даних (DBMS), тому FFMS є розвиненішими відносно DBMS. Проте не усі дані є зручними для зберігання в DF. Про це можна запитати у розробників програм на COBOL і FORTRAN, які успішно використовуються досі.
Тому я провів наступний експеримент.
На комп'ютері з OS MS Windows XP (MSWNT) було встановлено DBMS MS Visual Foxpro (MSVFP). Засобами оболонки MSVFP в DB було створено типову таблицю docs для зберігання документів з полями:
- code (код з "Державного рубрикатора науково-технічної інформації");
- author (прізвище, ім'я і по батькові автора);
- name (назва документу);
- identifier (внутрішній ідентифікатор);
- city (місто видання);
- country (країна видання);
- pubhouse (назва видавництва);
- year (рік видання);
- pages (кількість сторінок);
- illustrations (кількість ілюстрацій);
- isbn (код ISBN);
- annotation (анотація до документу);
- text (текст документу).
Усі поля, окрім "text", були оголошені ключами індексування.
Засобами оболонки MSVFP я зробив 2 програми:
1) електронна бібліотека;
2) емулятор дій оператора.
У складі програми електронної бібліотеки були 2 процедури запису тексту:
1) цілком в полі text;
2) посторінковий у форматі
docs\{code}\{identifier}\{номер сторінки}.txt
Критерій припинення виклику кожної процедури - 10000 записів в таблиці DB.
Емулятор оператора щохвилини заносив в логфайл кількість записів в таблиці і час виконання процедури.
Спочатку емулятор відпрацював з першою процедурою, а потім з другою процедурою.
Отримані дані перевершили усі очікування.
У першу хвилину час виконання першої процедури був приблизно в 1,4 разу менше часу виконання другої. Проте в останню хвилину час виконання першої процедури був приблизно в 17 разів більше часу виконання другої. Крім того, безумовна перевага зберігання окремої сторінки тексту в окремому файлі відчувається при виведенні документу на дисплей.
Мови програмування MSVFP (з урахуванням SOAP) і PHP (з урахуванням OOP) мають багато спільного, що дозволило мені легко перейти на PHP для виправлення помилок і коригування кодів в CMS.
Звідси можна зробити сміливий висновок:
безкоштовна CMS з алгоритмом розділення даних між DB і DF зможе зайняти гідну нішу у сфері систем управління контентом сайтів і приносити регулярні дивиденты розробникові з платних хостингів.
Чесно. Ті хто з цим має проблеми - кажуть допомагає.