Разработка сайта на платформе Django-nonrel

в 20:55, , рубрики: appengine, django, egaxegax, google app engine, python, Веб-разработка

В этой статье я хочу рассказать о разработке своего проекта — сайта egaxegax.appspot.com.

Поскольку являюсь большим поклонником языка Python, свой сайт я решил создать на популярном фреймворке Django. Чтобы использовать его на бесплатном хостинге appspot.com, адаптировал код для использования NoSQL версии django и платформы Google AppEngine.
Разработка сайта на платформе Django-nonrel - 1

Сайт существует уже больше 3 лет с 12-го года. Я использую его как платформу для изучения возможностей django и appengine «вживую». Также интересно изучать статистику по нему в Google Webmasters: поисковые индексы, запросы. Например, для себя я выяснил, что Google индексирует для поиска заголовки title, а не содержимое тегов meta.

Началось все с блога — небольших заметок на программные темы: скрипты, конфиги, примеры использования. Но статьи быстро закончились. А создавать новые в большом объеме не получается. Нужно было что-то большее.

Как-то где-то в Сети я скачал архив файлов с текстами и аккордами песен. Добавил к ним пару десятков своих подборов и решил выложить все на сайт. Всего получилось около 11500 файлов. Вручную столько не загрузить. Для этого я написал скрипт ptext.bat, который преобразует текстовые файлы в дампы для загрузки данных таблиц в GAE DataStore.

Загрузку данных пришлось разделить на несколько этапов из-за ограничений на количество операций записи в сутки в DataStore. В сутки получалось записывать около 700-800 записей (файлов).

После загрузки данных через некоторое время при открытии страницы сайта все чаще стала возникать ошибка 503 Server Error: Over Quota. Поизучав логи на сервере, я выяснил, что главными пользователями моего сайта были googlebot и yandexbot, которые обращаются к страницам с интервалом в 2-3 минуты. Ошибка возникает из-за превышения ограничения количества операций в сутки на чтение из DataStore.

Посмотрев документацию и примеры по appengine, я понял, что совсем не использовал модуль cache (а именно memcache). Каждое открытие страницы вызывало обращение к базе данных через QuerySet. В новой схеме результаты выборок из рекордсетов QuerySet я передаю в списки Dictionary, которые сохраняются в кэш и считываются оттуда при повторном обращении. Это решило проблему с быстрым исчерпанием лимита на чтение.

Позже я добавил раздел Фото и Новости. Разделы оформлены как отдельные приложения (apps). Данные хранятся в таблицах DataStore. Раздел Фото также использует хранилище файлов BlobStore. Все приложения используют кэш при выборке данных.

Сейчас по аналогии с разделом Аккорды я заполняю раздел Книги, куда выкладываю тексты электронных книг. Тексты книг я получаю, распаковывая файлы *.epub с помощью скрипта bconv.py из каталога media/scripts. В отличие от текстов песен они намного больше в объеме и не могут быть целиком отображены на странице. Кроме того, возникла проблема с тем, что книга целиком не может быть добавлена в кэш из-за превышения лимита памяти кэша. Для этого я считываю, помещаю в кэш и отображаю их по главам. Правда до конца проблема не решена. Поскольку сейчас в кэш помещается вся книга по главам целиком, при чтении нескольких книг подряд возникает ошибка превышения лимита на чтение. Выход — в чтении и кэшировании только текущей главы, а не всей книги целиком. Но это пока в проекте.

Кому интересно заходите на страницу проекта в репозитории GitHub django-egaxegax.

Автор: egaxegax

Источник

Поделиться новостью

* - обязательные к заполнению поля