spameris Posted July 16, 2015 Author Report Posted July 16, 2015 Jā bet nu IIS+php būs maz lietotāju, kā arī apache+php+win būs vēl mazāk lietotāju. Un ja ir specifiskas specifiskas problēmas tad ir sarežģiti viņas risināt, dēļ praktiski neeksistējošās lietotāju bāzes šādiem setupiem. Un IIS+php gadījumā MS ubersertificēti speci ar neko daudz nepalīdz. Ar IIS+.net jau viss ir OK, tikai šķiet ar php nav tik labi. Ja nemaldos tas ISAPI ir deprecated. Nu ar kodu jau ar šķiet viss vairāk, vai mazāk OK, jo nav jau problēmas ar ātrumu, bet kā jau minēju ar paša IIS+php stabilitāti. Quote
briedis Posted July 16, 2015 Report Posted July 16, 2015 Varbūt beigās pietiktu ar to, ka ieviestu kešošanu :D Jāsaprot, kas tad ir tas pudeles katls?CDN + normāla kešošana / optimāli kvērijis sniegtu noteikti 10x lielāku labumu, kā migrācija. 45k 6 stundās ir 125 pieprasījumi minūtē, kas ir diezgan smieklīgs skaitlis, kuru, man liekas, ka pat kāds raspberry pi varētu mierīgi pacelt. Pieslēdziet new relic, ātri vien sapratīsiet, kas to pasākumu bremzē. Quote
codez Posted July 16, 2015 Report Posted July 16, 2015 1 apmeklējums ģenerē no dažiem līdz pat vairākiem desmitiem un pat pāri simtam pieprasījumu (.css, .js, .jpg, etc.), atkarībā protams no lapas struktūras. Quote
spameris Posted July 16, 2015 Author Report Posted July 16, 2015 (edited) Nu runa nav par web servera pieprasījumiem, bet par cilvēku pie datora, neticu ka PI var tikt ar to galā. Un vispār arī nevienu vārdu neteicu, ka strādā lēni tur kautkas. Problēma ir piemēram ar php wincache shared memory lokiem, kas uzrodas randomā, nesaprotamiem IIS FastCGI interfeisa krešiem. Edited July 16, 2015 by spameris Quote
Roze Posted July 17, 2015 Report Posted July 17, 2015 Kāpēc izmantot to Wincache un nevis nativo Zend OPcache? Jebšu tur ir vēl kaut kāda funkcionalitāte bez opkoda keša? Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.