Roze

F3llony, kaut kāds reāls iemesls taču ir bijis, kapēc Tev nav ticis atbildēts, vai neesi pieņemts. 

Šodien parunāju ar lietvedi par šiem jautājumiem, izstāstiju cilvēku sāpi par to, ka neesot saņēmuši nekādu responsi, un lieta ir tāda, ka līdz šim uz šiem pieteikumiem ir atbildēts uz draugiem portālā reģistrēto e-pastu, kas, protams, var gadīties vairs nav aktuāls (grūti arī pateikt kāpēc šāda prakse). Vismaz viņa teicās, ka atbildot vienmēr, taču ir tiešām gadījies, ka uz sarunām uzaicināts cilvēks ir teicis ko līdzīgi.

Mēģinās uzlabot šo procedūru.

Tā ir tikai pašā Draugu portālā, citos apakšuzņēmumos vadītāji nav kāpuši pa kodiera kāpnēm, tā ka no programmēšanas zina tikai tik, cik paši painteresējas un tu ieskaidro.

Es vairāk to domāju to tā kā tiešā (tehniskā) darba vadītājus, ne pēc biznesa strukturas, kur ir citas kompetences un tad viņu termiņi (vai kādi citi pieņēmumi) bez jelkādām konsultācijām būtu no zila gaisa rauti. Citādi jau piem. Vendonam, Maponam CTO visi ir izbijušie.. nu labi T2R varētu būt izņēmums :P

Visas grupas vadītājs gan ir programmētājs :)

Zinu vēl vismaz vienu gadījumu, kad ir bijis citādi. 

Būs jāiet skaidroties ..

Šāda fīča ir, bet cik zinu, tā ir pieejama apstiprinātām aplikācijām/lapām t.i. tik brīvi lietotāja vārdā postēt nav iespējams.. 

Humora pēc, man pat neatbildēja uz pieteikumu. Līdz ar to, diez vai mans ego, attieksme un lielā mute būs pie vainas. 

Izklausās kaut kā neforši, jo cik zinu noteikti atbild visiem un vienmēr, arī gadījumos, kad cilvēks uzraksta, ka programmēt nu pilnīgi nemāk, taču ir strādājis veikalā par pārdevēju vai arī jelkāda cita tipa kontaktam (kaut vai pilnmēness ietekmē).

Upē, protams, ūdens ir aiztecējis, bet gribētos cerēt, ka tas noticis kaut kādas tehniskas ķeskas dēļ un nekā citādi ..

Piemēram, pret temporary pīķiem; vietu, kur nogrūzt neaktīvos aizņemots apgabalus; utmldz. Katrā ziņā, ar swap sistēmas strādā stabilāk.

Šī gan jau kļust par citu tēmu, bet nepiekritīšu..

Sistēmas ar temporāriem pīķiem (kas pārsniedz atmiņas apjomus) nevar saukt par stabilām.

Protams, no administratora viedokļa vienkāršāk (un varbūt mazāk galvas sāpju) ir pielikt "kaudzi" ar swapu, taču tā zināmā mērā ir vienaldzība (mums ir tāda programmētāju palama/"otmaska" par datu apjomiem - "Tas jau neko neaizņem").

Ja tādi ir, vai nu nav izvērtēti uz servera strādājošo aplikāciju/servisu īpatnības (memory leakings), iespējamie konfigurācijas limiti, nav pienācīgs monitorings vai arī vienkārši izdalītie aparatūras resursi ir nepietiekami, tādējādi sanāk, ka agrāk vai vēlāk var rasties problēmas un pēc Mērfija likuma - tās būs pašā nepiemērotakajā brīdī.

Pēc pieredzes un incidentiem vismaz līdz šim 2.4.x/2.6.x sērijas (jaunākie sākot no kāda 3.10.x uzvedās krietni labāk) linux kerneļi ļoti grūti (vai vispār ne) tiek galā ar ar out of memory un out of swap situācijām (pīķu gadījumā pēc vilciena efekta tās parasti seko viena otrai), t.i. rezultāts ir krietni sliktāks - sistēma pilnībā neresponsīva, nekā ja swapa nav.

Protams, bezswapa variantā OOM killeris ir nežēlīgs (burtiski "upurē/nogalina bērnus"), lai arī to var konfigurēt un vitāli svarīgos servisus (piem db utt) iezīmēt kā neaiztiekamus, taču pat tad, ja sistēma piespiedu kārtā ir beigusi procesu un tā rezultātā ir, piemēram, notikusi db  (neatgriezeniska) datu korupcija (ar mysql un innodb, kas it kā skaitās acid/crash safe, samērā vienkārši panākams rezultāts (varbūt ir iemesls izvēlēties citu engine?)), ja nav rezerves kopijas  (datu/servisa), scenārija, kā tos atjaunot - arī to nevar saukt par stabilu sistēmu.

Sanāk tikai tāda nosacita stabilitātes sajūta ..

Nu gluži tā gan nav, jo to ko metīs ārā no RAM'a kontrolē vm.swappiness parametrs, kernelis var sākt paging'u arī pirms viss file cache ir atbrīvots 

Jā pareizi tā ir, bet viņam nav swapa (attiecīgi process novienkāršojas :) )..

p.s. mūsdienās swapu likt uz serveriem ir diezgan nejedzīgi (vai vismaz minimums ar vm.swapinnes = 0), personīgi pārstāju likt swapu pirms gadiem 10 ..

p.s.2. izņēmums varētu būt zram, kur uz ram izveido disku/partīciju (kompresētu swapu) un tā teorētiski palielina sistēmas (virtuālās) atmiņas ietilpību, bet tā necieš no nesalīdzināmi lēnākās cieto disku darbības. To gan biežāk izmanto desktopos un mobilajās iekārtās.

Tāpēc varbūt ir vērts pamēģināt kādu Draugiemgroup uzņēmumu, jo termiņus nosaka paši darbu veicēji (lasi programmētāji), taču darbu vadītāji, parasti paši izbijuši koderi, kas iemēģina sevi projektu plānošanas u.c. aspektos, cenšas zināšanās neatpalikt, lai nebūtu arī makaronu spraušana uz ausīm :)

Vai tas ir normāli, ka palikuši tikai 150+ megabaiti brīvi no RAM?

Uz linux/unix tipa sistēmām tas ir normāli, jo OS maksimāli cenšas izmantot visu pieejamo atmiņu procesu paātrināšanai (atstājot nelielu brīvu rezervi) - sajā gadījumā 'top' vat skatīties pie 'cached Mem' t.i. no 2Gb rama 1Gb tiek izmantots failu kešošanai, līdz ar to tev principā brīvi ir 1.1Gb rams, jo, ja kādai aplikācijai/procesam būs nepieciešama papildus atmiņa, linux izsviedīs daļu šī keša un iedos to procesam.

Vēl jautājums par to FastCGI. Laikam neesmu īsti pareizi uzstādījis, bet lieta tāda, ka, pievienojot jaunu rakstu no desktop versijas viss normāli atjaunojas, bet, lai jaunais raksts parādītos mobilajā versijā, vajadzēja purge cache.

Fastcgi vispār ir protokols.

Vai šajā gadījumā tu domā nginxa fastcgi_cache?

Sanāk jebkurš low var panākt ka datucentrs paprasa projekta īpašnieku izņemt serveri. Dīvaini.

Nu tā (cik zinu) parasti nenotiek (ja vien līgumā nav kaut kādas specifiskas atrunas - vai arī tas ir kāds "best effort" tipa pakalpojums bez jebkādām garantijām) jebšu tas ir galējais solis pēc tā kad visi tehniskie resursi un risinājumi ir izsmelti ., jo nu ne jau klients kaut ko pārkāpj.

Ko tad viņi teiktu, ja Tu īrētu viņu virtuālo serveri (vps)? 

Un arī lasot mājas lapā ievietoto -  "Mūsu vērtības ir drošība un procesu nepārtrauktība!

Mēs esam kompānija kuras speciālistiem ir vairāk nekā 10 gadu pieredze, mums pašiem ir savs datu centrs ar vairāk nekā 40 starpsavienojumiem un 20 Gb ārzemju interneta kanālu. Mūsu atbalsta komanda ir sasniedzama 24 stundas diennaktī, 7 dienas nedēļā, bez brīvdienām." - tad sanāk tāda tukša salmu kulšana ..

Roze, Autors jau nekur nav minējis vai tas DDOS nav ar Latvijas trafiku :)

Latvijas trafiku ISPi/DC parasti spēj "apkarot" t.i. pāris zvani un kaitnieciskā iekārta/avots tiek iznīdēti  .. Dieva zīmes un roku plātīšana (arī dažādos citos kiberpārkāpumos) sākas brīdī kad IP ir ne-Latvijas.

Bet varbūt kāds ieteiks ko darīt manā situācijā?

Svarīgi ir kāds tas DDOS ir bijis, proti, vai tas ir kaut kas specifiski vērsts pret kādu aplikāciju (piemēram webserveri) vai vienkārši naturāls floods ar mērķi aizsist servera/provaidera trubu (arī vai tam ir gadījuma raksturs vai mērķtiecīgi tēmēts (kādam ir kāds kreņķis pret Tevi)).

Pēdējā variantā visplašāk izplatītais ir tā saucamais UDP floods, kur izmantojot botnetus un/vai dažādas ievienojamības serveru programmatūrā (piemēram ntp vai dns), tiek vienkārši gāzti liela apjoma dati un nav pat svarīgi vai uz servera vai provaiderim ir kaut kādi firewalli, jo trafika apjoms ir tik liels (mērāmi pārdesmit līdz pārsimt gigabitos sekundē), ka normāli pārstāj strādāt datucentra iekārtas. Maziem ISP / datucentra pakalpojumu sniedzējiem nav īsti mehānismu kā ar to cīnīties (ka vienā vai otrā veidā izraujot kabeli (mainot klienta IP utt)).

Viens no variantiem būtu apskatīt kādas iespējas (protams, atkarīgs no finansēm) ir izvietot savu serveri kādā no lielākajiem datucentra pakalpojumu sniedzējiem (piem Lattelecom, Telia, Deac) - tas protams neizslēgs DDOS, bet nerezultēsies ar to, ka klients tiek mests laukā no datucentra, kas principā ir (būtu jābūt) datucentra viens no pamatpakalpojumiem, goda un cieņas jautājumiem.

ISP/DC pakalpojumu sniedzējiem, kam ir savas starptautiskās trubas (vai piemēram, kā Telia kurai mātes uzņēmums vispār ir starptautisks carriers) ir iespējas vai nu pašiem vai ar savu peeringa partneru palīdzību risināt šos uzbrukumus augstākā līmenī (bloķēt upstreamus utt).

No tehniskā viedokļa (ja ir iespēja aprunāties vēl ar esošajiem DC speciālistiem) tā kā Tu mini, ka serveris principā domāts ir Latvijas auditorijai, tad kā variantu DDOS "apiešanai" var viņiem minēt un izmantot tā saucamo BGP Black Hole routingu provaidera AS/router iekārtā - proti, tā kā Latvijas internets LIX ir principā "atdalīts" no starptautiskā tīkla (izmanto citus kanālus), tad šāds piegājiens pilnībā nogriež piekļuvi/trafiku no ārzemēm.

Principā var jā, mūsdienās pat ir cilvēki, kas pa pāris (pārdesmit) dolāriem tirgo tīkla kapacitāti šādiem mērķiem ( http://top10booters.com).

HHVM (bijušais HipHop) nav "pārvaldītājs", bet Facebooka php jit  engine.

HHVM ir ok, ja nav nepieciešama kāda specifiska ekstensija, ko viņi nav noportējuši/pārrakstījuši ( https://github.com/facebook/hhvm/wiki/Extensions )

Kamēr Jūs te varās savā sulā, es veidoju risinājumus vs bizness, pieejamība, un to, ko reāli klients var atļauties un kas būtu viņam adekvāti. Un ar Wordpress lapām, jebšu PSD - Wordpress servisu es pelnu neslikti, pat vairāk nekā dažs labs sēžot pie bosa kantorī. 

Diezgan tāds dikvosīgs tomēr esi .. no vienas puses, saki ka pa 15 zaļajiem ietirgot klientam pluginu (kuru neviens neuzņemtos kodēt pa tādu naudu (lai gan, protams, viņi pelna krietni vairāk par katru transakciju)) ir ok, no otras puses lielies, ka pelni krietni vairāk, iepārdodot klientam 3rd-party risinājumu, kam vajag visādu "apčubināšanu".

Skatoties, piemēram, uz http://vip.wordpress.com/our-services/ izcenojumiem,  "$15,000 per upgrade" .. ir diezgan "ok", ja ir kas par to maksā (tāpat kā jaunu auto, kas izbeidzas pēc garantijas,  ražošanas principi (lasi, nevienam nevajag tādus kas iet 10+ gadus) utt). BET es neredzu nekādu iemeslu ar to lielīties.

Tak visi vairāk vai mazāk iesaistītie IT industrijā saprot (cerams), cik tiek pelnīts par "konsultācijām" un, ka tāds "upgrade" aizņem 5 minūtes..

Tā kā aizvien nesaprotu Tavu pārmērīgo sašutumu par to, ka kāds ir uzrakstījis ka WP ir slikti - ja tur viss būtu labi, bizness tak būtu sūdigāks un "savam džipam" nesanāktu, ne tā?

Tu pats piesauc to, ka neko optimizēt nevajag. 

Nevis nevajag, bet "var" neoptimizēt .. t.i, izvēlēties alternatīvu pieeju. Atšķirību (starp varēt un vajadzēt), es ceru, nojaut..

Es iesaku meklēt problēmas iemeslu, tu saki, nevajag Vispirms ir jāmeklē problēmu cēlonis, nevis bezjēdzīgi veidot cache piem lapām, diskiem, utt.. datubāzes kvērijiem, un kam tik vēl nē, ok browser cache, piem wp lapai, tas skaidrs, bet tur arī viņš iedalās. 

Ja atbild vispārīgi/vieglprātīgi, tad problēmas cēlonis principā ir zināms, proti tā ir produkta (lasi WP) izvēle un ar tām izrietošajām sekām - savādāk jau mums šajā forumā nebūtu arī šīs tēmas. 

Ja korekti, tad, protams, (programmatūras) optimizācija var būt gan interesants, gan kaitinošs, gan jautrs, gan izglītojošs, (gan ienesīgs) un ar gandarījumu vai naidu rezultējams process, bet ir svarīgi vai uzstādījums ir to paveikt maksimāli ātri ar minimāliem resursiem vai nē.

tam atkal kādā citā topikā vai kā savādāk tiek noraksts WP par to, ka tas līki, šķībi sakodēts, nekam neder, utt.. 

 

Viss, kas nestrādā out-of-the-box, agrāk vai vēlāk tiek noķengāts/norakts - tāda ir mūsdienu lietotāja (end-user) mentalitāte.

Attiecīgi risinājumi, kas ir "vollā un viss magically pēksņi strādā" un  kur klientam nav jāiejaucās (tā sevi pozicionē visi CDN, Cloudflares utt) ir bieži vien labāk akceptēti/atbalstīti, nekā ņemšanās ap visu "problēmu cēloni" (kas, savukārt, lielākoties ir vienkārši cilvēku slinkums - projektam pastāvot N-gadus aizvien mazāk un mazāk kādam ir vēlme ņemt un uzlabot/pārrakstīt to, kas jau kaut kā nebūt strādā).

Bet tāpēc uzreiz nevajag kā tādai jaunkundzei spiegt, ka nevienam nepatīk mana kleita un visi te slikti.. iešu citur kur "ir daudz citu labu forumu, vietu, diskusiju" ..

Visuvarenais Roze, plus vēl admins. :) Savākušies te normāls wordpress heiteru bariņš, kamēr pus pasaule, biznesi, daudz advancētas lapas, lietas, izstrādes, utt.. darbojas ar vispopulārāko CMS šobrīd, tad te daži cilvēciņi dzīvo savā pasaku zemē. Negribat, nevajag, ir daudz citu labu forumu, vietu, diskusiju, kur darboties un apmainīties ar zināšanām, pieredzi un uzzināt daudz ko jaunu un noderīgu. 

 

Laikam tiešām kā visi te daudz maz zinošie kadri, kas agrāk šeit bija migrējušies uz stack overflow un citur un visiem kā viens par php.lv ir apmēram vienāds sakāmais, pamazām sākšu pievienoties viedoklim.

Neviens neko "neheito" (lai gan ņemot WP popularitāti un ar to saistītās lietas (gan milzīgo caurumu daudzumu / bloatwari utt), tā principā varētu būt arī "normāla" (cilvēkiem raksturīga) parādība (skat M$ vai Apple utt)) - tēmas autors uzdeva jautājumu, pie tam, paskaidrojot, ka, viņaprāt, ir izsmēlis visas WP iespējas ātrdarbībai ar konkrētā CMS pluginiem, un tika ieteikti varianti problēmas risināšanai, kas (manuprāt) ir ar krietni labāku rezultātu un samērā lielu garantiju.

Komentējot, ka kāds kļūdās ir jānorāda kur un kā .. "gan blogs, gan veikals, gan lielapjoma portāls" neviens no šiem produktu tipiem neizslēdz cache iespējas. Pat vēl vairāk, lai kaut cik kontrolēt resursu izmaksas "lielapjoma" projektiem nav daudz citu variantu.

Ja Tu vēlies bīdīt biznesu un piedāvāt privāti WP optimizāciju, lūdzu, neviens ne par to iespringst vai kā savādāk, taču nevajag pašam izcelties ar to, par ko pats te tagad esi sašutis, naturāli apsaukājoties " te daži cilvēciņi dzīvo savā pasaku zemē" ..

mkay?

kur darboties un apmainīties ar zināšanām, pieredzi un uzzināt daudz ko jaunu un noderīgu

Cache risinājumi ir nozares stūrakmens.. Cache ir visur - sākot no zemākajiem / hardware līmeņiem (cpu l1/l2 cache, hdd cache, raid cache, os fs cache utt) līdz aplikācijām vai pat cilvēkresursiem .. Zināt par cache ir noderīgi.  

Roze pamatīgi kļūdās :) Wordpress saits var būt ..  lielapjoma portāls. :)

Tad kāds cits kļūdās .. ne es >_<

Kā arī iespējams kāds var paskaidrot, kas īsti ir HTML5 nu piemēram, kā tas atšķiras no iepriekšējām HTML versijām?

Ja gribas tehniski un specifiski, tad http://www.w3.org/TR/html5-diff/ .. īsumā - jauni elementi/atribūti un izmaiņas esošajos.

Un vai tiešām kodā nav bardags un vai to nevar uzrakstīt uz pusi mazāku koda ziņā ?

Koda "lielumu" parasti/bieži vien nosaka visādi dizaina vipendroni.

Nu, piemēram, vai ir tik ļoti būtiski tie apaļie stūrīši (vai uz lielākām izšķirtspējām tos var pamanīt?)? Novienkāršojot uz parastām kastēm paliek mazāk atsķirīgu elementu attiecīgi arī css samazinās utt

No otras puses parasti jau ir tā, ka (skarbajā) ikdienā šādas lietas ir mazākā sāpe - proti, weblapā tiek ielikta(s) megabaitīga(s) bilde(s) (flash video/gigantisks baneris) vai arī teiksim ielādēts kaut kāds jQuery u.c. kur pāris baitu optimizācijai vairs nav nekādas būtiskas nozīmes.

Bez tam reti kura weblapa no koda/formatēšanas viedokļa vairs izskatās pievilcīga - visi nodarbojas ar dažādiem inline / minify css/js utt hackiem ..

"Wordpress saits" liekas diezgan statisks (nemainīgs) pasākums - var arī neoptimizēt pilnīgi neko un uzlikt kādu cache risinājumu (Varnish / nginx+fastcgi_cache utt u.c.).

Droši vien daudz aiztaupītu, ja sākotnēji būtu skaidrāks vai "konfigam" jābūt "human readable" (tad, piemēram, Blitz komentārs par to, ka kaut kāds administrators, kas ņebumbum no php, INI tipa konfigā justos par kapeiku labāk, ir OK).

Ja to lasa/lieto php koderis vai kods, tad sāvādāk ..

 

INI

[config]
a=1
b=2

Pros:

• ātrāks par JSON un YAML

Cons:

• tikai 2 līmeņi

Skaldot matus http://php.net/parse_ini_fileman sanāk 3 t.i. pašā ini sanāk pseido masīvi

[third_section]

phpversion[aa] = "5.0"
phpversion[bb] = "5.1"
phpversion[xx] = "5.2"
phpversion[] = "5.3"

.. galā protams tas anyway ir arrays.

Offtopic - kā administratoram (no "cilvēkiem lasāmajām") vislabāk patīk nginx tipa konfigurācija:
 

section {
    var1 value1;
 
​    subsection {
        statement;
        var2 value2;
    }
 }

section2 {
...
}

Var, protams, arī šeit piesieties par to ka priekšā un pakaļā vajag {}, bet nu ..

Ja lieto Foreign Keyus, tad ir svarīgi vai tie ir pareizi/loģiski un kādā secībā dzēš ierakstus t.i. ar 'NO ACTION' nevar dzēst no parent tabulas ierakstu, kam ir reference child tabulā.

Šajā gadījumā kļuda "#1451 - Cannot delete or update a parent row: a foreign key constraint fails (`viesnica`.`rezervacija_has_serviss`, CONSTRAINT `ID_rezervacija` FOREIGN KEY (`ID_rezervacija`) REFERENCES `rezervacijas` (`ID_rezervacija`) ON DELETE NO ACTION ON UPDATE NO ACTION) " norāda, ka nevar dzēst ierakstu no Rezervacijas tabulas, jo uz to referencējas rezervacija_has_serviss tabula.

Teorētiski samainot (uzliekot virspusē kā pirmo) dzēšanu no rezervacija_has_serviss varētu palīdzēt konkrētajai lietai (un tā izkārtot arī visas pārējās tabulas (pēc ERD shēmas) - sākot no "tālākās" līdz vidējai jebšu centrālajai) 

No otras puses, ja jau ir nepieciešama šāda veida dzēšana no visurienes/visām tabulām (un vēlme lietot FK), tad, manuprāt, ir jēga ON DELETE darbību nomainīt no NO ACTION uz CASCADE  ( http://dev.mysql.com/doc/refman/5.6/en/create-table-foreign-keys.html ) un tad dzēšot no "master" (šajā gadījumā Lietotaji) tabulas ierakstu visiem referencētajiem ID būtu jāizdzēšas automātiski pašiem, bez nepieciešamības lietot trigeri (ekspirementiem var pamēģināt arī SET NULL, tas nedzēsīs ierakstu, bet nomainīs attiecīgos id, lai saprastu vai viss notiek korekti).

Personīgi, gan škiet, ka FK ir diezgan liela sāpe (uz visiem jābūt indeksi, vienādas storage engīnes, nevar būt partīcijas utt) un izprotamāka (db) loģika ir vai nu aplikācijas pusē vai plikos triggeros.

Tāpat arī FK Cascade dzēšanas neaktivizē aiztikto tabulu trigerus t.i. nav iespējama kaut kāda atdalīta ON DELETE loģika pašai tabulai utt.

Tāpēc, ka pirmais bija MySQL, to bija super vienkārši lietot un tā tas aizgāja

Pa lielam šis.

MySQLs kļuva populārs dot-com burbuļa laikā (90-tie - 2000).

To bija samērā viegli un vienkārši uzlikt / LAMP (Linux+Apache+MySQL+PHP) utt, tam bija laba ātrdarbība, veiktspēja šādiem webprojektiem, kā arī vienkāršotas lietas lietotāju vajadzībām (kaut vai piemēram Autoincrement, kur Oracle un PG bija nepieciešams manuāli veidot specifiskas sekvences utt).

No administratora viedokļa ne Postgresam, ne Oracle tajā laikā ne tuvu  (vai vispār) nebija nekāda jēdzīga (piem pat līdz 9. postgresam ir visādi 3rd party tooļi kā Slony utt jālieto) replikācija pret MySQLa binary logu sistēmu.

Tāpat Oracle gadījumā (lidz 10. versijai, kad beidzot parādījās Oracle instant client), lai piedabūtu php komunicēt ar datubāzi uz (web)servera bija jāveic gandrīz pilna Oracle instalācija, kas bija pinķerīgi un laikietilpīgi,

p.s. tagad gan kopš MySQL īpašnieks ir Oracle droši vien vairāk popularitāti iegūst paralēlie projekti kā MariaDB vai Percona ..

Cik atceros mod_status rāda statistiku/statusu (workerus utt) par visu serveri kopumā.

Attiecīgi direktīvu principā ir jēga likt tikai vienā no vhostiem (vai default domēnam) caur kuru tu apmeklēsi /server-status adresi (izvadi būs identiski neatkarīgi no vhosta).

Var mēģināt ieslēgt "ExtendedStatus On" lai redzētu detalizētākus datus par pieprasījumiem/domēniem utt.

p.s. protams labi adresei ir uzlikt arī kādus ierobežojumus tad, jo būs iespējams redzēt GET parametrus u.c.

Pa smuko.

Tas ir tikai tas, ko jūs redzat no API puses. PHP koda pusē tas extension ir drausmīgs, un tas vien jau ir ļoti labs iemesls, lai no tā atbrīvotos.

Nu jau tu lej ..t.i. vai nu apzināta trollošana vai jāsaka, ka īsti nezini par ko runā.