# PHPBB to Discourse Migration Speed Optimization **URL:** https://meta.discourse.org/t/phpbb-to-discourse-migration-speed-optimization/403319 **Category:** Migration **Tags:** phpbb **Created:** [May 19, 2026, 1:24pm UTC](https://meta.discourse.org/t/phpbb-to-discourse-migration-speed-optimization/403319 "2026-05-19T13:24:09Z") **Posts on this page:** 1 **Showing post:** 6
### Author: ![Ethsim2](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ethsim2/32/522255_2.png) [@Ethsim2](https://meta.discourse.org/u/Ethsim2) #### Post date: [May 19, 2026, 2:53pm UTC](https://meta.discourse.org/t/phpbb-to-discourse-migration-speed-optimization/403319/6 "2026-05-19T14:53:30Z")
That droplet size looks reasonably strong for this kind of import, so I would not expect `UNICORN_WORKERS` to be the main limiter here. A couple of observations: - Stopping Unicorn is probably fine for an import-only/staging container, but it likely will not massively speed up the importer itself. - Attachments and avatars being disabled should remove two of the slower parts, so if you are still only getting ~440 posts/min, the bottleneck may be database I/O, the source phpBB MySQL query side, or Redis/PostgreSQL waits. - The log line is worth watching carefully: `Exception while creating post 304683. Skipping.` Even though the import continues, that means at least that post was skipped. If this happens repeatedly, the final migration may be missing posts. The Redis part looks like a 1-second Redis client timeout during Discourse’s distributed mutex lock while `PostCreator` is creating a post. I would check whether Redis is actually overloaded or whether the timeout is just too aggressive during a long import. Useful next checks would be: ```bash free -h ``` ```plaintext df -h ``` ```plaintext iostat -xz 1 ``` ```plaintext vmstat 1 ``` ```plaintext redis-cli INFO memory ``` ```plaintext redis-cli INFO stats ``` ```plaintext redis-cli SLOWLOG GET 20 ``` Also, is the phpBB MySQL database local on the same droplet, or being read over the network? Since the stack trace is iterating through mysql2, a slow source database or slow disk can keep CPU usage low while the importer waits. At the current rate, from 333919 / 2167314 at about 441 items/min, you still have roughly 69 hours left, so it may finish, but I would mainly be concerned about whether those Redis timeout exceptions are causing skipped posts. I’d **not** suggest raising `UNICORN_WORKERS`. On an import-only run, Unicorn is mostly irrelevant. The important thing is that his import is continuing but **skipping posts** , which is the part I’d flag. --- _[View the full topic](https://meta.discourse.org/t/phpbb-to-discourse-migration-speed-optimization/403319)._