BelangrikDit is die gebruik van koekies (cookies). Die gebruik van hierdie webtuiste sonder om te draai af koekies in die leser, beteken dat jy saam vir die gebruik daarvan.
Bestel nou! Kenmerke Downloads

Verdien met ons!

As jy wil om te begin om geld te verdien met vBET Sluit by Affiliate program.
Page 1 van 2 12 LaasteLast
Resultate 1 aan 10 van 15

Thread: Meer belasting probleme

  1. #1
    Senior Member
    Join Date
    Feb 2010
    Posts
    210

    Default Meer belasting probleme

    Ok so ek het baie van die toets gedoen.

    Oor 'n tydperk van 24 uur is my vrag styg steeds in die 30,00 se

    'N herlaai fixes dit vir' n ander 24 uur.

    As ek die mod afskakel Ek kry nie hierdie probleem.

    Moet nie sê dat met mod gestremdes daar is minder verkeer, want dit is nie waar nie, stuur Google nog steeds dieselfde verkeer met mod ongeskik volgens my stats.

    Verduidelik asseblief, las is ry my mal.

  2. #2
    Senior Member
    Join Date
    Dec 2009
    Posts
    276

    Default

    Klink soos bots is slaan die vertaalde bladsye wanneer die mod is. Jy moet kyk na die optimalisering van Apache of om 'n bediener met meer CPU krag. Is jy vboptimise of enige ander soort van cache meganisme, soos memcached?

  3. #3
    Senior Member
    Join Date
    Feb 2010
    Posts
    210

    Default

    Die feit is dat my forum 30,000 unieke per dag kry, as ek die mod-las onmiddellik deaktiveer, en bots en gebruikers wys steeds bladsye, so eis steeds bedienerkrag, dit is eenvoudig dat die vertoon van vertaalde bladsye 10x die hulpbronne gebruik as standaard vb bladsye van die normale databasis. Dit is swak geskrewe kode, en moet reggestel word! Die ander mods het dit nooit gedoen nie, net vbet, wens ek het nooit verander nie, maar om terug te gaan is nou te laat.

  4. #4
    Senior Member
    Join Date
    Nov 2009
    Posts
    168

    Default

    Dit klink regtig asof jy op 'n onvoldoende versterk bediener. Ek is op 'n 8-core nehalem masjien (so ons kyk na 8 virtuele cores as gevolg van die HT, vir' n totaal van 16). Ek het ook uitgebrei geoptimaliseer hierdie masjien deur gebruik te maak van my eie tegnieke asook wysers van die mense by vbulletin.com.

    vBET roep my vrag van ongeveer 2,5 tot 3,0-3,5, afhangende van die aantal gebruikers, en hierdie is natuurlik groei wat gebaseer is op die kas grootte. Maar ek dink nie dis te sleg nie, as my gelyktydige gebruikers wissel van 'n redelik hoë 800 tot' n selfs hoër 1200.

  5. #5
    Michał Podbielski (vBET Personeel) vBET's Avatar
    Join Date
    Oct 2009
    Posts
    3,037

    Default

    Hi Natuurlik vertaling moet n paar hulpbronne - daar is geen magie. Vertaal bladsy beteken dat die uitset tot gevolg hê en dit verander. As gevolg van die vertaling sal altyd langer neem as die normale bladsy.

    Ek verstaan dat jy nie so gelukkig om meer server load, maar asseblief daarop let dat vBET hulpbronne is SLEGS VIR VERTALING neem. Vir normale bladsye voeg net vlae. So kom al hierdie bykomende belasting van bykomende verkeer te vertaal bladsye. As jy geskryf het jou verkeer het nie gaan af onmiddellik na die aanskakel van vBET (as jy het dit 'n rukkie, dan is dit sal afneem te skakel - glo my) en server load laer is - dit is duidelik - robots is steeds soek van URL's te vertaal bladsye, gebruikers is nog steeds bevinding in Google skakels na jou vertaalde bladsye. So jy het nog steeds dieselfde verkeer, maar nou onder vertaal skakels is eenvoudig gedupliseer inhoud - die normale bladsy wat nie vertaal. As jy wil bly met gestremde vBET ons sterk aanbeveel reël by te voeg in jou htaccess lêer wat redirect alle vertaalde bladsye normale een, anders kan jy los jou SEO as gevolg van gedupliseer inhoud.

    Let asseblief daarop dat ons reeds beplan het om ander kasstelsels te ondersteun en ons vertaalalgoritmes is onmiddellik geoptimaliseer. Dit wil sê ons het net ontdek hoe drasties verminder PHP prestasie wanneer ons aan groot snare werk en ons het ons algoritme verander. Dit is reeds vrygestel in vBET 4.2.0 met bykomende konfigurasie opsies. En ons sal alle verbeterings ook na vBET 3.x skuif wat steeds ondersteun word

    Ek verstaan dat in jou mening is ons kode is swak is. Ek weet nie wat jy baseer jou verwagtinge. Ons het die vinnigste vertaling mod vir vB - daar is niks wat werk beter nie. Vertaling sal 'n paar hulpbronne, en ons mod neem dit minder as enige ander. Jy kan sien hoe vinnig vBET kan werk op baie forums. As jy op jou bediener, dan oorweeg dit asseblief configuration of bediener hulpbronne toe te voeg. Jy sal nie 20 liter water in 10 liter emmer.

    Ons bedink is: "Ons het baie om te verander". En daarom eksperimenteer ons, verander algoritmes, profilering en spandeer baie tyd op soek na oplossings wat minder hulpbronne benodig. Tog weet ons geen mod wat enige kompetisie vir vBET kan wees nie en daar is 'n paar ander vertaalmods. Ons het baie algoritmeveranderinge gemaak wat ons moes wegsteek omdat hulle nie gehelp het nie, tydens hierdie proses het ons ook baie verbeterings ontdek. U kan u indruk op u bedienerkwessies plaas, maar oorweeg dit asseblief dat u 'n beter oplossing het? Wat kan jy 'n wenk gee dat miskien vBET nie verkeerde oplossing is nie, aangesien jy aan duisende forums werk, miskien probeer jy net 20 liter water in 10 liter emmer sit. Tog - ons het baie om te verander en 'n groot TODO lys in optimalisering afdeling (ongeveer 70% om te eksperimenteer sal dit help of nie) En jy is 100% reg - ons kan dit beter te doen, sal ons en ons doen dit al die tyd Wag net totdat ons beweeg van alle verbeterings wat ons gemaak is tydens vBET4.x implementering

    As ek kan gee jou 'n paar wenke - check hoe jy kan optimaliseer vBET: http://www.vbenterprisetranslator.co...rformance.html
    Veral oorweeg aanskakel van sommige tale en blokkeer irrelevant bladsye deur robots.txt

    Wat is die tyd van die reaksie vir vertaalde bladsye? Wat is jou CPU gebruik? Wat is jou geheue gebruik? As dit aanvaarbaar is, dan het jy niks om oor bekommerd te wees nie. Mense is dikwels bang deur die bediener belasting te verhoog en nie eens weet wat dit beteken. 10 keer meer server load nie NIE beteken 10 keer meer hulpbronne gebruik. Dit beteken net meer drade wag in die tou, wat is heeltemal normaal, aangesien nou jou drade het om te wag vir Google reaksie as sommige vertaling is nie Cached nog. So draad wag vir Google reaksie en dit neem geen CPU TE ALLE gedurende hierdie tyd. As gevolg van dat jou bediener belasting sal groter selfs as vBET kon geen hulpbronne nie (wat natuurlik nie moontlik is nie).

    Oor die gekraak van jou bediener - dit is natuurlik jou bediener probleem. Dit gebeur van tyd tot tyd. Ek het 'n soortgelyke probleem op my server. Dit was veroorsaak deur sommige Apache-bug so een Apache draad groei en groei met die geheue gebruik totdat die hele geheue is ans bediener Cached. Slegs een draad optree soos dit - ander Apache drade was normaal. Ek het gespeel met Apache konfigurasie en probleem opgelos is. Ek dink dat Apache net 'n paar geheue lekkasie - soos ek dit onthou Ek sit laer waarde van die versoeke wat kan hou deur' n draad. Daar was ook ander veranderinge. Ek stel voor jou geheue gebruik te monitor en monitor dit vir 'n geruime tyd. Ook kan dit nuttig wees om die gemiddelde bedrag van die geheue wat gebruik word deur een Apache draad om seker te maak, het sommige berekeninge en toepaslike waarde van die maksimum-drade vir Apache te stel.

    As jy nog vrae het kan jy net vra
    Laaste geredigeer deur vBET; 17-03-10 op 00:53.

  6. #6
    Michał Podbielski (vBET Personeel) vBET's Avatar
    Join Date
    Oct 2009
    Posts
    3,037

    Default

    Hey - ek het net op jou forum was dit vertaal ULTRA FAST ... So wat jy beweer oor en hoekom so kwaad houding oor vBET, wanneer jy van super-vinnige vertaling diens?

    Oorweeg dit asseblief wat server load beteken. Die verstaan van die betekenis daarvan kan baie nuttig wees om te verstaan wat gebeur op die bediener en hoe dit kan verband hou met die drade wat wag in die ry nie, want jy het geen hulpbronne, maar wag vir die reaksie van ander bediener (Google in hierdie geval).

    In my mening het jy 'n super-vinnige vertalings en jy het niks om oor bekommerd te wees nie

  7. #7
    Senior Member
    Join Date
    Feb 2010
    Posts
    210

    Default

    Ek het sites bou van 10 jaar, ek is ten volle bewus is 10x vrag beteken nie 10x hulpbronne, stop my soos 'n idioot en lepel voed my rommel te behandel. Die koue feite is met hierdie mod vs die ander mod jou vrag mega. En op piek tye my site is nou stadig en reageer nie. Ja, bladsye vertaal vinnig af-piek, maar teen 'n koste van' n stadige server later in die dag. Ek het 'n quad core, RAID-15k SAS bediener, wat geoptimaliseer is net mooi, loop dit 0,50 hele dag lank voor dit met' n groot verkeer. Dit is die VBET kode wat voeg laai en maak die server stadig in spitstye, dit is 'n feit, dit is nie toename in die verkeer, het ek dieselfde verkeer en bots het voor en die bediener coped fyn, dit is die vertaling produk. Tydperk. Hurry up en dit regmaak, ek is regtig nie wil 'n ander £ 300' n maand betaal vir 'n server upgrade net' n mod te hardloop lol.

  8. #8
    Senior Member
    Join Date
    Dec 2009
    Posts
    276

    Default

    Hoeveel tale moet jy in staat gestel het? Hoeveel poste moet jy doen? Het jy vbseo en sitemap kragopwekker geïnstalleer? Hoeveel bots slaan die werf 'n dag?

  9. #9
    Senior Member
    Join Date
    Feb 2010
    Posts
    210

    Default

    Hi!

    32 tale aangeskakel.

    100,000 poste.

    vbseo en sitemap geïnstalleer.

    sitemap plugin sê 1000.000 bladsye gekruip 'n dag.


    Die feit is, as ek die mod en die bediener, bot en gebruikers herlaai nog steeds slaan my bediener dieselfde as voorheen, dieselfde bladsye is nog in googles indeks en dus kry ek dieselfde verkeer aktief is of nie.

    Die enigste verskil is dat met die mod afgeskakel die robotte en Google is die Engelse bladsy, ja, die verkeer is identies, is die enigste verskil dit is nie 'n vertaalde bladsy te sien, so die mods databasis kwessies te vermy.

    Dit is duidelik dat as die dag vir my hierdie mod vrygestel is sonder behoorlike toetsing, en duidelik is die eienaar is nie geïnteresseerd om die kwessies aan te spreek.

    Misluk.

  10. #10
    Senior Member
    Join Date
    Feb 2010
    Posts
    210

    Default

    Michael, jy is verkeerd, hierdie las is nie veroorsaak deur 'n toename in die verkeer, is dit veroorsaak is deur die lees en skryf van vertalings aan MySQL.

    As vBulletin span kan lees en skryf aan MySQL met lae lading why cant jy?

    Swak kode my vriend.

Page 1 van 2 12 LaasteLast

Tags vir hierdie draad

Toestemming vir plekke

  • Jy mag nie nuwe drade
  • Jy mag nie Voeg antwoorde
  • Jy mag nie Voeg aanhegsels
  • Jy mag nie wysig jou poste
  •