Jump to content
php.lv forumi

WP target audience


qwerty
 Share

Recommended Posts

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ā. 

post-1596-0-58281300-1423676439_thumb.png

post-1596-0-47948600-1423676449_thumb.png

Edited by foxsk8
Link to comment
Share on other sites

  • Replies 47
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

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).

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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 by Kasspars
Link to comment
Share on other sites

<?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 by foxsk8
Link to comment
Share on other sites

img.2015.02.12.LtcC7T.png

 

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

Link to comment
Share on other sites

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 by Val
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share


×
×
  • Create New...