Publ: Development Blog

Entries tagged performance

Publ v0.7.31 released

Posted Wednesday, October 2 at 2:13 AM (2 months ago)

There’s a new release of Publ. There’s no new features, but there’s a huge performance improvement.

I’d been having some performance issues where on my larger sites, the main Atom feed was taking a long time to render. It didn’t really bother me too much because thanks to aggressive caching it would only cause an occasional slow page load (on the order of a few seconds) every now and then, but I thought there was probably something wrong with the I/O characteristics of how pages render.

Boy howdy was I wrong about that.

SQLite vs. Postgres, at a glance

Posted Wednesday, May 5 at 11:28 AM (3 years ago)

There’s a general belief that SQLite is a “slow” database and Postgres is “fast,” and many software packages (including FOSS) insist that SQLite is only suitable for testing and doesn’t scale. However, this doesn’t make much sense when you think about it; SQLite is an in-process database so there’s no communications overhead between the service and the database, and because it’s only designed to be accessed from a single process it can make use of optimistic locking to speed up transactions.

Since I was installing postgres for another purpose on my webserver, I decided to quickly see if Publ performs better on Postgres vs SQLite. To test the performance I compared the timing for my website on both doing a full site reindex, and rendering the Atom feed several times (using the debug Flask server and caching disabled).

Publ 0.6.6, Authl 0.4.0

Posted Sunday, May 31 at 3:32 AM (4 years ago)

I’ve just released new versions of Publ and Authl.

Publ v0.6.6 changes:

  • Fixed a regression that made it impossible to log out
  • Fixed a problem where WWW-Authenticate headers weren’t being cached properly
  • Improve the changed-file cache-busting methodology
  • Add object pooling to Entry, Category, and View (for a potentially big memory and performance improvement)

Authl v0.4.0 changes:

  • Finally started to add unit tests
  • Removed some legacy WebFinger code that was no longer relevant or ever touched
  • Added a mechanism to allow providers to go directly to login, as appropriate
  • Added friendly visual icons for providers which support them (a so-called “NASCAR interface”)

Publ v0.5.14 released!

Posted Tuesday, February 4 at 5:40 PM (4 years ago)

Today I released v0.5.14 of Publ, which has a bunch of improvements:

  • Fixed a bug in card retrieval when there’s no summary
  • Admin panel works again
  • Markdown entry headings now get individual permalinks (the presentation of which can be templated)
  • Markdown entry headings can be extracted into an outline to be used for a table of contents
  • Lots of performance improvements around ToC and footnote extraction, and template API functions in general

v0.5.12 released, and lots of documentation fixes

Posted Tuesday, December 31 at 12:02 AM (4 years ago)

Release notes

Today I got a fire lit under me and decided to do a bunch of bug fixing and general performance improvements.

Changes since v0.5.11:

  • Fixed a micro-optimization which was causing some pretty bad cache problems (I really should write a blog entry about this but tl;dr micro-optimizations are usually bugs in disguise)
  • Fixed an issue which was causing the page render cache to not actually activate most of the time (you know there’s going to be a ramble about this below…)
  • Fixed a bunch of spurious log meessages about nested transactions
  • Refactored the way that markup=False works, making it available from all Markdown/HTML contexts
  • Changed no_smartquotes=True to smartquotes=False (no_smartquotes is retained for template compatibility) (although I missed this on entry.title; I’ve already committed a fix for the next version)
  • Improve the way that the page render cache interacts with templates
  • Fixed an issue where changing a template might cause issues to occur until the cache expires

Documentation improvements

Goodbye peewee, hello PonyORM

Posted Wednesday, September 19 at 2:27 AM (6 years ago)

For a number of reasons, I have replaced the backing ORM. Previously I was using peewee, but now I’m using PonyORM. The primary reason for this is purely ideological; I do not want to use software which is maintained by someone with a track record of toxic behavior. peewee’s maintainer responds to issues and feature requests with shouting and dismissive snark; PonyORM’s maintainer responds with helpfulness and grace. I am a strong proponent of the latter.

PonyORM’s API is also significantly more Pythonic, and rather than abusing operator overloads for clever query building purposes, it abuses Python’s AST functionality to parse actual Python expressions into SQL queries. Seriously, look at this explanation of it and tell me that isn’t just amazing.