Търся: Системен администратор на сървър

stuklen каза:
Хайде и аз да се намеся, че много станаха знайни и незнайни разбирачи.
Тука някакви изказвания за неизползвани скриптове и нескопосани мнения. Като имате нещо да кажете говорете конкретно.
Да добавя още нещо това не е блог със 100 поста, за да зависи бързината на зареждане от домашния ви компютър.
Относно кеширането говорим за динамични страници. Ефект би имал при голям трафик, а тук става въпрос за бързо търсене в таблица с много данни.

Ето ви един пример. Всеки може да си го направи.
Таблица с 3 текстови колони с 1 милион записа, търсене на думи в 3-те колони и подредба по коефициент от тип double.

P.S. Пуснете ми вашите бързи сайтове да ги разгледам. Нека бъде на ЛС.
Увеличете...
Бачо стъклен, това че отричаш кеша директно те праща във Б група.
Както казах и на колегата тия каталози ги плющим на WP щот всичко става за няколко часа.
Има действащи такива с амен, че ако не и повече записи и не минават 2 секунди никъде. Та представи си зареждаме ги с хиляди на върху картата...
 
Искрено се надявам да не се изнервяме и обиждаме. В спора се ражда истината, но не и в скандала. По-добре е да си помагаме, когато можем.

ПП. Лошото е, че аз самия мога да помагам само по въпроси за дърводелство...
 
Дай да видим тея WP и на какви сървъри е. Знаем, че всички на приказки са силни.
И не отричам кеша, а казвам че е полезно кеширането при наличие на трафик.
 
Това с WP е ясно. И аз имам един базиран на WP сайт на двуядрен KVM с 4ГБ РАМ, който е 12К в Алекса, а базата данни нямам идея колко е голяма вече, защото така съм го направил, че собственика повече от нищо не е имал нужда, но е огромна.
Има ли възможност динамичната част от странците да се махне, която и да е тя, и да кеширате всичко за постоянно, след което да обходите сайта за да се напълни кеша и после от там нататък да обхождате само новите добавени фирми или тези, по които правите промени? Т.е. посетителите да виждат винаги само кеш?
Може с Varnish, ама ще трябва да се кешира на диска, вместо в паметта, за да остане при евентуален рестарт на сървъра. Или Nginx директно на диск с fast cgi?

ПС. При Varnish ще трябва и HTTPS прокси като Hitch (което иначе е адски бързо и добро), така че вероятно Nginx e по-лесното решение
 
Последно редактирано:
stuklen каза:
Дай да видим тея WP и на какви сървъри е. Знаем, че всички на приказки са силни.
И не отричам кеша, а казвам че е полезно кеширането при наличие на трафик.
Увеличете...
Шог, единия е със сигурност във Суперхостинг на споделения.
 
stuklen каза:
Хайде и аз да се намеся, че много станаха знайни и незнайни разбирачи.
Тука някакви изказвания за неизползвани скриптове и нескопосани мнения. Като имате нещо да кажете говорете конкретно.
Да добавя още нещо това не е блог със 100 поста, за да зависи бързината на зареждане от домашния ви компютър.
Относно кеширането говорим за динамични страници. Ефект би имал при голям трафик, а тук става въпрос за бързо търсене в таблица с много данни.

Ето ви един пример. Всеки може да си го направи.
Таблица с 3 текстови колони с 1 милион записа, търсене на думи в 3-те колони и подредба по коефициент от тип double.

P.S. Пуснете ми вашите бързи сайтове да ги разгледам. Нека бъде на ЛС.
Увеличете...
Партишънинг не може ли да се измисли на тия таблички?
 
Партишънинг по град смятам, че ще се справи. Да разбие фирмите по градове. Телефоните също могат да се разделят по код на населеното място. Е вярно, че София ще има най-много фирми, но няма да са 1кк :). Каква е базата mysql/maria или postgres? Ако си на mysql то таблиците е хубаво да са майисам, че инодб е бавничко.
 
stuklen каза:
Относно кеширането говорим за динамични страници. Ефект би имал при голям трафик, а тук става въпрос за бързо търсене в таблица с много данни.
Ето ви един пример. Всеки може да си го направи.
Таблица с 3 текстови колони с 1 милион записа, търсене на думи в 3-те колони и подредба по коефициент от тип double.
Увеличете...

Каква база данни ползва сайта? Това е първия въпрос от които можем да тръгнем.
За кеширането, memcached пробва ли? Точно при този тип търсене ще помогне.
 
hristonev каза:
Партишънинг по град смятам, че ще се справи. Да разбие фирмите по градове. Телефоните също могат да се разделят по код на населеното място. Е вярно, че София ще има най-много фирми, но няма да са 1кк :). Каква е базата mysql/maria или postgres? Ако си на mysql то таблиците е хубаво да са майисам, че инодб е бавничко.
Увеличете...
Това добре трябва да се помисли. Най-малкото разделянето на дялове е възможно само с InnoDB тип. InnoDB е бавно при insert/update. Селекта не е чак толкова бавен, че да се лишаваме от благините, които предлага. Най-вече заради заключването на таблицата при INSERT/UPDATE. При InnoDB това е на ниво запис (row), докато при MyISAM се заключва цалата таблица и другите чакат на опашка докато приключи заявката. INSERT/UPDATE LOW_PRIORITY ще изпълни с приоритет SELECT-a в този случай.
Според мен.
- опитай се да прецизираш полетата в таблицата с данните. При много на брой записи всеки килобайт е важен :)
- сортирнае по double, rand() ако може да се избягва. Първото може да го представиш като число без знак умножено по 100 примерно (преди да го запишешв базата)
- за кеширането писаха хората
- обноване на запис - само при нужда, импорт, крон задачи етц - по-добре направи няколко селекта в повече за да проверих дали има промяна от колкото да направиш обновяване без нужда.
- ако имаш статистика на прегледи - извади я от основната таблица. Или намери някакъв варинат да не се локват таблиците докато правиш ъпдейта. може някакъв масив в споделена памет, който на определено време да обновява данните. Въпросът е да се намалат insert/update заявките.
- внимавай със сеченията (JOIN). Удобное да джойнеш примерно таблицата с градове, категории, дейности и записите но това вътрешно за СУБД е разносилно на временна таблица с брой редове равна на произведението от броя редове на всички таблици участващи в заявката. Категориите и градовете рядко се променят, така че за тях кеша е 100% оправдан. След това програмно си ги "мапваш" към променливите за град, категория етц.
- ако имаш големи таблици, които не са пряко свързани с проекта - разкарай ги. Заемат само памет. Индекситена таблиците (би трябвало) да са в паметта.
- добре помисли, кое трябва да е индекс и кое не. В някои случаи повече индекси забавят работата. Естествено и обратното е вярно. Когхато имаш големи индексни таблици търсенето в тях е бавно.
Ами сигурно мога да напиша още много неща, но толкова време имам. Стъпка по-стъпка ще го оправиш. Естествено провери данеби забаването да идва от скипта. Сложи си точни на които да имериш времето, примерно преди заявката, след заявката, след като се изведат данните. Сравни времената и ще намериш слабото мяасто. Принципно ваденето от базата би трябвало да е най-бавната операция. Ако времето за обработка в скрипта е съизмеримо с това от базата - има проблем и със самият скрипт.
Ако ползваш някакъв ORM, QueryBuilder или тем подобна простотия виж далии RAW заявки нама да са по-удачни.

Поздрави.
 
Точно това което е описано по-горе е направено.
При прецизиране по населено място работи бързо. Кеширането е по ключова фраза и град.
Проследени са времената на заявки и изпълнение на скрипт.
Има си всички необходими индекси. Базата е MySql таблиците InnoDB. Мисля, че за няколко мили секунди бързодействие MyISAM не си струва.
Въпроса е, че се извършва търсене в текстови полета и то с лайк. За по-бърз начин не се сещам.
 
Аз скоро не съм правил сравнение инодб-майисам, но от преди 10г майисама не беше само милисекунди по-бърз. Пусни базата, ако не е тайна да ударим малко тестове, че така само боб хвърляме :).

ПП майисама си има фул-текст търсене. Инодб за мен не е добро решение. Постгрес или исамка.
 
Трябва да си влезнал или регистриран, за да отговориш тук.

Горе