@nielssteenkrogh Another cause for zeo clients taking a long time to start up is a very large/fragmented portal_catalog. It is stored in btrees and these can become unbalanced over time when new content is added.
Hanno Schlichting & Helge Tesdal wrote a script which rebalances the btrees in all the portal_catalog indexes. There's a bit of heuristics in there and an empirical balancing parameter. Use at your own risk, but we have tested in on some sites and afterwards also on production, where the startup time of zeoclient (up to delivering their first response). went down considerably (>50%) after running it.
The script seems safe to run on online zodb's, it uses subtransactions to commit the changes to the zodb. I did see some conflicterrors when running it on a live site, I don't know if it then skips the whole index of if it retries later.
What I don't understand is what this rebalancing script brings compared to a full 'Clear and rebuild' of the whole portal_catalog. It seems to look at the current state of an index before it rebalances it, a "Clear and rebuild" will drop the indexes and fill them up again while walking over all content in the site. Which might be just as inbalanced as the organic growth of content.
If anybody more knowledgable about the portal_catalog can shed a light on this....
Allthough it speeds up startup time, it doesn't really match your symptom of only have slow startups of zeoclients after being offline for more than 24 hours, that points more towards the zeo-client-cache. Allthough a huge portal_catalog might also get synced to the zeo-client cache, so decreasing this data structure could be beneficial to that as well.