"Waiting for available sockets" Chrome of ubuntu VPS issue ?

[Rhy]

de situatie: Net / eindelijk klaar (na een maand stoeien) met mijn nieuwe Ubuntu VPS @transip. En nu met meerdere tabs tegelijk bezig met allerlei content bij te werken ... en er valt me (weer) iets op.

de ergenis: Ik zie regelmatig: "Waiting for available sockets" staan in de chrome browser status bar. En logischerwijs wordt er dan letterlijk gewacht met b.v. pagina laden.

oorzaak / oplossing? Is dat nu een daadwerkelijke Chrome limitatie (zoals ik op google vind)? Of kan ik toch iets doen met de apache2 server instellingen m.b.t. mpm_prefork en mpm_worker, dan wel static resources onderbrengen op een subdomein om die limitatie te lijf te gaan?

Echt storend is het niet; real world scenario is het niet bepaald (20+ tabs van 1 site open), maar toch zit het me dwars.

[ Voor 7% gewijzigd door Rhy op 24-01-2016 01:13 ]

[himlims_]

is het naar een flush nog steeds?

code:

Force-open Sockets 
    Go to the address bar and type chrome://net-internals.
    In the drop-down menu, select Sockets.
    Click on the Flush socket pools button.

dan weet je of het clientside of servertje is, ander browsertje geprobeerd?

zie ook; http://stackoverflow.com/...waiting-for-available-soc

oplossing zit m denk ik in het aanbieden, zoals je zelf aangeeft kan een subdomain bepaalde processen versnellen. begrijp dat het vooral werkt bij shit-load aan data (500+)

[ Voor 17% gewijzigd door himlims_ op 24-01-2016 08:11 ]

[CAPSLOCK2000]

Rhy schreef op zondag 24 januari 2016 @ 01:11:
oorzaak / oplossing? Is dat nu een daadwerkelijke Chrome limitatie (zoals ik op google vind)? Of kan ik toch iets doen met de apache2 server instellingen m.b.t. mpm_prefork en mpm_worker, dan wel static resources onderbrengen op een subdomein om die limitatie te lijf te gaan?

Op grond van deze informatie kunnen we dat onmogelijk beoordelen.
Heb je al vastgesteld of het probleem op de client of op de server zit?
Is er op de servers iets geks te zien?
Hoeveel processen lopen er?
Worden andere http-verzoekjes wel nog afgehandeld?
Verschijnt er iets in de logs?
Kun je het probleem reproduceren?

[Nactive]

Ik heb dit alleen nog maar voor gehad als je gebruik maakt van long polling of andere technieken die expliciet een connectie met een server openhouden.

Wat je kan proberen is in chrome je netwerk tab bekijken. Als er iets blijft open staan moet je dat normaal daar ook zien.

Wat voor software draai je trouwens ? Zelfgeschreven of een geïnstalleerde website ?

[Rhy]

Omdat Firefox er b.v. geen last van heeft, leek het me niet zo zinvol de diverse server logs te posten, maar apache2/error.log is schoon. atop / iotop / htop / vmstat lieten niets bijzonders zien. Maar had het probleem vroeg in de ochtend ook al bij slechts 3 tabs in chrome.

Ik draai een alles-in-1 custom wordPress website waar ik grootste plannen mee heb, als het ooit gaat werken zoals ik voor ogen heb Met 80+ plugins, complexe menu structuren (max_post_vars moest ophogen), backend/frontend, meervoudig affiliate platform voor o.a. woocommerce i.c.m. s2member. Afgelopen maand eigenlijk alleen bezig geweest mijn server kennis bij te spijkeren m.b.t. hardening, cloudflare, firewall. Dus zat ook nog aan iets met IPv6 ofzo te denken aangezien ik dat blokkeer (ookal weet ik eigenlijk niet eens waarom).

Dank in ieder geval voor de suggesties; na alles stap voor stap (opnieuw) nalopen. Was het volgens mij een nogal domme fout; had eergister Tor met ProxyDomains geinstalleerd. Omdat er naast de webserver ook een desktop environment draait met 'iets'. Dat maar verplaatst naar mijn lokale bak.

En ik heb nu in ieder geval de subdomain truuk uitgehaald voor images a.d.v. http://www.oxhow.com/host...g-subdomain-better-speed/ ... met als gevolg dat mijn pingdom score nu naar de maan is (vervijfvoudigd): maar e.e.a. toch snappier lijkt te werken. En een oplossing daarvoor er niet echt is: https://wordpress.org/sup...nal-images-from-subdomain maar ach leuke opstap naar MAXCDN ofzo. Of misschien toch maar wp-fastest-cache weer eens proberen i.p.v. W3TC. @himlims_ hmm dank voor je link suggestie; misschien dat inderdaad met script.yourdomain.com e.e.a. weer sneller werkt.

Afijn ... aldoende leert men; problem solved. Op naar de volgende uitdaging mod_security werkend krijgen.

update2: Hmm lees net dat 't waarschijnlijk wel kan met W3TC met een gedetailleerde handleiding: http://www.htpcbeginner.c...ed-cdn-speedup-wordpress/ ... woei nogmaals dank himlims_ voor zetje in de goede richting. update3: yup! update #2 implementatie werkt als een speer!

[ Voor 12% gewijzigd door Rhy op 25-01-2016 01:37 . Reden: himlims_ ]