May 31 2009
projekts – procesā
Šo varētu uztvert kā turpinājumu bloga ierakstam “Projekts“. Tagad, pēc aptuveni pusgada reāla izstrādes darba un tuvojoties kaut kādam rādāmam rezultātam, varu izdarīt secinājumus un varbūt arī lietas, ko varbūt bija labāk darīt savādāk.
OS. Linux. Nav nozīmes kāds distributīvs, pa lielam visi viņi savu funkciju pilda. Šobrīd, izstrādes vidē, darbojas CentOS, bet tas ir tikai tāpēc, ka viņš tur jau bija:) Ar visu savu saimniecību, kas man absolūti nav vajadzīga. Tāpēc man patīk BSD sistēmas, kurām sākotnēji nav nekā vispār un var salikt tikai to, kas tiešām nepieciešams.
Webserveris. Lighttpd. Nekādu problēmu. PHP FastCGI modē un visas lietas. Patiesībā viena lieta mani mazliet pārsteidz saistībā ar manis izmantojamo gettext. Protams ir izstrādāts normāls web interfeiss tulkošanas lietām, sajūgts arī ar mysql, bet ne par to stāsts. Stāsts par to, ka biju lasījis, ka pēc jebkurām gettext izmaiņām jārestartē webserveris lai izmaiņas stātos spēkā. Manā gadījumā ir tā, ka tas notiek pats no sevis. Patiesībā ar kļūdu – pirmais php requests pēc gettext update beidzas ar 500. kļūdu, bet pēc tam viss notiek it kā nekas nebūtu bijis un arī izmainītie, jaunie teksti strādā.
Turpinot par PHP – CodeIgniter framework kā MVC “groži” tika atstāts. Tiesa gan reāli sākot darbināt diezgan drīz uzradās lietas, ko gribējās savādāk, kā arī situācijas, kad bija vajadzība mazliet izkāpt no CI uzliktajiem rāmjiem. Pirmais, kas cieta, bija sesiju apstrādes library. Oriģinālais tika nonests, vietā uzlikts “native session“, papildināts ar memcache. Iemesls diezgan triviāls – šis CI oriģinālais sesiju handleris arī datus storēja pa savam, bet es orientējos uz izstrādi, kur paredzēta vieta serveriem, uz kuriem nu nekādi nav vēlmes stutēt augšā CI. Piemēram bilžu/failu upload. Tā kā man nebija cilvēcīgas iespējas no šiem serveriem tikt klāt pie sesijas datiem, tad vieglākais ceļš bija nonest šo neparocīgo risinājumu:)
Vēl CI tika papildināts ar pāris pašrakstītiem libraries memcache un gettext supportam. Mamcache gadījumā jauns CI library, kā arī papildnāts sesiju library. Gettext gadījumā updeitots language library.
CI uzliktie izstrādes rāmji (MVC), gan dažreiz mazliet samazina izstrādes ātrumu, taču vairumā gadījumu tomēr palīdz noturēt kodu saprotamu un viegli updeitojamu. Nestandarta situācjās, kad ir vēlme izdarīt to, ko it kā neparedz CI, tas ir elementāri izdarāms griežoties pie CI instances pa tiešo ($CI = & get_instance();) un kā tika novērots, tad šis paņēmiens arī nerada kādas vērā ņemamas problēmas noslodzes vai ātrdarbības ziņā.
Dati. Trijotne – mysql, memcache, sphinx. Ar memcache viss bija skaidrs, tiesa gan pie nepietiekoša atmiņas daudzuma sāka rasties ievērojama CPU noslodze, bet tas vairāk bija dēļ tā, ka uz 1GB RAM tika mēģināts palaist visu, visu – webserveri, mysql, sphinx, memcache utt. Protams, ka tas dzelzis nīka ārā, jo 2Gb bija swapā:)
Ar mysql pagaidām cīnos, jo performance salīdzinājumā ar pārējiem datu handleriem ir nožēlojama un man pagaidām nekādi neizdodas to panākt ciešamu. Taisnības labad gan jāsaka, ka neesmu vēl īpaši mēģinājis tur kaut ko optimizēt. Īpaši vērā ņemams lēnums ir attiecībā uz kombināciju “insert on duplicate key update ”. Atsevišķās vietās nācās arī nomainīt insertus ar “delayed insert” un sekojošu innodb -> myisam pāreju attiecgajām tabulām. Frontend galā tīru select uz mysql gandrīz nav nemaz – tiešajiem datu selektiem starpā memcache, datu atlasēm – sphinx.
Attiecībā uz mysql, nākamais pētāmo lietu sarakstā ir Falcon storage engine, bet par to man pagaidām komentāru nav.
Ar sphinx bija dažas nianses attiecībā uz datu indeksēšanu un patiesībā vairāk uztveramas kā sphinx bugs, bet par to tagad sīkākos iztirzājumos neizplūdīšu. Galarezultātā un arī pateicoties mysql lēnumam, sphinx tiek izmantots krietni plašāk, nekā biju plānojis sākumā. Plānots bija tikai geo lietām, bet tagad tas darbina arī visādas datu relāciju lietas, kā arī indeksētus filtrus, keywordus, fulltext search utt. Vienīgā problēma ir neliela datu izmaiņu aizture, bet ar dažādiem paņēmieniem to ir izdevies samazināt līdz minimumam (1-2sec). Patiesībā ir doma kaut kad tās sphinx lietas tīri no praktiskā viedokļa iztirzāt atsevišķā bloga ierakstā.
Client side , UI risinājumi. Ļoti daudzveidīgi. It kā vairums gatavu risinājumu – jqueryUI, ajax forms, jcrop, swfupload, utt, bet lielu daļu nākas stipri pielāgot gan vizuāli, gan funkcionāli. Atsevišķs stāsts varētu būt par Google Maps API, priekš kā pat sākotnēji tika uztaisīta tāda lieta kā marķeru nepārklāšanās princips – čekojot marķeru atrašanās rādiusus, jeb poligonus. Diemžēl pagaidām šo principu esmu atslēdzis, jo Internet Explorer javascript renderēšanas ātrums ir vismaz 10x mazāks, nekā jebkuram citam browserim un nekas nav mainījies arī IE8. Iespējams, ka nāksies atteikties arī no ajax json datu saņemšanas principa – arī šī paša iemesla pēc. Par IE runājot – arī IE6 vizuālā renderēšanas īpatnības hvz cik papildus izstrādes laika prasošas un droši vien ir saprotama problēma jebkuram web izstrādātājam:)
Nobeigumā, jeb secinājums. Ir sajūta, ka aptuveni mēnesis pirmsizstrādes izpētes un plānošanas laika ir bijis gana noderīgs, jo ir izdevies izvairīties no nopietnām problēmām pašos izstrādes principos un lietojamajos rīkos. Lielākā problēma patiesībā bija koncepcijas iztrūkums pašam projektam – tikai tādas vīzijas skiču un mutiskā veidā. Attiecīgi neiespējami kaut ko pietiekami precīzi izplānot laiku un resursu ziņā. Tas, protams, aiz sevis pavelk arī tādas lietas kā prasību maiņas, redizainu utt. It kā jau visu paši arī daram – paši domājam kā labāk, paši pēc tam pārtaisam, bet manuprāt ir ļoti lietderīgi vienreiz pasēdēt un patiešām padomāt, nevis ķert karstu un sākt taisīt pat īsti neapjaušot ko:) Tas tā – it kā mācība priekšdienām, kura tomēr vienmēr atkārtojas no jauna:)
