Onlangs deed ik een online paper grouping-project. De belangrijkste functies zijn het zetten van woorden, het bekijken en het genereren van toetsartikelen. Als het gaat om woordbewerkingen aan het begin, is één ding dat in me opkomt de Office COM-component om Word te bedienen. Het duurde ongeveer twee weken om de code voor het hele systeem te schrijven. Toen begon ik herhaaldelijk te testen, voelde ik me lokaal goed, en ik kon soepel een woordtestpaper maken, en de prestaties waren redelijk. Dus ik kon niet wachten om het op de server uit te brengen.
De eerste is dat een component met CLSID {000209FF-0000-0000-C000-000000046} in de COM-fabriek faalt door de volgende fout: 8000401a Het systeem kan het serverproces niet starten omdat de configuratie-ID onjuist is. Controleer alsjeblieft de gebruikersnaam en het wachtwoord. (Uitzondering op HRESULT:0x8000401A).
Allereerst worden al deze problemen veroorzaakt door permissies, en de oplossing is gewoon het configureren van permissies. Niet alleen nuttig voor Excel en Word, maar ook voor alle Office-producten.
Om ter zake te komen: voer eerst dcomcnfg in tijdens de run, open de component service manager->component service->mijn computer->DCOM-> zoek het bijbehorende Microsoft Excel-applicotion/Microsoft Word 97-2003 document, en klik dan met de rechtermuisknop op het attribuut om de opstarttoestemming te activeren is voldoende om het naar OK te geven. -------- geen probleem, dit probleem is opgelost.
Laten we het hebben over de tweede situatie, "Prestatieprobleem": aangezien ons systeem het volgende subsysteem van onze website is. Er is dus een bepaalde gebruikersbasis. Het systeem werd direct na de live-ingang door een groot aantal gebruikers benaderd. In het begin werden er vier tot vijfhonderd artikelen per dag gegroepeerd, en langzaam werd het volume steeds groter en groter, wat het begin was van problemen met het systeem. De eerste is dat er veel winWord.exe processen in het proces zitten. Het kan niet eindigen. Hoewel de systeemcode het Quit-proces bevat en bronnen recyclet, wordt het probleem nooit opgelost. Het gevolg van een groot aantal winword.exe processen is dat de server vertraagt. Het zou voor deze component bijzonder geheugenintensief moeten zijn.
Er is geen manier om het probleem op te lossen. De laatste rogue was het schrijven van een timingservice die het winword-proces dat niet draaide stopte. Dit behandelt de symptomen, maar niet de onderliggende oorzaak. 、
Hier wil ik zeggen dat Microsoft Office een desktop-kantoorapplicatiesoftware is, voornamelijk ontwikkeld voor gewone gebruikers, het heeft rijke UI-elementen (gebruikersinterface) en bestaat uit een set van puur lokaal draaiende software of clientsoftware. De Word-automatiseringsinterface is voornamelijk ontworpen om window-applicatieaanroepen te vergemakkelijken. Bijvoorbeeld native applicaties ontwikkeld door Delphi, VB, C# Winform, enzovoort. Hoewel het mogelijk is om Visible te forceren om onwaar te zijn en Word in server-side code kan draaien, brengt het nog steeds veel lastige problemen met zich mee.
1. ASP.NET is gebaseerd op B/S-architectuur. In de B/S-architectuur is gebruikerstoegang gelijktijdig, wat betekent dat N gebruikers vaak tegelijkertijd verzoeken doen aan een serverpagina. In dit geval valt de Word-automatiseringsaanroep vaak af en toe uit.
2. Door de verborgen interfacewerking zullen sommige interfaces die interfaces bevatten die succesvol in het vensterprogramma kunnen worden aangeroepen, niet aanroepen aan de serverzijde of zelfs crashen, wat vaak leidt tot dode processen.
3. Omdat Word een complex desktopprogramma is en niet voldoet aan de standaarden van algemene webserviceprogramma's op het gebied van eenvoud en efficiëntie, draait het traag aan de serverzijde en verbruikt het veel middelen (CPU, geheugen), vooral omdat het niet een groot aantal gebruikers tegelijk kan ondersteunen, en de middelen snel uitgeput raken.
4. De meeste ontwikkelaars zijn relatief onbekend met COM-technologie, en er zijn vaak codefouten bij het programmeren en aanroepen van de Word-interface, waardoor het probleem moeilijk is te controleren, wat een veelvoorkomende factor is die dode processen veroorzaakt. Word-dead processen verbruiken niet alleen serverbronnen, maar zorgen er vaak voor dat serverpagina's geen nieuwe Word-automatiseringsobjecten kunnen aanmaken en blijven werken. Sommige netizens stelden een oplossing voor voor een dood proces: programmeren om het dode proces van Word te doden, wat een praktijk is om de symptomen te behandelen maar niet de oorzaak; het dode proces van Word is verdwenen, maar de abnormale sluiting van Word zal ervoor zorgen dat veel middelen niet op tijd kunnen worden vrijgegeven. Hoe lang zo'n webserver zal meegaan is moeilijk te zeggen.
Om deze problemen op te lossen, ontdekte de auteur na grondig onderzoek en vergelijking dat er een componentcomponent aspose.words op het internet is, die bovenstaande problemen volledig elimineert en aanbevolen wordt om met je te delen.
Hieronder deel ik wat van de operationele code van het aspose.words-onderdeel met je, in de hoop dat het nuttig zal zijn voor degenen die het nodig hebben
Originele link: http://blog.csdn.net/fraing/article/details/8989736
|
Geplaatst op 08-04-2016 16:44:24
|
|
|
Geplaatst op 03-05-2020 09:07:08