This was originally in the NE 24th anniversary post but figured it would be better to have it's own post instead due to the constant adding to it I've been doing.

This isn't a serious project, just something I've been throwing together for fun. The basic goal of it is just to write the site as close to the original as possible and in Perl. So far, it's fully functional, just a bit buggy and slower.

Site: https://disc-shamrice.koyeb.app

NEMB: https://disc-shamrice.koyeb.app/Indices/46108.html

Below is my run down of trying to get some performance out of the site. It went from taking >40 seconds to load NEMB to down to 1 second if hitting the cache (5 seconds if not). Still a work in progress.

2023-02-20:

The DiscApp Perl version is VERY slow but it does have some things the main site is missing. The search function works based on words (if pointing to the original search URL) also clicking "return to messages" on a link clicked from the search page returns you to the search page, the 'collapse on index' setting for message boards is actually faster, HTML and urls are almost a 1:1 to the original site, and the 'main site' and login pages are formatted from the original site. The Perl version has basically become a test to become as most of an exact output copy as possible.

You can try the slightly different search here. This will change back to the original way once I roll out this change on the main site as the original search feature works how the main site search works now. (Ticket for main site: Here)

Btw, this post was posted from the Perl site... after waiting almost 40 seconds for the index page to load.... :)

Edit:

The Perl site is running extra slow because I added a ton of debug logs to track down the slow down. For some reason simple queries that take less than half a second directly on the SQL server take up to a second when the site performs them. I'm guessing maybe it really is the lag due to the distance between the DB and the web. (Crossing the Atlantic 100s of times building thread trees...)

2023-02-21 Edit:

After some additional tinkering with caching database results on the server side, I was able to get the index page here to go from ~40 seconds to ~20 seconds after the threads are cached. This is still horrendous. I wonder maybe it's also CPU limiting it? If I load the same copy of this forum on my local computer, the load time for the index is 12 seconds without caching, 6 seconds once cached. Still really bad.

If I run the the local version pointed to my local Postgres database, it's around 700ms after caching. I must be messing something up stupid while building the thread trees... there's no way it could be this much slower. Especially seeing that all other pages are pretty comparable in speed (and the server instance is 1/2 the size as the main site).

2023-02-22 Early AM Edit:

So, after checking if it's the string concatenation (this was a big speed increase in the Java version) or the way I'm dereferencing my thread arrays I'm iterating through. I didn't see any difference at all. Even removing the string concatenation didn't change the speed. I'm guessing it must be the speed of the recursion itself? What's crazy is that on my local backup of NEMB, when I have it set to expand all threads in the history of the board (~20 years of threads), the Java version takes around 10s to render every time. The Perl version takes ~19-20s to render the first time and then only ~3s after that. It's actually FASTER than the Java version locally. I'm honestly not sure if it's something I can fix without seeing if spinning an instance up on Heroku instead of Koyeb fixes the speed issue.

2023-02-23 Edit:

Alright... got it sorted as best as it's going to be. Local test above on local instance of NEMB full history matches Java version at around 9-10s first load. After that, when it hits the cache it only takes around 300ms whereas the Java version always takes around 9s. It's incredibly fast now.. at least locally. The deployed version pointing to the prod database is much slower. NEMB now takes around 5s to load on first hit and then around 900ms-1s when using the cache. Not too bad but not great. I don't think there's any more I can do though.

The new code now grabs the whole sub thread tree in a single recursive DB query and then the HTML is built on that instead of a DB call for each thread. If it's already been called, it pulls from the cache instead. There's no more recursive sub calls in the site code. I used an array to make a crude thread nesting stack instead.

You can see in this log example that most of 1s response time comes from chugging on building the sub thread html. The site is running on I think 1GHz and 256MB of RAM so I can't fault it too much.

[2023-02-23 19:21:33.04312] [9] [info] ACTIVITY QUERY START

[2023-02-23 19:21:33.22773] [9] [info] ACTIVITY QUERY END

[2023-02-23 19:21:33.23474] [9] [info] Found 15 threads by activity.

[2023-02-23 19:21:33.23496] [9] [info] *** STATISTICS: Populate thread trees start

[2023-02-23 19:21:33.60243] [9] [info] *** STATISTICS: Populate thread trees end. Took: 0 seconds.

I have two worker threads running serving the page.. I'm thinking it's possible for the thread cache on each to become out of sync when new threads are posted as replies. Only the worker that submitted the thread can update their local cache. hmm. Will need to think on that....

After adding a few more logs. It's definitely the hosting now that's the bottleneck. Pointing my local website to the prod database loads NEMB in 300ms with 0.15s spent populating the thread trees. The web hosting takes 0.38s to populate the thread trees but 1s to finish rendering. it must be getting caught up somewhere else. Even so, it's 2-3x slower.