Въпроси за бързодействие, оптимизация и изчистване на кода

Pavkatar

Registered
Здравейте, преди време бях писал в За нас/Въпроси/Препоръки/ да направим една тема подобна на Въпроси за сигурността:примери, начини на защита, само че за бързодействие на скриптове, приложения и т.н.

Идеята на темата е да се коментират начини за подобряването на скоростта на приложенията: замяна на функции, подобряване на алгоритми, използване на кеширания, смаляване на js,css файлове и т.н. :)

П.С. Лично аз мисля, че хората които са задълбочили в изучаването на езика (лично аз говоря за PHP, но може и др) или просто в "програмирането" като цяло би им било интересно :)

П.С.2 Ще помоля админите, ако преценят да направят темата "Важна" :)
 
Ами в днешно време оптимизацията е толкова важна колкото и дизайн на сайта. Аз също съм на мнение ,че е добре да има такава тема :) Като веднага мога да посоча някой неща с цел бързодействие на сайта

1. Да има един цсс файл, а не на различните страници да се добавят или махат
2. Всички javascript файлове да се викат последни преди тага </body> и колкото е възмощно по-малко на брой да се, дори ако трябва да е един.
3.Да се използват 'спрайтове' за картинките на сайта - колкото по-малко рекуести има за картинки толкова по-добре
 
http://24ways.org/2010/speed-up-your-site-with-delayed-content
Много интересно четиво е това. Можете да се разровите из сайта, има и други интересни неща :lol: ... това е за JS
За PHP .. ами освен да се избягва ползването на цикли и т.н. може също и където е възможно да се ползват единични кавички, а не двойни.
 
Идея как се заменя в заявка LIMIT число,число
с LIMIT число
и съответно да си имаш странициране...
Някой?
 
Най-важното е да не се реже от функционалността за сметка на бързодействие. Разбира се, когато може да се направи нещо по два начина трябва да се избере по-ефективния. И такива неща като кои били по-бързите кавички е меко казано тъпо да се съобразявате с тях. Дали ще спечелиш 10ms при 10000 потребители не е от значение. Една картинка от 10kb ще забави повече зареждането отколкото "бавните кавички" ако ги ползваш навсякъде.
 
MontefuckeR каза:
Идея как се заменя в заявка LIMIT число,число
с LIMIT число
и съответно да си имаш странициране...
Някой?
Лекооооо, като се замислиш това няма да как да стане като орежеш заявката си ... единственото, което би било от полза са индексите на полетата. Тоест, можеш да избегнеш лимита на MySQL, но после трябва да го обработваш с php, което ... си е къде, къде по-бавно ...
Би ли показал тая статия в която се обяснява да избягваме лимита в MySQL :?:
 
Replace каза:
MontefuckeR каза:
Идея как се заменя в заявка LIMIT число,число
с LIMIT число
и съответно да си имаш странициране...
Някой?
Лекооооо, като се замислиш това няма да как да стане като орежеш заявката си ... единственото, което би било от полза са индексите на полетата. Тоест, можеш да избегнеш лимита на MySQL, но после трябва да го обработваш с php, което ... си е къде, къде по-бавно ...
Би ли показал тая статия в която се обяснява да избягваме лимита в MySQL :?:

http://www.scribd.com/doc/14683263/Efficient-Pagination-Using-MySQL

При тест наистина скоростта е доста по-голяма, но не намерих начин как да си направя страницирането, от СХ ми го препоръчаха...
 
Защото няма. Не може хем толкова бързодействие, хем функционалност. И какво те бърка това, че е по-бавно? Хайде да няма странициране за да работи по-бързо?
 
ами това, че в таблицата има 500к записа, и при изкарване от типа на LIMIT 50000,50 заявката става бавна и влиза в Slow query Лог-а, говоря за заявка от типа:
SELECT field,field2,field3 FROM table ORDER BY field DESC LIMIT N,N
Не може да отпадне ORDER BY, защото става безполезна...
Най-бързо работи ако е LIMIT N, но уви така и не успях да намеря начин, никой ли не е работил с по-големи таблици и с изкарване на информация с подобни заявки като по-горната?
 
И какво, сайта ти става бавен? Ами ъпгрейтни си сървъра. Защото това, което искаш е да изкараш от 500 до 550 запис без да знаеш кои са тези до 500 и как ще се сортират. Не ми се струва реално, а на теб? Единственото, което можеш да направиш е да си оптимизираш индексите.
 
ами започва да се натоварва процесора, тъй като се натрупват много бавни заявки и сокетите се изпълват, как можеш да оптимизираш индексите? :roll: от СХ ми препоръчаха този метод, който ви дадох линк ...
 
Ами сложи индекс на полето, по което сортираш, сортирането го направи DESC, ако имаш WHERE клауза също е най-добре да е на полето, по което сортираш
 
StormBreaker каза:
Ами сложи индекс на полето, по което сортираш, сортирането го направи DESC, ако имаш WHERE клауза също е най-добре да е на полето, по което сортираш
Ами има индекси, но от експлайна показва, че не ги използва, пробвах с FORCE INDEX и USE INDEX(мисля, че така беше), но пак не искаше да използва индекс... :shock:
 
Когато в WHERE клаузата ползваш поле с индекс, то той наистина не се използва от SQL-а :?:
 
Ами щом смяташ, че имаш индекси по тия полета ... предполагам от към перформънс, само това може да измъкнеш :oops:
 
Еми ... няма как да оптимизираш повече заявката. По-добре попитай направо тия от СХ да ти предложат начин, а после (ако желаеш разбира се, може да ни просветлиш и нас).
Специално, за таблици с много записи - няма как да не ти влезе в Slow Query Log-a, именно защото са много записи. Затова се ползват (или поне ние ползваме) месечни таблици, и така куеритата (ест. ако не тръгнеш да правиш справки за 2 години назад) стават доста по-оптимизирани.
 

Back
Горе