Архив

Статии по ключова дума: ‘B1’

Защо да ползваме летни гуми за лятото и зимни за зимата

5 ноември, 2009 Няма коментари

Над този въпрос размишлявахме с един приятел и реших да потърся за повече детайлна информация.  Ето какво открих:

Защо слагаме зимни гуми?

За сигурно шофиране през зимата е необходимо оптимално сцепление. Благодарение на специалния си дизайн с множество ламели, зимните гуми имат много по-голяма контактна площ с пътя, което гарантира по-добра устойчивост и по-къс спирачен път.

При движение на сняг със скорост от 50 км/ч автомобил, "обут" с четири зимни гуми, има спирачен път от 35 метра, докато този с летни гуми спира за 43 метра.
При заледен път и скорост от само 30 км/ч разликата е още по-голяма. Зимните гуми спират за 57 метра, а летните за цели 68 метра.

Много често метрите, спечелени от зимните гуми, предотвратяват сериозни произшествия и спасяват човешки животи. Кои са истинските зимни гуми? На пазара се предлагат т. нар. "всесезонни" гуми. Според производителите им са подходящи за употреба през цялата година -- при пролетния дъжд, при лятната жега, при есената слана и зимния лед. Това не е нищо друго освен маркетингов трик, който обаче често струва скъпо на клиента. И докато през лятото свойствата на тези гуми са задоволителни, при зимни условия употребата им е компромис със сигурността.

zimen_znakПрез 1999 г. в САЩ и Канада бе приет нов стандарт за зимни гуми, който вече е световно признат. Зимните гуми, одобрени по строгите изисквания на този стандарт, гарантират на клиентите най-високите възможни нива на устойчивост и сцепление с пътя при сурови зимни условия и са маркирани със специален знак: снежинка на фона на планина.

Защо силика?

Най-новата технология в производството на зимни гуми е използването в каучуковата смес на силициев двуокис SiO2, химическо съединение известно под името силика. При температури под 7 градуса Целзий, обикновената каучукова смес на летните и всесезонни гуми губи еластичността си и не може да осъществи добро сцепление с пътя дори при сухи условия. Чрез прибавянето на силика се запазва еластичността на каучуковата смес при минусови температури и се постига маскимално сцепление при сняг и лед. Така например, новите зимни гуми със силика Lassa Snoways Era, производство на Bridgestone Sabanci имат 15% по-добро сцепление на сняг в сравнение с предходния модел на фирмата, което води и до значително подобрение на спирачния път при зимни условия. …

За да прочетете цялата статия, моля натиснете тук: автогуми.ком

Конструкции на SQL за поддръжка на таблици в MySQL

14 октомври, 2009 Няма коментари

MySQL притежава няколко конструкции на SQL за поддръжка на таблици: CHECK TABLE за проверка на целостта им, REPAIR TABLE за извършване на поправка, ANALYZE TABLE за анализ и OPTIMIZE TABLE за оптимизиране.  Следва малко информация за всяка от конструкциите за поддръжка на таблици в MySQL:

CHECK TABLE

Конструкцията CHECK TABLE извършва проверка за целостта на структурата и съдържанието на съответната таблица. Тя е приложима и за MyISAM, и за InnoDB. За таблиците от тип MyISAM се осъществява също и актуализиране на статистиката на индексите. Ако дадената таблица с изглед, с CHECK TABLE се проверява дефиницията му. Ако данните, изведени от CHECK TABLE показват наличие на проблем с таблицата, тя трябва да бъде поправена.

REPAIR TABLE

Конструкцията REPAIR TABLE служи за коригиране на проблеми в таблица, която е повредена. Тя е приложима само за таблици от тип MyISAM. Можете да конфигурирате автоматична поправка на таблиците на MyISAM.

Пример: repair table dhstudio

ANALYZE TABLE

Конструкцията ANALYZE TABLE служи за актуализиране на таблица с информация за разпределението на ключовите стойности в нея. Тя се използва от оптимизатора за избор на по- подходящи планове за изпълнението на заявки. Тази конструкция работи с таблици на MyISAM и InnoDB.

Пример: analyze table dhstudio

OPTIMIZE TABLE

Конструкцията OPTIMIZE TABLE служи за "изчистване" на таблици от тип MyISAM чрез дефрагментирането им. Резултатът е повторното разпределяне на неизползваното пространство, получено в резултат от изтриване и актуализации, както и обединяване на записите, които са били разделени и съхранени разпокъсано. OPTIMIZE TABLE се използва също така за сортиране на индексните страници, ако не са подредени, както и за актуализиране на статистиката за индексите.
OPTIMIZE TABLE работи и с таблици на InnoDB, но ги пренасочва към конструкцията ALTER TABLE, която ги изгражда наново. По този начин се актуализира статистиката за индексите и се освобождава място в клъстерния индекс.

Пример:  optimize table dhstudio

Ако искате да разберете кои таблици трябва да оптимизирате изпълнете следното:

show table status where Data_free!=0;

По този начин ще фрагментирате таблиците които се нуждаят от това, а не тези които са фрагментирани.

GLOBUL предлага предплатени пакети за мобилен интернет

25 юли, 2009 Няма коментари

globul_logoСофия, 12 февруари 2009 г. – От 15 февруари, GLOBUL предлага предплатени стартови пакети за мобилен интернет. Потребителите, които предпочитат да ползват мобилен интернет от GLOBUL без да подписват абонаментен договор, могат да изберат най-подходящото от двете предложения на оператора.

Първото предложение включва GLOBUL 3G Connect Center с USB-модем ZTE MF 626 и SIM-карта с включени 2 GB трафик, валидни за период от 31 дни, на пакетната цена от 99,90 лв. За потребителите, които вече имат USB или PCMCIA модем е второто предложение на оператора, което включва SIM-карта за достъп до интернет през мрежата на GLOBUL с пакет GoWeb 1 GB, с период на валидност 31 дни, на цена от 29,90 лв.

След изчерпването на включените MB трафик, абонатите имат възможност да презаредят своя предплатен пакет с пакет за презареждане GLOBUL GoWeb 512MB или GoWeb 1GB, като могат сами да избeрат периодa на активност на новия пакет. Пакетът за презареждане GoWeb 512MB струва 19,90 лв. при период на валидност 31 дни или 29,90 лв. при период на валидност 93 дни. Пакетът за презареждане GoWeb 1GB е на цена от 29,90 лв. при срок на валидност от 31 дни или 39,90 лв. за срок от 93 дни.

За презареждането е необходимо потребителят да има съответната сума като наличност в SIM-картата. Кредитът на картата може да се презареди чрез ваучери за предплатената услуга b-connect или чрез услугата CASH REFRESH, чрез плащане през банкомат, банков превод или чрез останалите начини за презареждане на предплатени карти.

За активиране на нов предплатен пакет за мобилен интернет, потребителят изпраща безплатен SMS до номер 125 с кода на избрания пакет за презареждане. За пакет GLOBUL GoWeb 512MB с валидност 31 дни, кодът е GA51, за пакет GLOBUL GoWeb 512MB с валидност 93 дни, кодът е GA53. за предплатен пакет GLOBUL GoWeb 1GB със срок на валидност 31 дни, кодът е GA101, a за пакет GoWeb 1GB с валидност от 93 дни, кодът е GA103.

Всяко добавяне на предплатен пакет GoWeb към удължава срока на наличния, а остатъкът от неизползвани MB се натрупва. Абонатът може по всяко време да провери оставащите MB трафик и валидност от закупения пакет с SMS с текст “GC” до номер 125.

Подробна информация за пакетите и начините за презареждане на предплатени пакети за мобилен интернет от GLOBUL е публикувана на официалната интернет страница на компанията www.globul.bg, телефон 123 и търговската мрежа на GLOBUL и партньорите на компанията.

Оптимизиране на mysql таблицата на kakvo.org

6 януари, 2009 4 коментари

Вчера посещенията на kakvo.org  надхвърлиха 11 000 и машината клекна. Клекна до толкова, че mysqld и apache2 заеха 100% и дори не можеш да се логнеш в машината нормално, а след известно време(20 сек.). За целта първата и най- основна част от решаването на този проблем е оптимизирането на mysql и apache2. След няколко огледа и мъки в натоварената машина забелязах, че полетата за "превод от" и "превод на" са тип "text" и не са индекси. В този случай когато се търси конкретен превод със заявка "… where превод от='търсен превод' " отнема 1.2 сек. и сериозно натоварва машината. Мислех 100 часа :P и реших да добавя едно поле "превод_md5" char(32) в което да пиша md5 на "превод от" и което ще бъде index. По този начин когато се търси превод не се изпълнява старата заявка където се търси самият превод, а новата в която се търси md5 на превода. Благодарение на уникалните и индексирани md5 хешове на таблицата, заявките се оптимизираха до заветните 00.00 сек. за изпълнение, а употребата на MySQL падна до 10%. Сега машината е във война с племето на Apache, но пък за сметка на това е в съюз със ордена на MySQL. Започвам да мисля още 100 часа как да подобря дипломатическите отношения на машината с племето на Apache.