годзіць развіцця

У апошні час я займаюся ў асноўным з кодам замест адміністрацыі так драмамі, перад якім я стаю з kodene значна больш, чым такі сервер, таму я вырашыў накідаў некалькі радкоў нонсэнс, што ўдалося стварыць. Boosted рыхтуюцца прадставіць свой праект, які вымусіў адкрыццё некалькі драматычных частак

  • Първото нещо което което със сигурност щеше да създаде проблеми е изключването на javascript от браузърната поддръжка. Както всяка модерна апликация така и нашия инструмент използва доста JS за AJAX і іншыя дынамічныя працэсы, якія перадаюць інтэрактыўнасць і сучаснае бачанне і палепшыць функцыянальнасць. Мы шмат думалі аб тым, каб найбольш прымальным быў з інфармацыяй печыва, а затым PHP каб праверыць, ці з'яўляецца інфармацыя сапраўдная, і калі ўсё добра. Вельмі пісьменныя рашэнне, але, нарэшце, з'яўляюцца больш прэзентабельны версію. HTML будзе гуляць, калі ён прыходзіць у NoScript. Я думаю, што гэта самае элегантнае рашэнне.
<noscript>
<meta http-equiv="refresh" content="0;URL=./nojs.html" />
</noscript>

Як правіла, сітуацыя трывіяльная, калі мы перастанем падтрымка JS будзе перанакіраваны на nojs.html. Просты і вельмі эфектыўнае рашэнне

  • Php multhithreading – многія nishkovosta нешта вельмі карысна для працэсараў з вялікім ядром (не тое, што на аднаядзерны не ў парадку, але многія рэчы ядзерныя сістэмы з'яўляюцца яшчэ адным піва). Наша праграмнае забеспячэнне мае частка, якая займаецца зборам інфармацыі з іншых API – тая і я импортва ў наша база Дані. Obshtovzeto ніякіх выклікаў, за выключэннем, што ён зноў рэалізаваны з multhithreading PHP ў рэжыме CLI, паколькі гэты працэс з'яўляецца dosatachno вялікі і павінен быць atomatiziran каму-то неабходна, каб зрабіць гэта ўручную. Тут была драма, звязаная з працэсамі fokrvaneto і струмень не толькі ствараць даччыны працэс-і сцэнар, які чакаў, каб priklyuchabota стварыць новую. Па-дурному, што забіў шматпрацэсарнай ўяўленне пра тое, што на самой справе паводзіны і ня multhithreading, але гэта дэталі. большасць вылучаныя & пасля таго, як судовы працэс, які азначае, каб працягнуць сваю працу сцэнарыя пакуль ніякіх зменаў у паводзінах, неабходных і стандартны вывад сцэнара будзе перанакіраваны – у маім выпадку, як добра /DEV / нуль 🙂 Накрая структурата на тази част от кода изглеждаше така
$pid = pcntl_fork();
if ($pid == -1) {
die('could not fork');
}else if ($pid) {
// we are the parent
echo "I'm parent  \n";
pcntl_wait($status); //Protect against Zombie children
} else {
// we are the child
echo "I'm a child $timer  \n";
exec("$command > /dev/null &");
exit (0);
}

Primerčeto зноў е трывіяльным. Ад да спектакля я быў вельмі ўражаны перамяжоўваюцца паміж пад'ёмным працэсаў і гэтак жа пра 50 працэс-дзіця, які зрабіў свой stranba 7800+ MySQL ўстаўляе аб 30-40 шведскіх крон. Машына вельмі слабая, таму што мы varar тэст перад нанясеннем, каб падняць рэальны.

  • Mysql querys – Я быў у шоку ад вялікай глупствам. Быў код, які зрабіў 4-5 непатрэбныя запыты да базы дадзеных, замест таго, каб выкарыстоўваць больш плённую запыт SQL, а затым асноўную працу, каб прынесці PHP-гэта. Драма была такая, найбольш- напред се правеше една заявка която взимаше информация после изхода от заявката се използваше да се направят други заявки като тя служеше за аргументи. Доста грозна и тлъста ситуация. Subquery а е непозната територия явно както и left join или просто не са били обмисляни нещата добре. Хванах пренаписах заявката всичко се получи доста добре и като цяло натоварването падна с около 200% за същата част от кода.

В общи линии това са нещата на последък с които се заниамваме и немога да кажа че е скучно но понякога се изумявам от разни необмисляни парчета код които трябва да поправям а най стеращното е че често са мои 😆

падтрымліваючы Zemanta

2 каментары

  1. И аз имам тегления на данни, сложени в crontab-a. Пробвах преди със & в края, но ставаше пиково натоварване, грозна история. Сега съм ги оставил, като свърши единия процес, да пуска другия, но това е ужасТ :> Като зацикли някъде и всичко отива по дяволитетова го решавам като килвам старите процеси, като дойде време да се пуска новия, но това е още по-голям ужасТ, защото губя данни. Та ще се се опитам да имплементирам, твоето решене по този въпрос. Благодарско! 🙂

    1. Ами по моя метод хубавото е че информацията може да се обработва от няколко процеса едновременно но това също ти гарантира по голямо натоварване 😉 Баланса между натоварване и скорост винаги е много тънък. Всичко опира до тестове.

Пакінуць адказ

Ваш адрас электроннай пошты не будзе апублікаваны. Абавязковыя палі пазначаныя *

Анты-спам *