WP target audience

[foxsk8]

Par WP ātrdarbību:

 

Wuu, uzliec queru monitor pluginu, un palaid wp ar viņa standarta ādiņām, bez neviena plugina, bez nekā, kādu rezultātu tu iegūsi? Un vēl uzliec šo pašu uz DO serveri, kur viņiem jau serveru līmenī ir laba performance, man uz 4 kodolu proci, 8 gb ram, win sistēma, parasts web serveris, WP vilkās, uz DO, lido par 5 zaļiem mēnesī, neizmantojot nekādus tur w3 total cache, un citas figņas. 

 

Dzīvs piemērs uz klienta izvēlētu skinu, ko kodējuši indušu themes club, kur skins ir pakaļā, load problēmas, nestabilitāte, utt... 101 lieks kverijs. 

 

Es par WP globāli runāju tikai un vienīgi tā, ka es izstrādāju custom html griezumu no dizaina, un customizēti pielieku visas funkcijas, skinu izveidoju pats, uz WP bāzes. 

 

Pieatačoju divus variantus:

 

1. Ir skins, lokāli vs DO, 

2. Unikāls risinājums uz localhost.

 

Veči, es Jums nelieku lietot WP skinus, mega skinus, kas visi ir huiņas un maksā lēti, vairāk problēmu nekā labuma, tas būtu no sliktās sērijas, pieredzes, un 100% visi Jūs saskaraties ar ko tādu, un nevis ar unikāli pašiem uzveidotu ādu. 

 

Kas grib, var paši uz saviem WP uzlikt šo, un tad nu pēc šī plugina varētu daudz ko izecināt:

 

https://wordpress.org/plugins/query-monitor/

 

Tāpēc arī veidojās šis stāsts kāpēc WP sūkā. 

Edited February 11, 2015 by foxsk8

[Roze]

Tāpēc arī veidojās šis stāsts kāpēc WP sūkā. 

 

Jā un nē t.i. es piekrītu tam, ka ar sūdīgu pluginu/konfigurāciju/u.c. var mierīgi "sadirst" arī labu lietu, bet pēc būtības arī vaniļas (vanilla) WP nav ātrs pasākums (no kā, manuprāt, veidojas lielākā daļa stāstu)

 

Ja es pariezi interpretēju screenshotus, tad man nav saprotams, kam nepieciešami 246 kveriji "unikālājam risinājumam" nemaz nerunājot par 808Q, kas figurē "skinā" (būtu interesantāk, ja parādītu detalizētākus izvadus).

[foxsk8]

Jā un nē t.i. es piekrītu tam, ka ar sūdīgu pluginu/konfigurāciju/u.c. var mierīgi "sadirst" arī labu lietu, bet pēc būtības arī vaniļas (vanilla) WP nav ātrs pasākums (no kā, manuprāt, veidojas lielākā daļa stāstu)

 

Ja es pariezi interpretēju screenshotus, tad man nav saprotams, kam nepieciešami 246 kveriji "unikālājam risinājumam" nemaz nerunājot par 808Q, kas figurē "skinā" (būtu interesantāk, ja parādītu detalizētākus izvadus).

 

Unikālam arī plugini, daudzvalodu atbalsts, WPML, kopā ar String Translate arī apēd jūtamus resursus kā tādus. Redzi, WP nav veidots uz tā teikt view, load bāzi, uz assetiem, ka ielādē moduli, js, css, failus, konkurētās fijas tikai tad, kad vajag, atverot lapu, viņas visas gan, core, gan pluginu fijas sāk darboties, vai konkurētam skatam, lapa vajag to, vai nē. Pārsvarā tie ir repeat kveriji, piem izvilkt diviem postiem title, piem to pašu the_title(); vai the_parmalink, hops, tie jau ir 2 kveriji, ja vēl tu tos iebāzē savādāk loopā, ciklā, tas jau aiziet vairāk, ja tev cikli un postu tipi ir dažādi, vairāki, piem tur līdz 10 tipiem, kur katrs apēd piem 5 kverijus ir jau 50, bildītes, utt.. the_content, vēl pieliekas klāt, iegūt meta datus, custom laukus, vēl, ieliekam ciklos, vēl nāk klāt, nerunājot par pašu menu, funkcijām, opcijām, utt.. ko WP visu velk laukā no DB, ierakstu, nevis tu manuāli norādi, vot logo pačis šitāds, un html gabals tāds. Tad tie 200 kverīji arī salasās kopā. Citā lapā atkal ir mazāk. 

 

Pilnos screen diemžēl rādīt nevaru, bet lokālais projekts ir arī diezgan apjomīgs. 

[Kasspars]

uz the_title un the_permalink nebūs 2 query. WP ielasot aktīvos postus ieliekt to atmiņā un nākšoreiz visi the_title the_permalink utt atgriezīs datus no atlasītajiem datiem un netiks taisīti  jauni db query.

Piemēram, wp_options ir key -> value tabula. Ir ieraksti, kuriem ir pazīme autoload=yes, tos WP ielasa ar vienu db querry un visā lapas ciklā vairāk neveic db pieprasījumus.

Tas pats ir ar post_meta. Tā arī key -> value tabula. Katram ielasītajam postam automātā tiek ar vienu query ielasīti visi meta dati, lai nevajadzētu taisīt db query katram posta meta pieprasījumam.

WP jau ir uzprogrammētājs, lai viegli varētu pievienot memcahced suportu tieši post-meta tabulai.

 

post meta ir ideāls pretendents uz redis

 

Ļoti, ļoti bieži pluginu developeri grēko ar to, ka taisa db pieprasījumus pa tiešo caur $wpdb, nevis izmanto API. Tas arī ir iemesls, ka rodas daudz lieku db pieprasījumu.

 

Tas pats attiecas uz db pieprasījumiem ciklā. Jebkurš pieredzējis developeris nekad netaisīs db pieprasījumu ciklā. Viņš uztaisī vienu pieprasījumu un tad iterēsies cauri atlasītajiem datiem. Un šī ir ne tikai WP problēma, tā ir sūdīgu developer problēma.

 

 

Varētu daudz un dikti stāstīt par WP, bet jēga tērēt laiku, ja šo visu lasa tikai heiteri :P Un tie kas nav heiteri tā pat ir paši pastudējuši WP kodu un saprot, kā darbojas wp iekšas.

Edited February 11, 2015 by Kasspars

[Roze]

.. bet jēga tērēt laiku, ja šo visu lasa tikai heiteri :P

Nu arī neheiteriem izskatās, ka nav vienota viedokļa :)

[foxsk8]

<?php
						 $args = array(
									   'post_type' => 'pakalpojumi',
									   'posts_per_page' => 4,
									   'paged' => ( get_query_var('paged') ? get_query_var('paged') : 1),
									   );

						query_posts($args);
					while (have_posts()) : the_post();
					?>
					<article class="col-sm-6 col-md-3 s-item">
						<h4 class="h2 hasico"><a href="<?php the_field('button_url'); ?>"><i class="icon <?php the_field('service_icon'); ?>"></i><?php the_title(); ?></a></h4>
						<?php the_content();?>
						<a href="<?php the_field('button_url'); ?>" title="<?php the_title();?>"  class="lnk-arrow"><?php the_field('button_text'); ?><i class="icon icon-arrow-r"></i></a>
					</article>
					<?php endwhile;?>

Un šādu ciklu ir vairāk, šaubos, ka viņs tikai vienu reizi uztaisīs kvēriju kā tādu, ja vēl nomet pa vidam wp resetu kur tas nepieciešams, tad ir tā kā ir. Labi, tur paginators šajā gadījumā nebūtu vajadzīgs, bet gan showposts. 

 

Un arī protams par query monitorings kaut ko no tā visa noēd nost. 

 

Šis gan tāds interesantāks:

<?php
function test_unoptimized_query() {
	$time_start = microtime( true );
	$posts = get_posts( array( 'posts_per_page' => -1 ) );
	return number_format( microtime( true ) - $time_start, 10 );
}

function test_optimized_query() {
	$time_start = microtime( true );
	$posts = get_posts( array( 'posts_per_page' => -1, 'cache_results' => false ) );
	return number_format( microtime( true ) - $time_start, 10 );
}

https://thomasgriffin.io/optimize-wordpress-queries/

Edited February 11, 2015 by foxsk8

[briedis]

 

Nez cik lietotāji viņi paspēja apkalpot, līdz wordpress pakrita?

[yancis]

Manas skolas majaslapa bija uz WP. Katru dienu ap plkst 16:00:-17:00 paradijas sis errors (laiks kad visi atnak majas un atver to lapu).

Tatad ja bija kadi 200 page hiti stundas laikaa - tad nomira.

[Kasspars]

paheitojat vēl par linux, kā nekā uz linux tas viss griežas :D

[foxsk8]

 

Nez cik lietotāji viņi paspēja apkalpot, līdz wordpress pakrita?

 

Parasti tur nomirst mysql dēļ lielā ram patēriņa, un ja tas viss vēl stāv uz shared kasti, tad nav brīnums. Viss ir atkarīgs arī no servera, un kas tieši tur apakšā izmantots, cik pluginu, utt.. droši vien nav bijusi nekāda optimizācija

[Val]

Piemēram, wp_options ir key -> value tabula. Ir ieraksti, kuriem ir pazīme autoload=yes

Izstāstīsi man, kādas skujas pēc matainajiem tur vajadzēja ielikt varchar(20) bez indeksa?

Kad options tabula tiek pietirsta ar miljons aizvēsturiskiem transientiem, kas paši no sevis nedzēšas, tad lai nolasītu pāris simtus optionus, nākas taisīt pilno pārlasi. Way to go, wp(zdu)...

Edited February 13, 2015 by Val

[Kasspars]

Nu tak uzliec varchar(miljons) indeksu un izdzēs vecos transients! Es vainīgs, ka nemāki kodēt un izmanto līkus plaginus

[Val]

Ne es to lapu taisīju. Šie bija tikai secinājumi.

[Kasspars]

By default index ir uz option_name lauku. Tavā gadījumā kāds acīmredzot ir noņēmis indeksu vai arī nemācēja importēt tabulu ar indeksiem.

 

Tā arī rodas briesmu stāsti. Viens nemācējā izdarīt lietu X, otrs nepareizi saprata X un sāka skaļi runāt

[Val]

SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'

Indekss ir, bet šajā gadījumā uz option_name tas nemaz nav vajadzīgs.

 

WP target audience :mrgreen: