Тестирование своего проекта
03-06-2024Время чтения ~ 3 мин.Albireo Framework / CMS 711
Как бы разработчик не планировал и как бы тщательно не подходил к кодингу своего проекта, всегда есть нюансы, которые невозможно предусмотреть. Поэтому одним из самых эффективных способов тестирования — это использование приложения в реальных условиях.
Этот сайт — второй, который работает на Albireo CMS. Первый сайт намного меньше по объему, поэтому на нем выявилось совсем немного проблем, скорее мелких недочётов. Этот же сайт, намного больше. Одних комментариев почти 1800 штук. Поэтому система сама по себе работает хорошо, но в плане комментариев стали проявляться проблемные участки.
Комментарии в Albireo CMS я сделал на файлах. В каталоге комментариев, каждая страница имеет свой подкаталог, в котором уже и хранятся файлы комментариев. Формат файла очень простой: несколько полей и текст комментария. Для того, чтобы вывести комментарии к странице, достаточно прочитать все файлы. Операция быстрая и простая.
В какой-то момент выяснилось, что в отличие от систем на базах данных, у Albireo CMS нет такого понятия как id записи. Поскольку все файлы равноправны, то идентификатором является адрес страницы. Сложность в том, что адрес страницы не так просто использовать в качестве имени каталога, поскольку в них есть символ /
, что указывает на разделения каталогов. Можно, конечно использовать автогенерируемый id (uniqueid), но тогда каталоги становятся нечитабельными. Поэтому, чтобы не завязываться на имя подкаталога страницы, я прописываю адрес страницы в поле файла комментария и он больше не зависит от подкаталога. И это отлично работает.
Проблема, как оказалось в большом количестве файлов комментариев. Чтобы было понятно — это всего примерно 2Мб текста, но раскиданных по 1800 файлов. Чтобы вывести не просто комментарии, а какие-то отмеченные, например неодобренные, нужно прочесть все файлы и потом вывести только нужные. И вот эта операция оказалась достаточно медленной.
Очевидное решение — использовать кэш, но если мы работаем в админ-панели, то кэш бесполезен, поскольку нам всегда нужна актуальная версия данных.
Если предположить, что на сайте будет 1000 записей и к ним хотя бы 10 комментариев, то становится очевидно, что такое большое количество файлов так просто не обработать. Поэтому нужен другой способ хранения.
На этапе проектирования комментариев я даже не знал об этой проблеме. Единственным способом её выявить — это использовать реальный сайт и отслеживать такие недочёты.
В итоге я переделал все комментарии на sqlite-базу. Скорость сильно возросла, но пришлось написать отдельную страницу для редактирования комментариев. Остальное — это отдельная библиотека с готовыми функциями, поэтому удобство использования осталось на высоком уровне.
Ещё один пример тестирования на реальном сайте — это просмотр статистики. На реальном сайте накопление данных происходит очень быстро и появляется большое количество страниц пагинации. Таким образом нужно её оптимизировать для удобного просмотра. На локальном сервере, где посещения единичны такое выявить вообще невозможно.
То есть суть в том, что проект может развиваться только когда используется на реальных данных.
Слава Украине! Смерть рашистам!