دوستان این مطلب از سایت پرشین نتورک هست
ولی کامل ترین چیزی هست که من دیدم کسی وقت گذاشته
اگه بعد از خواندن کسی مشکلی داشتین میتونم کمک کنم .
قبلا یکی از دوستان در تاپیک زیر توضیحاتی دادن ولی به کاملی و جامع بودن این مطلب نبود http://www.webhostingtalk.ir/f115/25431/
-----
دوستان عزیز سلام:
برای این منظور می خواستم چند مقاله را به صورت ترجمه شده باز نویسی کنم اما متاسفانه کمبود وقت و مشغولیت های فکری مانع شدند در ضمن گیرایی مطلب هم به حدی ست که حیفم اومد باز هم تعلل مانع شروع بشه....خلاصه سعی بر این شد که با ویرایش کلی و جفت کردن مطالب به هم به زبان انگلیسی ساده مطلبی رو ارائه کنم که امیدوارم با کمک اساتید اگر مشکلی یا ایرادی هم داشت رفع و اصلاح بشه.......
می خواهیم در این چکیده به نصب و پیکر بندی squid پرداخته و با اعمال محدودیت هایی بر پهنای باند آن را در کنترل داشته باشیم......
Installing and Configuring Necessary Software Here, I will explain how to install the necessary software so that we can limit and test the bandwidth usage..
1. Installing Squid with the delay pools feature Squid has a feature called delay pools, which allows us to control download bandwidth. Unfortunately, in most distributions, Squid is shipped without that feature.
So if you have Squid already installed, I must disappoint you -- you need to uninstall it and do it once again with delay pools enabled in the way I explain below.
To get maximum performance from our Squid *****, it's best to create a separate partition for its cache, called /cache/. Its size should be about 300 megabytes,( depending on our needs).
If you don't know how to make a separate partition, you can create the /cache/ directory on a main partition, but Squid performance can suffer a bit.
We add a safe 'squid' user useradd -d /cache/ -r -s /dev/null squid >/dev/null 2>&1 No one can log in as squid, including root
We download Squid sources from http://www.squid-cache.org
For example: squid : Optimising Web Delivery
We unpack everything to /var/tmp:
tar xzpf squid-2.5.STABLE10-src.tar.gz
We compile and install Squid (everthing is in one line) ./configure --prefix=/opt/squid --exec-prefix=/opt/squid --enable-delay-pools --enable-cache-digests --enable-poll --disable-ident-lookups --enable-truncate --enable-removal-policies
make all
make install
2. Configuring Squid to use the delay pools feature
Configure our squid.conf file (located under /opt/squid/etc/squid.conf):
squid.conf Every option in this file is very well documented in the original squid.conf file
The ports our Squid will listen on. http_port 8080 icp_port 3130 cgi-bins will not be cached. acl QUERY urlpath_regex cgi-bin \? no_cache deny QUERY Memory the Squid will use. Well, Squid will use far more than that. cache_mem 16 MB 250 means that Squid will use 250 megabytes of disk space. cache_dir ufs /cache 250 16 256
Places where Squid's logs will go to. cache_log /var/log/squid/cache.log cache_access_log /var/log/squid/access.log cache_store_log /var/log/squid/store.log cache_swap_log /var/log/squid/swap.log
How many times to rotate the logs before deleting them.
logfile_rotate 10
redirect_rewrites_host_header off
cache_replacement_policy GDSF
acl localnet src 192.168.1.0/255.255.255.0
acl localhost src 127.0.0.1/255.255.255.255
acl Safe_ports port 80 443 210 119 70 20 21 1025-65535
acl CONNECT method CONNECT
acl all src 0.0.0.0/0.0.0.0
http_access allow localnet
http_access allow localhost
http_access deny !Safe_ports
http_access deny CONNECT
http_access deny all
maximum_object_size 3000 KB
store_avg_object_size 50 KB
Set these if you want your ***** to work in a transparent way. Transparent ***** means you generally don't have to configure all your client's browsers, but have some drawbacks too. httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_***** on
httpd_accel_uses_host_header on
all our LAN users will be seen by external web servers as if they all used Mozilla on Linux.
anonymize_headers deny User-Agent
fake_user_agent Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6+) Gecko/20011122
To make our connection even faster, we put two lines similar to the ones below. They will point a parent ***** server our own Squid will use. Don't forget to change the server to the one that will be fastest for you! Measure pings, traceroutes and so on. Make sure that http and icp ports are correct.
Uncomment lines beginning with "cache_peer" if necessary. This is the ***** you are going to use for all connections...
cache_peer w3cache.icm.edu.pl parent 8080 3130 no-digest default
...except for the connections to addresses and IPs beginning with "!".
It's a good idea not to use a higher
cache_peer_domain w3cache.icm.edu.pl !.pl !7thguard.net !192.168.1.1
This is useful when we want to use the Cache Manager.
Copy cachemgr.cgi to cgi-bin of your www server.
You can reach it then via a web browser typing
the address http://your-web-server/cgi-bin/cachemgr.cgi
cache_mgr your@email
cachemgr_passwd secret_password all
This is a name of a user our Squid will work as.
cache_effective_user squid
cache_effective_group squid
log_icp_queries off
buffered_logs on
DELAY POOLS
This is the most important part for shaping incoming traffic with Squid
For detailed description see squid.conf file or docs at http://www.squid-cache.org.
We don't want to limit downloads on our local network.
acl magic_words1 url_regex -i 192.168
We want to limit downloads of these type of files
Put this all in one line
acl magic_words2 url_regex -i ftp .exe .mp3 .vqf .tar.gz .gz .rpm .zip .rar .avi .mpeg .mpe .mpg .qt .ram .rm .iso .raw .wav .mov
We don't block .html, .gif, .jpg and similar files, because they generally don't consume much bandwidth
We want to limit bandwidth during the day, and allow full bandwidth during the night
Caution! with the acl below your downloads are likely to break at 23:59. Read the FAQ in this bandwidth if you want to avoid it.
acl day time 09:00-23:59
We have two different delay_pools
View Squid documentation to get familiar
with delay_pools and delay_class.
delay_pools 2
First delay pool
We don't want to delay our local traffic.
There are three pool classes; here we will deal only with the second.
First delay class (1) of second type (2).
delay_class 1 2
1/-1 mean that there are no limits. delay_parameters 1 -1/-1 -1/-1
magic_words1: 192.168 we have set before
delay_access 1 allow magic_words1
Second delay pool.
we want to delay downloading files mentioned in magic_words2.
Second delay class (2) of second type (2).
delay_class 2 2
The numbers here are values in bytes;
we must remember that Squid doesn't consider start/stop bits
5000/150000 are values for the whole network
5000/120000 are values for the single IP
after downloaded files exceed about 150000 bytes,
(or even twice or three times as much)
they will continue to download at about 5000 bytes/s
delay_parameters 2 5000/150000 5000/120000
We have set day to 09:00-23:59 before.
delay_access 2 allow day
delay_access 2 deny !day
delay_access 2 allow magic_words2
OK, when we have configured everything, we must make sure everything under /opt/squid and /cache directories belongs to user 'squid'.
mkdir /var/log/squid/
chown squid:squid /var/log/squid/
chmod 770 /var/log/squid/
chown -R squid:squid /opt/squid/
chown -R squid:squid /cache/
Now everything is ready to run Squid. When we do it for the first time, we have to create its cache directories
/opt/squid/bin/squid -z
We run Squid and check if everything is working. A good tool to do that is IPTraf; you can find it on http://freshmeat.net. Make sure you have set the appropriate ***** in your web browsers (192.168.1.1, port 8080 in our example)
/opt/squid/bin/squid
If everything is working, we add /opt/squid/bin/squid line to the end of our initializing scripts. Usually,
it can be /etc/rc.d/rc.local.
Other helpful options in Squid may be /opt/squid/bin/squid -k reconfigure (it reconfigures Squid if we made any changes in its squid.conf file)
/opt/squid/bin/squid -help self-explanatory
You can also copy cachemgr.cgi to the cgi-bin directory of your WWW server, to make use of a useful Cache Manager.
3. Solving remaining problems
OK, we have installed Squid and configured it to use delay pools. I bet nobody wants to be restricted, especially our clever LAN users. They will likely try to avoid our limitations, just to download their favourite mp3s a little faster (and thus causing your headache).
I assume that you use IP-masquerade on your LAN so that your users could use IRC, ICQ, e-mail, etc. That's OK, but we must make sure that our LAN users will use our delay pooled Squid to access web pages and use ftp.
We can solve most of these problems by using ipchains (Linux 2.2.x kernels) or iptables (Linux 2.4.x kernels).
Linux 2.2.x kernels (ipchains) We must make sure that nobody will try to cheat and use a ***** server other than ours. Public proxies usually run on 3128 and 8080 ports:
/sbin/ipchains -A input -s 192.168.1.1/24 -d ! 192.168.1.1 3128 -p TCP -j REJECT
/sbin/ipchains -A input -s 192.168.1.1/24 -d ! 192.168.1.1 8080 -p TCP -j REJECT
We must also make sure that nobody will try to cheat and connect to the internet directly (IP-masquerade) to download web pages:
/sbin/ipchains -A input -s 192.168.1.1/24 -d ! 192.168.1.1 80 -p TCP -j REDIRECT 8080
If everything is working, we add these lines to the end of our initializing scripts. Usually, it can be /etc/rc.d/rc.local.
We might think to block ftp traffic (ports 20 and 21) to force our LAN users to use Squid, but it's not a good idea for at least two reasons:
Squid is a http ***** with ftp support, not a real ftp *****. It can download from ftp, it can also upload to some ftp, but it can't delete/change name of files on remote ftp servers.
When we block ports 20 and 21, we won't be able to delete/change name of files on remote ftp servers.
IE5.5 has a bug -- it doesn't use a ***** to retrieve the ftp directory. Instead it connects directly via IP-masquerade.
When we block ports 20 and 21, we won't be able to browse through ftp directories, using IE5.5.
So, we will block excessive ftp downloads using other methods. We will deal with it in chapter 4.
(2) Linux 2.4.x kernels (iptables) We must make sure that nobody will try to cheat and use a ***** server other than ours. Public proxies usually run on 3128 and 8080 ports:
/sbin/iptables -A FORWARD -s 192.168.1.1/24 -d ! 192.168.1.1 --dport 3128 -p TCP -j DROP
/sbin/iptables -A FORWARD -s 192.168.1.1/24 -d ! 192.168.1.1 --dport 8080 -p TCP -j DROP
We must also make sure that nobody will try to cheat and connect to the internet directly (IP-masquerade) to download web pages:
/sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
If everything is working, we add these lines to the end of our initializing scripts. Usually, it can be /etc/rc.d/rc.local.
We might think to block ftp traffic (ports 20 and 21) to force our LAN users to use Squid, but it's not a good idea for at least two reasons:
Squid is a http ***** with ftp support, not a real ftp *****. It can download from ftp, it can also upload to some ftp, but it can't delete/change name of files on remote ftp servers.
When we block ports 20 and 21, we won't be able to delete/change name of files on remote ftp servers.
IE5.5 has a bug -- it doesn't use a ***** to retrieve the ftp directory. Instead it connects directly via IP-masquerade.
When we block ports 20 and 21, our LAN users won't be able to browse through ftp directories, using IE5.5.
So, we will block excessive ftp downloads using other methods
به امید خدا در ادامه به بهینه سازی و نصب ماژول برایwccp می پردازم.....
---------- Post added at 07:58 AM ---------- Previous post was at 07:57 AM ----------
دوستان عزیز خسته نباشید:
مواردی که مربوط به بهینه سازی و بالا رفتن کیفیت کار Squid می باشد رو امیدوارم با کمک هم دسته بندی کنیم تا مجموعه این تجربیات به صورت بهتری مورد استفاده قرار گیرد:
انتخاب سخت افزار مناسب برای یک Cache Server
در ابتدا باید بدونید که عمل Caching بر خلاف خیلی از کارهای دیگه در شبکه به Hardware حساس هست تا به Software . در حقیقت شما بهینه سازی هایی که با انتخاب درست یک Hardware می تونید بکنید خیلی بیشتر و موثرتر از بهینه سازی های نرم افزاری هستش . گویی که در Load بالا همین بهینه سازی های نرم افزاری می تونه باعث بشه به صورت خیلی محسوسی شما از همان Hardware ها به نحو احسن استفاده کنید ، اما انتخاب Hardware رکن اساسی هستش . پس خیلی در مورد خرید Hardware برای Cache Server تون دقت کنید . گاهی پول زیاد دادن و دستگاههای گران قیمت خریدن نه تنها باعث بهبود نمیشه ، بلکه گاهی مشکل ساز هم میشه . پس دقت کنید که در این مورد به خصوص گرونترین ها رو نرید تو بازار انتخاب کنید و با معیار های علمی که اشاره خواهم کرد قطعات مورد نیازتون رو خریداری و انتخاب کنید .
چهار عامل به طور کلی در انتخاب سخت افزارها مهم هستند :
1- زمان دسترسی تصادفی بر روی دیسک شما ( ترجمه ای بهتر برای Random Seek Time پیدا نکردم )
2- مقدار حافظه اصلی سیستم شما و سرعت دسترسی به آن ( RAM )
3- سرعت انتقال اطلاعات از دیسک شما به حافظه اصلی ( حالا نمی دونم چه واژه ای برای Throughput بهتره )
4- و در نهایت سرعت پردازنده شما ( CPU )
البته این عواملی که اشاره کردم مستقیما به Cache مربوط هستند . اما عواملی هم وجود دارند که به صورت غیر مستقیم مربوط هستند که هر کسی می تونه اونها را بنا به نیاز خودش پیدا کنه . مثلا در صورتیکه Cache Server در شبکه به عنوان یک عضو حیاتی محسوب میشه استفاده از Failure Redundancy برای خیلی از قطعات می تونه مشکل رو تا حدودی برطرف کنه . مثلا برای Power و یا خود دیسک . اما در حالت عادی اثر مستقیمی بر Cache Server ندارند .
ابتدا استخراج آمار
ببینید همیشه انتخاب شما وابسته به نیاز شماست . در صورتیکه شما در یک شبکه با تعداد درخواست پائین اما حجم تبادل اطلاعات بالا سر و کار دارید یک نوع انتخاب دارید اما در شبکه ای که تعداد درخواست زیاد اما هر کدام تبادل اطلاعات کمی دارند انتخاب متفاوتی دارید . پس ابتدا بشینید برای خودتون حساب کنید که در شلوغترین حالت ممکن شما چه تعداد درخواست در دقیقه خواهید داشت ؟ جواب این سئوال می تونه مشخص کنه که چه تعدادی object در یک دقیقه دریافت خواهد شد و در نهایت یه ایده ای در مورد ترافیک Cache Server به شما خواهد داد .
البته محاسبه بیشترین تعداد درخواست کار ساده ای نیست ، به خصوص اینکه شما هیچ ایده ای در مورد تعداد کاربرانتون و پهنای باند احتمالی که می خواهید بر روی آن کار کنید نداشته باشید . بنابراین شاید در این موارد بهترین کار این باشه که یه دستگاه بدرد نخور پیدا کنید و روش یه دفعه به صورت معمولی یه Cache Server نصب کنید و مقدار ترافیکتون رو توسط منتقل کردن ترافیک تعدادی از کاربرانتون برای مدتی بر روی این دستگاه تخمین بزنید .
دقت کنید در هنگام تخمین زدن از اعدادی که در شلوغترین حالت ممکن بدست می آورید استفاده کنید و از معدل استفاده نکنید . یعنی مثلا تعداد درخواستها در روز رو تقسیم بر 1440 کنید و بگید این مقدار ترافیکتون در دقیقه هستش ! این غلطه ! شما باید شلوغترین ساعتها رو پیدا کنید و بر اساس اونها مقدار تخمینی رو پیدا کنید .
انتخاب دیسک
خیلی موارد هستش که موقع انتخاب و خرید دیسک باید مد نظر قرار بدهید . قبلا در مقدمه اشاره کردیم که موارد مهم در انتخاب دیسک همانا زمان دسترسی تصادفی و سرعت انتقال اطلاعات از آن است . داشتن سریعترین دیسک دنیا همیشه بهترین انتخاب نیست چراکه ممکنه که حجم زیادی از اطلاعات رو نتونه در خودش جا بده . دیسک مناسب برای Cache دیسکی هستش که بتونه حجم معقولی از اطلاعات دریافت شده از Internet رو بر روی خودش قرار بده و در عین حال به اندازه ای سرعت داشته باشد که بر اساس تعداد درخواستهای شما در ثانیه سرعت Browsing شما رو کند نکنه .
مهمترین چیزی که باید در Document های دیسکتان به دنبال آن بگردید عددی است که مشخص کننده Random Seek Time هستش . هر چقدر مقدارش کمتر باشد بهتر است . این عدد مشخص کننده زمانی به میلی ثانیه هستش که هد دیسک اطلاعاتی رو از یک تراک تصادفی به تراکی دیگر منقل می کند . البته یک سیستم عامل قدرتمند همیشه بهترین روش ها رو برای انجام این کار در نظر میگیره و سعی می کنه که این زمان به حداقل برسونه ، اما بالاخره همیشه محدودیت سخت افزاری وجود داره و انتخاب دیسکی که زمان کمی را از این لحاظ داشته باشد می تواند خیلی به سرعت دار شدنCache Server شما کند . دقت کنید که انتظار CPU برای دیسک می تونه خیلی سرعت Cache Server شما رو کاهش بده .
( در آینده خواهم گفت که مثلا استفاده از سیستم عامل هایی که Posix Thread رو پشتیبانی می کنند واجرا کردن Cache به صورت asynchronous Input-Output و البته انتخاب فایل سیستم مناسب می تونه خیلی خوب از قابلیت های یک Hardware خوب برای سرعت بخشیدن به عمل Caching و پشتیبانی از تعداد بالا درخواست در ثانیه کمک کنه، اما فعلا مطمئن بشید که Hardware شما مناسب باشد )
یک Cache با یک دیسک در حالت عادی برای هر درخواست باید یکبار بر روی دیسک جستجو انجام دهد ( فرض کنید که RAM Caching برای دیسک وجود نداشته باشد و لیستی از Object ها نیز در حافظه اصلی نیست ) . در صورتیکه شما فقط یک دیسک دارید فرمولی که برای بدست آوردن تعداد درخواست در ثانیه هست به صورت زیر است :
زمان دسترسی تصادفی / 1000 = تعداد درخواست در ثانیه
البته Squid این قابلیت رو داراست که نوشتن بر روی دیسکها رو در صورت وجود بیش از یک دیسک برای Cache تعدیل کند . بنابراین زیاد کردن تعداد دیسکها باعث پائین آمدن زمان دسترسی تصادفی خواهد شد و در نتیجه بازدهی بهتری خواهید داشت . با اینکه در سیستم عامل های مختلف ممکن است این قضیه مقادیر مختلفی در بر داشته باشه ، اما اگر فرض کنیم شما از دیسکهایی استفاده می کنید که زمان دسترسی تصادفی یکسانی دارند می توانید از معادله زیر برای بدست آوردن تعداد درخواستهای قابل سرویس دهی در ثانیه به ازای تعداد دیسکهای خود استفاده کنید :
( تعداد دیسکها / زمان دسترسی تصادفی ) / 1000 = تعداد درخواست در ثانیه
مثلا اگر فرض کنیم 3 دیسک که هر کدام دارای 12 میلی ثانیه زمان دسترسی تصادفی می باشند برای Cache Server در نظر بگیریم بر اساس معادله بالا : (3/12)/1000 = 250 عدد درخواست در ثانیه را به خوبی می توانیم توسط این Cache Server جوابگو باشیم .
نکته دیگری رو که باید در اینجا اشاره کنیم در مورد انتخاب IDE و SCSI هستش . ببینید واقعش اینه که این روزا اینقدر IDE ها پیشرفت کرده اند که زمان دسترسی تصادفی مشابهی با SCSI ها پیدا کرده اند ( البته IDE هایی که از DMA-Compatible Controllers استفاده می کنند ) . بنابراین با تفاوت قیمت فاحشی که دارند برای کسانی که تعداد زیادی درخواست دارند و هر کدام سرعت کمی در انتفال اطلاعات دارند ( دقیقا چیزی که ISP ها به آن نیاز دارند ، یعنی تعداد درخواست بالا ، اما هر کدام بیش از 56 کیلوبیت در ثانیه امکان دریافت و ارسال اطلاعات ندارند ) استفاده از IDE های با زمان دسترسی تصادفی مناسب خیلی به صرفه تر هستش براشون . البته کسانی که از Object Size های بالا برای Caching استفاده می کنند ( یعنی Object های حجیم رو می خواهند Cache شود ) و کاربرانشان دسترسی های پر سرعت به شبکه دارند ( مانند کاربران یک شبکه محلی که Download های زیاد دارند ) استفاده از SCSI که دارای سرعت انتقال اطلاعات به مراتب بالاتری می باشد مناسبتر است .
در مورد حجم دیسک مربوط به Cache شما تصمیم گیری کمی مشکل است . ببینید برای چند نفر کاربر محدود که در یک شرکت هستند شاید در حد 100 مگابایت مقدار مناسبی باشد . ( در صورتیکه کارای عجیب غریبی نکنند و سرعت ارتباطی اونها معقول باشد مانند 64K ) . اما برای Production Use و یا استفاده از شبکه های با هدف خاص ( مانند ISP ها برای کابران Dial-up ) قضیه کمی پیچیده تر هستش . در حقیقت این مقدار بستگی به چندین فاکتور داره .
فرض کنید که شما می خواهید یک Cache Server برای خودتون توی خونه راه بندازید . اگر شما 1 گیگابایت فضا برای Cache Server خودتون اختصاص بدهید و به صورت متوسط 10 مگابایت اطلاعات را در روز Browse کنید ، حداقل 100 روز طول میکشه که Cache شما پر شود . بنابراین شاید خیلی زمان زیادی طول بکشد که واقعا Cache Server شما به HIT Rate واقعی برسد ( HIT Rate یعنی نسبت تعداد درخواستهایی که از Cache سرویس داده می شود نسبت به کل تعداد درخواستها ) . از اونطرف اگر مثلا اگر 10 مگابایت دیسک برای یک Cache Server اختصاص بدهید و مثلا 10 درخواست در ثانیه داشته باشد این Cache Server شما خواهید دید که Object هایی که در Cache شما می مانند برای چند ساعت هم نخواهند بود و این باعث می شود که عملا شما HIT Rate ای نداشته باشید . بنابراین برای اینکه مقدار واقعی و بدرد بخوری برای اندازه دیسک Cache خود پیدا کنید باید حدودا بدانید که چه مقدار اطلاعات از Cache Server عبور خواهد کرد در طول روز . در صورتیکه ایده ای از این مقدار ندارید می توانید پهنای باند خط ارتباطی خود به اینترنت رو ملاک قرار دهید . مثلا 1MB/Sec خط اینترنت ( سعی می کنم مثالهام رو منطبق با شرایط ISP ها مطرح کنم ، چون عملا بیشترین کاربرد Cache Server برای ISP ها و برای End-User های هستش ) در حدود 125000 بایت اطلاعات را می تواند در یک ثانیه منتقل کند . اگر همه کاربران این خط اینترنت قرار باشد از Cache Server استفاده کنند ، بنابراین دیسک این Cache Server در هر ثانیه 125K پر می شود که می کنه به عبارتی 450 مگابایت در هر ساعت . حالا اگر تمام ساعات شبانه روز این خط استفاده شود چیزی در حدود 3.6 گیگابایت اطلاعات را می تواند جابجا کند . چون معمولا همچین چیزی نیست که همه خط در طول شبانه روز 100% استفاده شود فرض می کنیم به طور متوسط 2 گیگابایت تبادل اطلاعات با Internet از طریق این Cache Server بشود . بنابراین شما دیسکی با حجم 2GB لازم دارید تا بتوانید اطلاعا ت یک روز به طور کامل نگهداری کنید . حالا در صورتیکه بسته به نظر شما می خواهید تعداد روزهای بیشتری رو نگهداری کنید می توانید این مقدار رو زیاد کنید . من فکر می کنم به طور متوسط نگهداری اطلاعات 1 هفته مقدار مناسبی است . بنابراین 14 گیگابایت مقدار مناسبی برای این حجم ترافیک خواهد بود . مهم اینه که شما ایده قضیه رو بگیرید و خودتون در اشل کاری خودتون پیاده کنید و با نیازهاتون مقدار مورد نیازتون رو پیدا کنید .
در ضمن Hit Rate بستگی به تعداد سایتهایی که کاربران شما مشترکا از آنها بازدید می کنند داره . اگر فکر می کنید که کاربران شما در زمینه خاصی از سایتهایی که دارای اطلاعات حجیم هستند مشغول به فعالیت هستند ، این عامل را هم در انتخاب حجم دیسک حتما دخیل کنید .
البته بعضی هم از RAID برای Cache Server های خودشون استفاده می کنند . این هم از روشهایی هستش که می تونه به طرز خارق العاده ای Performance شما را بالا ببره . البته دقت در انتخاب نوع RAID ای که استفاده می کنید مطمئنا مهمه . استفاده از RAID-0 می تونه سرعت کار شما به شدت بالا ببره ، چون در حقیقت همان زمان دسترسی تصادفی رو کاهش میده ، اما در صورتیکه Stability برای شما مهمتره می تونید از RAID-5 استفاده کنید که در صورت ایراد در یکی از دیسک ها بقیه وظیفه اش رو جبران کنند و ضرری به کاربران نرسد .
در نهایت به شخصه به این تجربه دست پیدا کرده ام که استفاده از تعداد زیادتری دیسک معمولی و کم ظرفیت که زمان دسترسی تصادفی خوبی دارند ، بهترین انتخاب هستش و خرج کمتری هم نسبت به روش های نوین مانند RAID و دیسکهای پرسرعت و گرون قیمت داره .
انتخاب حافظه اصلی ( RAM )
Squid یک جدول از لیست Object هایی که بر روی دیسک داره بر روی حافظه اصلی نگهداری می کنه . به این دلیل که این لیست به ازای هر درخواست باید جستجو روش انجام بشه باید دسترسی سریعی بهش وجود داشته باشه و اصلا به همین خاطر هستش که همه اش در حافظه اصلی قرار دارد . بنابراین باید مقدار حافظه اصلی رو طوری انتخاب کنید که سیستم عامل به دلیل حجیم بودن این جدول و کم بودن حافظه اصلی مجبور نشود مقداری از آن را داخل حافظه مجازی در Swap قرار دهد . این کار باعث می شود که سرعت جستجو در این جدول به شدت کاهش یابد و در نهایت تعداد درخواست کمتری را در ثانیه قادر به پاسخگویی باشید .
هر کدام از Object هایی که بر روی دیسک قرار دارند در حدود 75 بایت فضا در حافظه اصلی درون این جدول را اشغال می کنند . بنابراین در صورتیکه شما 8 گیگابایت دیسک برای Caching داشته باشید چیزی در حدود 48 مگابایت RAM برای نگهداری اطلاعات این جدول لازم است که باید مقدار حافظه ای که برای بار شدن سیستم عامل و برنامه های دیگر راه انداز لازم است را نیز به آن اضافه کنید .
در ضمن انتخاب نوع حافظه اصلی نیز می تونه تعیین کننده باشه . مثلا استفاده از RAM های DDR که سرعت انتفال خیلی بیشتری را دارا هستند می تواند خیلی کمک کند که جستجو درون جدول سریع شود و در نهایت تعداد زیادتری درخواست رو سرویس دهی کند .
انتخاب CPU
کلا Squid و عمل Caching خیلی به CPU حساس نیستند . ممکنه در ابتدا که Squid بالا می آید و می خواهد همان لیست کذایی رو در حافظه اصلی ایجاد کند Process سنگینی انجام دهد ، اما این نهایتا مال چند دقیقه خواهد بود و بعد از آن CPU همیشه منتظر IO خواهد بود . بنابراین اصولا خیلی Load بالایی برای CPU نخواهید داشت . مثلا یک Pentium 133 می تونه خیلی راحت چیزی در حدود 7 درخواست در ثانیه رو بدون هیچ مشکلی سرویس دهی کند . بنابراین پول زیادی برای تهیه CPU های پرسرعت و گران قیمت برای Cache Server ندهید و به CPU هایی که معمول بازار هستند و قیمت مناسبتری دارند اکتفا کنید . مثلا در این زمینه AMD فکر می کنم قیمت های مناسبتری نسبت به Intel داره .
در ضمن استفاده از Motherboard های که قابلیت استفاده از چند CPU همزمان را دارا هستند هم طبیعتا کمک شایانی نمی کند . چرا که SMP و استفاده از چند CPU موقعی به درد می خوره که شما Load بالایی داشته باشید و تعداد Task های زیادی هم داشته باشید . در اینجا شما اصل کارتون توسط یک Task مربوط به Squid انجام می شود و همان هم چندان کار CPU ای زیادی ندارد . گویی که استفاده از Async-IO که بعدا توضیح می دهم تعداد زیادی thread را ایجاد خواهد کرد ، اما Load آنها هم آنچنان زیاد نیست که بخواهید از چندین CPU استفاده کنید. ( نوشته آقای هاشمی وبلاگایران اتسول )
با توجه به این توضیحات قشنگ فکر کنم که مشکلی از لحاظ انتخاب سخت افزار باقی نمونده باشه ....
---------- Post added at 08:00 AM ---------- Previous post was at 07:58 AM ----------
اگر بخواهیم از خواص Ultra Direct Memory Access و UDMA66 استفاده نماییم لازم است که دوباره کرنل توزیع لینوکسی که در اختیار داریم کامپایل کنیم و در این مورد می توانیم از اینجا اطلاعات لازم رو پیدا کنیم....و بسته به کرنلی که استفاده می نماییم می توانیم جدید ترین Patch را برای فعال کردن این قابلیت پیدا کنیم ...مثلا برای کرنل 2.2می توان از این Patch استفاده کرد...
که همین patch به سادگی به تایپ این دستوردر /usr/src/linux به کرنل اضافه می گردد:
patch -p1 < ../ide.2.2.14.20000124.patchبا اتمام این کار هارد ما برای فورم دهی و کار آماده است....
حال برای اینکه سریعترین و بالاترین کیفیت را در حفظ و باز خوانی اطلاعات داشته باشیم از سیستم فایل ReiserFS برای دایرکتوری کش استفاده می نماییم با این کار Performence کش سرور ما تا 20% بالا می رود...
در مورد سیستم فایل روزنامه ای (Journallling ReiserFS) می توانیم اطلاعات مفیدی را از اینجا بدست آوریم...
بعد از اضافه کردن ماژول ReiserFS به کرنل توزیع لینوکسیمان و ارتقا سیستم فایل دایرکتوری کش ازext2 یا ext3 به این سیستم فایل و mount کردن آن می توانیم از آن استفاده نماییم جهت آشنایی بیشتر با این کار این لینک ها را مشاهده فرمایید:
http://www.namesys.com/benchmarks.htmlچکیده ای از عمل کامپایل کردن چنین است:
BULMA: Ext2, ReiserFS and XFS Benchmarks
http://www.quest-pipelines.com/newsletter-v2/linux2.htm
Configuration
There are a few configuration details in the kernel you will need to change to make use of the new patches we've applied. Further, there are a few changes one can make to improve the performance of the Kernel for use in a server.
Here is a list of the important items to alter, you'll also need to turn on whichever UDMA chipset or SCSI controller you have:
CONFIG_EXPERIMENTAL=y
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y
CONFIG_NET=y
CONFIG_PCI=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDMA_AUTO=y
CONFIG_IDEDMA_PCI_EXPERIENTAL=y
CONFIG_PACKET=y
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
CONFIG_FIREWALL=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_FIREWALL=y
CONFIG_IP_ROUTER=y
CONFIG_IP_ALIAS=y
CONFIG_REISERFS_FS=y
CONFIG_YRH_HASH=y
This isn't a complete kernel config, obviously. You will also need network hardware drivers and will need to make a few other decisions when deciding what the box will need to do. I've already included in this list all that is needed for a transparent ***** if that is the route you plan to take. A couple of these options could use some explanation.
CONFIG_REISERFS_FS - This one turns on the newly patched in ReiserFS.
CONFIG_YRH_HASH - This chooses the Yuri Rupasov Hash option in ReiserFS.
It is a slightly more effective hash type for squid. Now simply compile and install your new kernel, run lilo, and reboot. After rebooting, you can build the ReiserFS tools found in the /usr/src/linux/fs/reiserfs/utils directory. Type the following:
mkdir bin; make; make install
Now you can convert your squid directories to ReiserFS like so (X is your planned cache partition):
/sbin/mkreiserfs /dev/hdaX
Add the following line to your /etc/fstab:
/dev/hdaX /cache reiserfs notail,noatime 0 0
You can then mount you're new cache directory:
mount /cache
Note: The notail option above tells ReiserFS not to pack tails, which is a way for the FS to save file space. Since we need speed much more than a few megabytes of saved space, we'll disable it. And the noatime option should be used regardless of what filesystem you use, for a web cache. It disables access time updates on files, saving one write for every read
---------- Post added at 08:05 AM ---------- Previous post was at 08:00 AM ----------
برای اینکه کش سرور ما به صورت اتوماتیک بعد از بالا آمدن درخواست را سرو کند به طریق ذیل عمل می کنیم:
1- اگر Squid را از روی RPM آن بر روی سیتم نصب کردیم با این دستور:
کد:
2_اگر squid را از روی Source کد های آن نصب کردیم لازم است که از این اسکریپت را بهetc/rc.d/init.d/squidاضافه می کنیم:کد:# chkconfig --level 3 squid on
کد:
و در پایان لینک های سمبولیک را میسازیم:کد:# touch /etc/rc.d/init.d/squid # vi /etc/rc.d/init.d/squid # chmod +x /etc/rc.d/init.d/squidکد PHP:
#!/bin/shSQUID=/usr/local/squid/bin/squidcase "$1" in'start') if [ -x "$SQUID" ]; then echo "Squid caching web ***** server starting." $SQUID fi ;;'stop') if [ -x "$SQUID" ]; then $SQUID -k shutdown fi ;;*) echo "usage: $0 start|stop" exit 1 ;;esac
کد:
#کد:ln -s /etc/init.d/squid /etc/rc3.d/S90squid # ln -s /etc/init.d/squid /etc/rc2.d/K90squid موفق باشید.