Vergelijk ownCloud Infinite Scale en Nextcloud 28 zonder giswerk.

Een bestandsserver kan traag aanvoelen, zelfs als de CPU-grafieken er rustig uitzien: het laden van directorylijsten duurt seconden, uploads haperen tijdens piekbelastingen of het proces lijkt elke dag meer RAM te verbruiken. Een vergelijking tussen ownCloud Infinite Scale (oCIS) en Nextcloud 28 op basis van één enkele waarde voor "RAM per gebruiker" zal dit probleem niet aan het licht brengen. Er bestaat geen officiële benchmark die een universele winnaar aanwijst, en beide projecten documenteren de geheugenbehoefte als afhankelijk van de werklast en configuratie. Voor een zinvolle vergelijking is het raadzaam om elk platform te meten met dezelfde bestanden, clients, opslag, gelijktijdigheid en testperiode; controleer eerst of de bottleneck zich bevindt in de applicatie, de database, de opslag of de achtergrondprocessen.

Er is ook een onderhoudsbeperking: Nextcloud 28 heeft volgens het gepubliceerde schema van het project in december 2024 het einde van zijn levenscyclus bereikt. Het ontvangt geen routinematige updates meer via het community-releasekanaal. Als Nextcloud 28 al in gebruik is, is het raadzaam om eerst te upgraden voordat u prestatieoptimalisatie als de volledige oplossing beschouwt. De onderstaande stappen helpen bij het vergelijken van gedrag en het lokaliseren van resourceproblemen; ze maken een niet-ondersteunde versie echter niet veilig om te gebruiken.

Waarom verschillen de metingen van RAM-geheugen en snelheid?

Infinite Scale en Nextcloud gebruiken verschillende serverarchitecturen. oCIS is georganiseerd als services in een op Go gebaseerd platform; de ingebouwde supervisor start zijn services als één serverproces. De geheugenbehoefte kan bestaan ​​uit gecachede gebruikers- en opslagmetadata, en de ownCloud-documentatie koppelt specifiek het aantal geheugenruimtes en metadata aan het beschikbare RAM-geheugen en de toegangs- of synchronisatieprestaties. Een server die na een grote initiële scan een grotere werkset laat zien, is op zich geen bewijs van een lek. Controleer of het geheugen stabiliseert na het indexeren en of de latentie acceptabel blijft.

Nextcloud 28 is een PHP-applicatie. De totale geheugenvoetafdruk is afhankelijk van het aantal PHP-FPM-workers en het gedrag per worker, ingeschakelde apps, de webserver, de database, caches, het genereren van previews en achtergrondtaken. De officiële beheerdershandleiding vermeldt dat de geheugenvereisten aanzienlijk variëren afhankelijk van het aantal gebruikers, apps, bestanden en serveractiviteit. Het toevoegen van workers kan de verwerking van parallelle verzoeken verbeteren, maar kan tegelijkertijd het piekgeheugengebruik verhogen. Vergelijk daarom het totale geheugen van de host of container, en niet alleen het geheugen van één PHP-proces ten opzichte van één oCIS-proces.

Opslag kan op beide platforms een doorslaggevende factor zijn. Een trage schijf, netwerkbestandssysteem, objectopslag, database of antivirusscan kan ervoor zorgen dat verzoeken applicatiegebonden lijken. Evenzo leveren een koude cache en een warme cache geen vergelijkbare responstijden op. De relevante vraag is niet welk product het laagste idle-getal heeft, maar welke stack uw daadwerkelijke workload binnen het RAM- en latencybudget kan voltooien.

Vergelijk ze onder dezelfde omstandigheden.

1. Leg de exacte builds en implementatie vast. Noteer de oCIS-versie, het Nextcloud 28-patchniveau, het besturingssysteem, de containerlimieten, de CPU-toewijzing, de database, de opslagbackend, de ingeschakelde apps en services, de PHP-versie en de webserver. Behoud waar mogelijk dezelfde hardware en datapaden. Combineer geen containergeheugenlimiet voor het ene platform met het volledige hostgebruik voor het andere.
2. Gebruik een representatieve testset. Neem de bewerkingen op die in de productieomgeving traag aanvoelen: initiële synchronisatie, incrementele synchronisatie, bladeren door een grote map, downloaden en uploaden van bestanden, delen en gelijktijdige aanmeldingen. Houd het aantal bestanden, de verdeling van de bestandsgroottes, het aantal actieve clients en de gelijktijdigheid consistent. Gebruik een testomgeving en voorkom dat de productiedata overbelast raken.
3. Meet een basislijn en herhaal dit vervolgens. Registreer het inactieve geheugen na het opstarten, het geheugen tijdens elke workload, het piekgeheugen, de CPU, schijf-I/O, databaseactiviteit en de aanvraag- of synchronisatielatentie. Voer de test eenmaal uit na een schone start en nogmaals met opgewarmde caches. Herhaal elke meting voldoende om te controleren of het resultaat stabiel is; beschouw een enkele meting niet als een benchmark.
4. Scheid het applicatiegeheugen van het hostgeheugen. Controleer voor containers de werkset en limiet van het containergeheugen; gebruik voor Linux-processen een procesmonitor en systeemgeheugenstatistieken. Houd ook de swap, out-of-memory-gebeurtenissen en het databasegeheugen in de gaten. Een groeiende hostcache is niet hetzelfde als een geheugenlek in de applicatie, en containerlimieten kunnen het geheugengebruik in verschillende runtimeomgevingen anders weergeven.

Raadpleeg voor oCIS-monitoring de bijbehorende documentatie voor servicestatistieken en Prometheus-eindpunten. De documentatie van ownCloud 8.2 beschrijft statistieken voor ondersteunde services; deze statistieken variëren per service en release. Het beheerdersoverzicht en de systeemtools van Nextcloud kunnen waarschuwingen voor de installatie aan het licht brengen, terwijl monitoring van het besturingssysteem en de database nodig is om het totale RAM-gebruik te verklaren. Houd de testinstrumentatie waar mogelijk identiek en noteer de eenheden en bemonsteringsintervallen.

Wat moet je als eerste afstellen?

1. Bevestig dat er daadwerkelijk sprake is van geheugendruk.

Zoek naar aanhoudend hoog geheugengebruik in combinatie met swapping, OOM-kills, herstarts van containers of een stijgende latentie van aanvragen. Hoog RAM-gebruik alleen kan duiden op nuttige caching. Als het gebruik tijdens een scan stijgt en vervolgens stabiliseert, is het verhogen van het geheugen mogelijk niet nodig. Als het gebruik stijgt zonder te stabiliseren onder een constante belasting, controleer dan de logboeken, het geheugen op serviceniveau en de taak die actief was voordat de limieten werden gewijzigd.

2. Verminder onnodig achtergrondwerk

Identificeer taken zoals het genereren van previews, antivirusscans, indexering, synchronisatiepieken en gepland onderhoud. Deze taken kunnen concurreren met interactieve verzoeken. Verplaats zware taken naar een rustiger periode of verminder de gelijktijdigheid ervan met behulp van de gedocumenteerde beheermogelijkheden voor de geïnstalleerde versies. Schakel beveiligingsscans of vereist onderhoud niet uit om een ​​grafiek kleiner te laten lijken; kwantificeer eerst de kosten en de impact van de taak op de gebruiker.

3. Optimaliseer de PHP- en cacheconfiguratie van Nextcloud.

Controleer voor Nextcloud de ondersteunde PHP-configuratie voor versie 28 en stem het aantal PHP-FPM-workers af op het beschikbare RAM-geheugen. Te weinig workers kunnen verzoeken in de wachtrij plaatsen; te veel workers kunnen het geheugen uitputten. Configureer een ondersteunde geheugencache en Redis voor transactionele bestandsvergrendeling waar nodig, volgens de handleiding van versie 28. Caches verbruiken geheugen, maar kunnen herhaalde bewerkingen verbeteren, dus vergelijk latentie en geheugenverbruik met elkaar. Vermijd het kopiëren van instellingen van huidige Nextcloud-releases naar versie 28 zonder de versiespecifieke documentatie te raadplegen.

4. Bekijk de metadata en opslagopties van oCIS

Voor Infinite Scale is het belangrijk om het aantal geheugenlocaties, de metadata van bestanden en mappen, de opslagdriver en het cachegedrag te beoordelen. De officiële documentatie met vereisten legt uit dat metadata die in het geheugen wordt bewaard, de toegangs- en synchronisatieprestaties beïnvloedt. Als grootschalige weergave- of synchronisatieworkloads samenvallen met geheugenproblemen, vergelijk dan de relevante service- en opslagstatistieken voordat u RAM toevoegt. Controleer de opslagspecifieke opties aan de hand van de exacte oCIS-release; ga er niet vanuit dat de ene opslagbackend hetzelfde geheugengedrag vertoont als de andere.

5. Verhoog de capaciteit pas nadat de beperking is vastgesteld.

Als de gemeten werkbelasting een stabiele, acceptabele latentie heeft maar de geheugenlimiet bereikt, voeg dan RAM toe of pas de toewijzing van resources aan en herhaal dezelfde test. Als de latentie slecht is terwijl het geheugen voldoende blijft, onderzoek dan de databasequery's, opslaglatentie, netwerkdoorvoer, vergrendelingen en CPU-verzadiging. Het schalen van oCIS-services of het toevoegen van workers kan de doorvoer verbeteren in een goed ontworpen implementatie, maar dit verandert ook de resourcebehoefte en de operationele complexiteit. Wijzig één variabele tegelijk, zodat het resultaat toewijsbaar is.

Hoe het resultaat te controleren

Herhaal de oorspronkelijke workload na elke wijziging en vergelijk dezelfde meetwaarden: piek- en stabiele RAM-gebruik, swapactiviteit, p95-aanvraag- of synchronisatielatentie (indien beschikbaar), voltooide overdrachten en het aantal fouten of herstarts. Een succesvolle oplossing zou de door gebruikers gerapporteerde prestaties moeten verbeteren zonder elders geheugenproblemen te veroorzaken. Voor een eerlijke platformvergelijking publiceert u de testomstandigheden naast de resultaten en vermeldt u of de caches koud of warm waren; generaliseer niet op basis van één kleine server of dataset.

Beschouw de status van Nextcloud 28 als een aparte operationele kwestie. Gebruik de upgrade-instructies van het project om over te stappen naar een ondersteunde release en voer de vergelijking vervolgens opnieuw uit, omdat nieuwere code, PHP-versies, apps en migratiewijzigingen de footprint kunnen beïnvloeden. Raadpleeg voor de huidige implementatievereisten en releasespecifieke instellingen de vereisten voor ownCloud Infinite Scale 8.2 , ownCloud-statistieken voor Prometheus , de systeemvereisten voor Nextcloud 28 , de geheugencaching van Nextcloud 28 en het onderhouds- en releaseschema van Nextcloud .