Case study: tối ưu không cần thiết

English | Vietnamese

Rules

Main Forum

Portal

Member Listing

Statistics

Search

Reading Room
[Register]

Login [ | https ]

Forum Index

Thảo luận việc định hướng

Case study: tối ưu không cần thiết

[Discussion] Case study: tối ưu không cần thiết	13/08/2010 09:47:26 (+0700) \| #1 \| 218269

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

Hôm nọ, tôi nghe hai kỹ sư điện toán kháo chuyện nhau và dẫn đến chỗ cãi nhau khá kịch liệt.

Một bên thì cho rằng tài nguyên máy thời nay thừa thãi, muốn hiệu suất hơn thì chỉ cần thảy thêm RAM, CPU là xong. Tính ra giá thành, chi phí những cái này còn rẻ hơn mướn người ngồi đó mà táy máy chuyện tối ưu, phí thời gian, phí tiền bạc. Một bên thì cho rằng đây là thái độ lười nhác và vô trách nhiệm bởi vì một hệ thống muốn đạt hiệu suất không chỉ ném tài nguyên vào nó mà phải theo dõi, điều chỉnh và kiện toàn. Đây chính là công việc tối ưu cần thiết mà engineer nào cũng phải cần làm. Chuyện tốn kém không thể nói bừa mà phải chiết tính kỹ lưỡng để xác định cụ thể lợi hại.

Hãy thử xét trên bình diện tài chính, thời gian, kỹ thuật và trách nhiệm xem ý kiến nào ở trên là thoả đáng và hợp lý.

Mời bà con mổ xẻ "case study" này.

What bringing us together is stronger than what pulling us apart.

[Discussion] Case study: tối ưu không cần thiết	13/08/2010 10:16:48 (+0700) \| #2 \| 218274

louisnguyen27
Member

Joined: 12/08/2008 18:04:41
Messages: 321
Offline

conmale wrote:

Chuyện tốn kém không thể nói bừa mà phải chiết tính kỹ lưỡng để xác định cụ thể lợi hại.

Em thấy hai cha này hơi nhảm: ông thứ nhất nói mua này mua nọ nhưng chẳng phải là người chi tiền để đi mua, ông thứ hai cũng nhảm nốt vì bỏ thời gian đi cãi với ông thứ nhất.
Vấn đề duy nhất của hai đồng chí này là đưa ra phương án, tính ROI và khả năng.

Q+SBtZW1iZXIgb2YgSFZ+B
Back to Linux soon!!!

[Discussion] Case study: tối ưu không cần thiết	13/08/2010 10:47:11 (+0700) \| #3 \| 218280

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

louisnguyen27 wrote:

conmale wrote:

Chuyện tốn kém không thể nói bừa mà phải chiết tính kỹ lưỡng để xác định cụ thể lợi hại.

Em thấy hai cha này hơi nhảm: ông thứ nhất nói mua này mua nọ nhưng chẳng phải là người chi tiền để đi mua, ông thứ hai cũng nhảm nốt vì bỏ thời gian đi cãi với ông thứ nhất.
Vấn đề duy nhất của hai đồng chí này là đưa ra phương án, tính ROI và khả năng.

Em nên khai triển rộng hơn và sâu hơn là nhận định ngắn gọn như trên bởi vì cho rằng ông nào cũng nhảm thì nên chứng minh tại sao họ nhảm trên quan điểm "tài chính, thời gian, kỹ thuật và trách nhiệm".

What bringing us together is stronger than what pulling us apart.

[Discussion] Case study: tối ưu không cần thiết	13/08/2010 11:39:54 (+0700) \| #4 \| 218282

St Konqueror
Member

Joined: 08/12/2007 00:47:39
Messages: 229
Offline

conmale wrote:

Một bên thì cho rằng tài nguyên máy thời nay thừa thãi, muốn hiệu suất hơn thì chỉ cần thảy thêm RAM, CPU là xong. Tính ra giá thành, chi phí những cái này còn rẻ hơn mướn người ngồi đó mà táy máy chuyện tối ưu, phí thời gian, phí tiền bạc.

Người nói câu này có lẽ không chịu trách nhiệm cho một hệ thống cỡ lớn mà có khả năng là chỉ quản lí ở mức độ hệ thống của các SME mà thôi. Bởi vì nếu là một hệ thống lớn mà hoạt động không hiệu quả thì chi phí mỗi lần quăng thêm thiết bị mới vào để cho nó chạy nhanh hơn cũng không thể nói là rẻ.

Tuy nhiên, người này cũng có ý nghe được: Đó là khi cần gấp một hệ thống xử lí tốt hơn (ví dụ chuẩn bị cho việc phát triển sản phẩm mới) mà phải chờ sysadmin ngồi lại cấu hình, theo dõi, tối ưu thì cũng rất mất thời gian một cách không cần thiết. Ngoài ra, có thể làm delay công việc các teams khác đang cần sử dụng hệ thống. Vậy thì chẳng thà đầu tư một khoảng để thảy thêm thiết bị vào còn hơn là phải làm delay công việc của công ty, đặc biệt là nếu khoảng đầu tư đó không lớn so với doanh thu dự tính thu được từ sản phẩm. Đó là xét về mặt thời gian và tài chính.

Còn nếu xét về mặt kỹ thuật và trách nhiệm thì nếu một hệ thống hoạt động mà không được quan tâm tối ưu hiệu suất thì cứ sẽ phải nâng cấp dài dài do mỗi lần nâng cấp cũng chỉ tăng hiệu suất được một thời gian chứ không thể nào đảm bảo hiệu quả lâu dài. Mà nếu maintain một hệ thống mà không tính đường lâu dài thì đúng là vô trách nhiệm. Và không chỉ có vậy, một hệ thống hoạt động không hiệu quả trong một thời gian dài sẽ trở nên cồng kềnh quá mức và rất có thể tiềm ẩn nhiều vấn đề về bảo mật.

Cho nên kết lại thì gọn nhất là 2 ông này nên đưa ra chiến lược để tăng hiệu suất có bao gồm cả 2 phương án là nâng cấp phần cứng và tối ưu phần mềm. Sau đó xem xét hiệu quả của từng phương án trong ngữ cảnh thời gian, khả năng tài chính và tính đến cả chiến lược lâu dài. Cuối cùng quyết định làm thế nào cho hiệu quả nhất là được.

-stk

[Discussion] Case study: tối ưu không cần thiết	13/08/2010 11:53:40 (+0700) \| #5 \| 218283

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

Rất lý thú với những input của St Konqueror.

Tớ "nhá" thêm hai thuật ngữ để tham khảo và sử dụng trong case study này đó là: vertical scaling và horizontal scaling.

What bringing us together is stronger than what pulling us apart.

[Discussion] Case study: tối ưu không cần thiết	13/08/2010 13:08:56 (+0700) \| #6 \| 218287

Ky0
Moderator

Joined: 16/08/2009 23:09:08
Messages: 532
Offline

conmale wrote:

Hôm nọ, tôi nghe hai kỹ sư điện toán kháo chuyện nhau và dẫn đến chỗ cãi nhau khá kịch liệt.

Một bên thì cho rằng tài nguyên máy thời nay thừa thãi, muốn hiệu suất hơn thì chỉ cần thảy thêm RAM, CPU là xong. Tính ra giá thành, chi phí những cái này còn rẻ hơn mướn người ngồi đó mà táy máy chuyện tối ưu, phí thời gian, phí tiền bạc. Một bên thì cho rằng đây là thái độ lười nhác và vô trách nhiệm bởi vì một hệ thống muốn đạt hiệu suất không chỉ ném tài nguyên vào nó mà phải theo dõi, điều chỉnh và kiện toàn. Đây chính là công việc tối ưu cần thiết mà engineer nào cũng phải cần làm. Chuyện tốn kém không thể nói bừa mà phải chiết tính kỹ lưỡng để xác định cụ thể lợi hại.

Hãy thử xét trên bình diện tài chính, thời gian, kỹ thuật và trách nhiệm xem ý kiến nào ở trên là thoả đáng và hợp lý.

Mời bà con mổ xẻ "case study" này.

Đây cũng là vấn đề em và bạn em thường tranh cãi mà smilie

Em luôn đồng ý với ý kiến: "Tối ưu hoá là việc làm cần thiết"
Vì các lý do sau:
- Các công ty sản xuất phần cứng/phần mềm hầu hết là thiết kế để đáp ứng đại đa số yêu cầu của người sử dụng. Mà mỗi người lại sử dụng nó cho một mục đích khác nhau, cho nên sẽ có những chức năng(thành phần) họ không dùng đến điều đó sẽ dẫn đến các hệ quả:
+ Lãng phí tài nguyên cho những chức năng mà người dùng không dùng tới. Mặc dù là nó rất nhỏ nhưng xét trên hệ thống lớn và về lâu về dài thì đó là sự lãng phí lớn.
+ Phát sinh những lỗi ảnh hưởng đến hệ thống từ những thành phần mà mình không sử dụng. Nếu bỏ tiền ra để bảo trì và sửa lỗi cho những cái mình không sử dụng quả là điều lãng phí. Điều này đe doạ đến bảo mật của hệ thống
+ Làm giảm khả năng ổn định của hệ thống vì nó có quá nhiều chức năng cùng hoạt động. Vì cái gì càng phức tạp và đa dạng thì độ ổn định càng giảm.
=> Giải pháp này không hiệu quả khi nhân lực và thời gian bị hạn chế!

- Ngoài ra tối ưu hoá còn phát sinh vấn đề lãng phí khác: Lãng phí thời gian ngồi tối ưu hoá, lãng phí nhân lực, trong khi có thể có những giải pháp khác mang lại hiệu quả tương tự nhưng ít tốn kém hơn.

Tóm lại:

- Nếu xét về Thời gian + Kỹ thuật: Thì tối ưu hoá mang lại hiệu quả cao hơn. Người làm về kỹ thuật thường quan tâm đến vấn đề tối ưu hoá.
- Nếu xét về Thời gian + Kỹ thuật + Tài chính: Thì lúc đó phải tính toán sao cho mang lại hiệu quả cao nhất, và tốn ít chi phí nhất. Về điểm này thì hoàn toàn đồng ý với St Konqueror

- Ky0 -

UITNetwork.com
Let's Connect

[Discussion] Case study: tối ưu không cần thiết	13/08/2010 13:12:05 (+0700) \| #7 \| 218288

tmd
Member

Joined: 28/06/2006 03:39:48
Messages: 2951
Offline

Mình phân biệt kỹ cách sử dụng của Tây và mình. Dân Tây thì nó sài hết thời gian "khấu hao" rồi thải hàng loạt. Mình sài tới lúc nó hư hoàn toàn không thể cứu vãn rồi mới thanh lý.

http://www.scalingout.com/2007/10/vertical-scaling-vs-horizontal-scaling.html

Vertical scling: thêm phần cứng vào 1 máy để nâng hiệu suất. Cái này giải thích trường hợp của ông ks đòi thêm phần cứng.

Horizontal scaling: thêm nhiều máy vào hệ thống tàng tàng. Dĩ nhiên hệ thống này chỉ có máy cùng cấu hình hơi thấp một chút.

Mô hình cty thoã mái, ai yêu cầu máy gì mua nấy, máy cấu hình khác nhau. Công việc cấu hình,bảo trì, sửa chửa, kiểm tra sẽ tốn kém rất nhiều. Mô hình này mãn nhu cầu đơn lẻ hoặc nhóm nhỏ. Cty chắc cũng có quy mô nhỏ, công ty có chính sách không khắc khe, công việc không đồng bộ.

Mô hình công ty làm việc đồng bộ, mua hệ thống máy giống nhau, vì không có yêu cầu cấu hình cao. Mọi việc như trên kia sẽ dễ dàng hơn rất nhiều. Họ áp dụng quy chế sử dụng khấu hao. Hệ thống máy sài bao nhiêu lâu sẽ thải loại và mua mới. Mô hình cty lớn có chính sách rõ ràng thường chơi kiểu này.

PS: Tuỳ vào chính sách mà người ta sẽ có biện pháp tối ưu ở mức nào đó chấp nhận được.
http://en.wikipedia.org/wiki/Scalability

3 giai đoạn của con... người, ban đầu dek biết gì thì phải thăm dò, sau đó biết rồi thì phải thân thiết, sau cùng khi quá thân thiết rồi thì phải tình thương mến thương. Nhưng mà không thương được thì ...

[Discussion] Case study: tối ưu không cần thiết	13/08/2010 14:02:17 (+0700) \| #8 \| 218292

vikjava
Elite Member

Joined: 28/06/2004 02:32:38
Messages: 926
Location: NQN
Offline

@louisnguyen27: có thể 2 người đó có khả năng hoặc nhiệm vụ làm báo cáo trình lên ban tổng giám đốc nâng cấp hoặc tối ưu hệ thống. "Người bỏ tiền " họ không tự quyết định điều này.

Hôm nọ, mình có nghe nói lãnh đạo cty kia trình nâng cấp hệ thống bổ sung thêm SAN, server nghe đâu dự toán cỡ 2 triệu USD. Trong khi hệ thống mới đầu tư hơn 5 triệu USD đươc 2 năm. Lý do xin nâng cấp là do ứng dụng phục vụ quá chậm, người dùng la lối quá trời.

Mình có hỏi tại sao cty đó không thành lập một nhóm người ngồi tối ưu lại ứng dụng. Câu trả lời là ai có thể nắm hết ứng dụng đó ( mua của tụi nước ngoài, tui nó triển khai và hổ trợ từ A-Z). Bộ phận ứng dụng mỗi người nắm một mảng, viết thêm chương trình hoặc report gắn vào là tốt rồi. Lý do thứ 2 là nâng cấp phần cứng thì an toàn ít rủi ro và các sếp trên dễ "cảm nhận" hơn.

Bênh cạnh đó, các cty phần cứng luôn "bám sát" , "tư vấn" cho các sếp.

Một cái là thấy ngay kết quả, một cái là cả một quá trình chưa chắc có đáp số. Đa phần các "sếp" sẽ chọn cái có kết quả ngay. Các "sếp" này sẽ tư vấn cho "Người bỏ tiền" là các sếp bự hơn ở trên.

[Discussion] Case study: tối ưu không cần thiết	13/08/2010 14:07:49 (+0700) \| #9 \| 218293

kenji
Member

Joined: 24/09/2003 13:20:28
Messages: 77
Offline

Nếu em là sếp thì nắm đầu hai cha kia kêu vào làm việc, cha nào đòi nâng cấp cứ list ra và cha nao đòi tối ưu thì cho tôi ưu những gì có thể.
Hai cha ko nên ngồi chung. Nếu cha kia ko thể tối ưu thì quăng qua cha kia xem có thể nâng cấp or thây mới hay ko.
Còn mình thì ngồi uống cafe xem sao smilie

Tính em đơn giản nên nghĩ sao nói rứa, mong mấy bác đừng chém gió

[Discussion] Case study: tối ưu không cần thiết	13/08/2010 21:01:06 (+0700) \| #10 \| 218315

panfider
Member

Joined: 12/05/2010 01:51:04
Messages: 448
Offline

Đứng với góc độ một lập trình viên,mình đồng ý cho ý kiến tối ưu để đạt hiệu quả, một chuơng trình không tối ưu là chương trình gây ra risk và phát sinh ra nhiều vấn đề sau này.
Là một lập trình viên có kinh nghiệm và hiểu biết thì có lời khuyên: không tối ưu là một sai lầm lớn.

[Unix] live free or die

[Discussion] Case study: tối ưu không cần thiết	13/08/2010 23:33:27 (+0700) \| #11 \| 218321

tmd
Member

Joined: 28/06/2006 03:39:48
Messages: 2951
Offline

panfider wrote:

Đứng với góc độ một lập trình viên,mình đồng ý cho ý kiến tối ưu để đạt hiệu quả, một chuơng trình không tối ưu là chương trình gây ra risk và phát sinh ra nhiều vấn đề sau này.
Là một lập trình viên có kinh nghiệm và hiểu biết thì có lời khuyên: không tối ưu là một sai lầm lớn.

Không phải lập trình viên nào cũng biết tối ưu hiệu suất làm việc của toàn bộ cấu trúc máy + HDH + software cài thêm nha bạn.
Sáng vào nhấn button, gỏ lóc cóc.... gỏ ... gỏ... chiều cũng có khi bấm button, rồi về hay để đó rồi đi về. smilie

PS: hạn chế cảm tính , mà nhìn vào thực tế nói chuyện sẽ thiết thực hơn. Tất nhiên là ví dụ "lóc cóc" trên là có đó. smilie

[Discussion] Case study: tối ưu không cần thiết	14/08/2010 00:24:15 (+0700) \| #12 \| 218323

tmd
Member

Joined: 28/06/2006 03:39:48
Messages: 2951
Offline

Lấy một ví dụ đang tui đang có đây. Công ty xây dựng quy mô lớn, nhân viên văn phòng tầm 50-60 người. Mỗi người được mua một PC, có cấu hình không giống nhau. Tùy vào công việc, máy của kỹ thuật được ưu tiên có vga card rời . Nhưng, các phòng khác, không có mục đồ họa trong công việc, vẫn mua card vga. Lý do được mua là công ty không có quy chế rõ ràng là cấm mua vga card cho nhân viên văn thư, marketing... ngoài nhân viên làm kỹ thuật có đồ họa.

Về các vấn đề tài chính, thời gian, kỹ thuật, và trách nhiệm, công ty không có chuẩn như ISO . Cho nên, công ty không có người quản lý vấn đề chi tiêu chặc chẻ, ai muốn mua gì, thì chờ trưởng phòng duyệt, sau đó chờ xếp lớn ký duyệt là được mua. Người khác nhìn vào không cần biết mua cái đó về làm gì, mà yêu cầu vật tư vẫn được duyệt. Vật được mua về bỏ vào kho.

Cho nên, khi xét về khoản tài chính, nên xem công ty có chính sách chặc chẻ không. Nếu không, vấn đề tài chính gần như ảnh hưởng đến toàn bộ các khoản thời gian,... còn lại. Nếu có, các vấn đề thời gian, kỹ thuật, và trách nhiệm bắt đầu được xét tới, lấy yếu tố thời gian làm chủ đạo. Nếu thời gian không phải vấn đề sớm chiều, thì người ta có thể gặp chuyện tự cài tự chỉnh. Nhưng nếu vấn đề đó đặt nặng, thì anh lập trình viên hay kỹ sư phần mềm chẳng cần phải mó tay vào chỉnh, mọi chuyện có bộ phận quản lý thiết bị lo tất, anh chỉ cần vào gỏ và gò tắt máy đi về.

Trách nhiệm của anh kỹ sư nào cũng là tuân thủ nội quy làm việc của công ty. Một số trường hợp anh không thể tự chỉnh tự sửa để "tối ưu" theo ý riêng. Việc này hạn chế tối đa vấn đề sao nhảng của anh kỹ sư khi gặp sự cố, hư là có máy gắn vào để làm tiếp.
Vậy thì khi công ty không có bộ phận bảo trì thì công ty phải có một chính sách theo dõi, điều chỉnh và kiện toàn mà người kỹ sư có thể tự làm theo.

[Discussion] Case study: tối ưu không cần thiết	14/08/2010 08:56:04 (+0700) \| #13 \| 218328

panfider
Member

Joined: 12/05/2010 01:51:04
Messages: 448
Offline

không biêt cty tmd kinh doanh lĩnh vực gì ?

[Unix] live free or die

[Discussion] Case study: tối ưu không cần thiết	14/08/2010 09:57:48 (+0700) \| #14 \| 218337

tmd
Member

Joined: 28/06/2006 03:39:48
Messages: 2951
Offline

panfider wrote:

không biêt cty tmd kinh doanh lĩnh vực gì ?

Lĩnh vực cơ sở hạ tầng cơ bản. Vậy xin panfider cho một ví dụ về những loại hình công ty kinh doanh lĩnh vực công nghệ phần mềm có tối ưu nhưng không có bộ phận bảo trì xem sao. Phân biệt giữa công ty không có chính sách cụ thể và công ty cho nhân viên toàn quyền tự xử cái máy.

[Discussion] Case study: tối ưu không cần thiết	14/08/2010 13:01:07 (+0700) \| #15 \| 218344

panfider
Member

Joined: 12/05/2010 01:51:04
Messages: 448
Offline

mình đứng với góc độ lập trình viên để đưa ra lời khuyên. Vì vậy lời khuyên của mình thuộc về kĩ thuật lập trình.
Mình không đứng ở góc độ quản lý, nên khó đưa ra nhận định đúng ở góc độ tmd.

Đứng với góc độ quản lý thì cty nhỏ thì dễ quản lý hơn cty lớn. Cty tmd có thường gặp vấn đề kĩ thuật nào thường xuyên thì liệt kê, và lập nhóm, phân tích và xử lý.

[Unix] live free or die

[Discussion] Case study: tối ưu không cần thiết	14/08/2010 17:16:35 (+0700) \| #16 \| 218354

tmd
Member

Joined: 28/06/2006 03:39:48
Messages: 2951
Offline

Đứng ở góc độ nào thì cũng phải dựa vào nhu cầu thực tế. Không nên đứng ở góc độ cá nhân để rồi áp đặt nhu cầu đó cho thực tế đám đông. Nên hiểu một chuyện là lập trình viên thì không giống quản lý hệ thống, cũng không giống người cung cấp thiết bị, cũng không giống hỗ trợ kỹ thuật.
PS: Tui quote lại để rõ

Đứng với góc độ một lập trình viên,mình đồng ý cho ý kiến tối ưu để đạt hiệu quả, một chuơng trình không tối ưu là chương trình gây ra risk và phát sinh ra nhiều vấn đề sau này.

Lập trình viên không thể biết rõ chuyện phần cứng và phần mềm nó có tuơng thích hay không để mà tối ưu. Mà tối ưu cái gì ở đây, rõ ràng ra một chút. Phần cứng tối ưu bằng cách cpu tốc độ cao, ram nhiều, mainboard đa năng, ... , hay tinh chỉnh hệ điều hành tối ưu, hay phần mềm trên đó vừa đủ không gây xung đột. Bạn pathfider cần nói cho rõ ràng ra.
Một software không tối ưu là do anh lập trình viên làm ra không được tốt, sao có liên quan tới cái máy anh ta ngồi trên đó. Trừ phi anh ta không biết anh ta đang ngồi trên cái gì để viết phần mềm.

Là một lập trình viên có kinh nghiệm và hiểu biết thì có lời khuyên: không tối ưu là một sai lầm lớn.

Tui chẳng bao giờ đi tin người nói cái câu này. Nói chung chung ai mà tin cho được.

[Discussion] Case study: tối ưu không cần thiết	15/08/2010 10:55:27 (+0700) \| #17 \| 218393

panfider
Member

Joined: 12/05/2010 01:51:04
Messages: 448
Offline

Không nên đứng ở góc độ cá nhân để rồi áp đặt nhu cầu đó cho thực tế đám đông

bạn có thể nhận xét đồng ý hay bác bỏ một ý kiến, nhưng nói nó áp đặt thì hơi vô lý!

Lập trình viên không thể biết rõ chuyện phần cứng và phần mềm nó có tuơng thích hay không để mà tối ưu. Mà tối ưu cái gì ở đây, rõ ràng ra một chút.

mình tiếc không giúp gì được cho tmd. Nhưng câu nói trên của tmd làm mình bối rối. tmd nên giải thích câu đó được không ?

[Unix] live free or die

[Discussion] Case study: tối ưu không cần thiết	15/08/2010 10:59:39 (+0700) \| #18 \| 218394

tmd
Member

Joined: 28/06/2006 03:39:48
Messages: 2951
Offline

mình tiếc không giúp gì được cho tmd. Nhưng câu nói trên của tmd làm mình bối rối. tmd nên giải thích câu đó được không ?

Bối rối vì cái gì cũng nên cho rõ ràng. Tự nhận mình là lập trình viên, tự nhận rằng cần tối ưu. Nhưng chẳng thấy nói rõ ràng về cách thức hay đường hướng.

PS:

Vì vậy lời khuyên của mình thuộc về kĩ thuật lập trình

.
Bạn đang tham gia lộn topic rồi.

conmale wrote:

Một bên thì cho rằng tài nguyên máy thời nay thừa thãi, muốn hiệu suất hơn thì chỉ cần thảy thêm RAM, CPU là xong. Tính ra giá thành, chi phí những cái này còn rẻ hơn mướn người ngồi đó mà táy máy chuyện tối ưu, phí thời gian, phí tiền bạc. Một bên thì cho rằng đây là thái độ lười nhác và vô trách nhiệm bởi vì một hệ thống muốn đạt hiệu suất không chỉ ném tài nguyên vào nó mà phải theo dõi, điều chỉnh và kiện toàn. Đây chính là công việc tối ưu cần thiết mà engineer nào cũng phải cần làm. Chuyện tốn kém không thể nói bừa mà phải chiết tính kỹ lưỡng để xác định cụ thể lợi hại.

[Discussion] Case study: tối ưu không cần thiết	15/08/2010 11:16:11 (+0700) \| #19 \| 218396

vikjava
Elite Member

Joined: 28/06/2004 02:32:38
Messages: 926
Location: NQN
Offline

Hi anh conmale và mọi người !

Cho em hỏi tí, để thực hiện tối ưu hoá thì cần những gì ? Chẳng hạn tối ưu hoá hệ thống cỡ lớn như corebanking ở các công ty tài chính chứng khoáng, ngân hàng ! Em nghĩ chúng ta phải biết tối ưu hoá là gì, tối ưu hoá cái gì, triển khai như thế nào, rồi sau đó mới tính tới chuyện bàn luận tại sao triển khai smilie

p/s: Các bạn nên tập trung vào chủ đề, có gì thì mở topic mới ra để tranh luận. Tranh luận mang tính cá nhân dễ gây loãng topic, vài lời ...

[Discussion] Case study: tối ưu không cần thiết	15/08/2010 11:33:27 (+0700) \| #20 \| 218398

tmd
Member

Joined: 28/06/2006 03:39:48
Messages: 2951
Offline

vikjava wrote:

Hi anh conmale và mọi người !

Cho em hỏi tí, để thực hiện tối ưu hoá thì cần những gì ? Chẳng hạn tối ưu hoá hệ thống cỡ lớn như corebanking ở các công ty tài chính chứng khoáng, ngân hàng ! Em nghĩ chúng ta phải biết tối ưu hoá là gì, tối ưu hoá cái gì, triển khai như thế nào, rồi sau đó mới tính tới chuyện bàn luận tại sao triển khai

p/s: Các bạn nên tập trung vào chủ đề, có gì thì mở topic mới ra để tranh luận. Tranh luận mang tính cá nhân dễ gây loãng topic, vài lời ...

Câu chuyện này rõ ràng quá còn gì . Câu chuyện xoay quanh 2 ngài kỹ sư . Còn chuyện 2 ngài kỹ sư này làm ở chổ nào thì mình không nên nói ra. Nó gây loảng topic thật sự, có rất nhiều ngành nghề khác nhau trong cái lĩnh vực IT, và ứng dụng của nó trong các ngành nghề khác cũng phức tạp. Lấy ví dụ tài chính sẽ làm người ta nghiêng hẳn về tài chính và quên hết các ngành khác. Như vậy mới là loãng thật sự.

[Discussion] Case study: tối ưu không cần thiết	15/08/2010 19:21:11 (+0700) \| #21 \| 218434

haipt
Member

Joined: 20/08/2004 19:48:44
Messages: 165
Location: Hải phòng
Offline

Hai người muốn biết ai thắng ai thì phải lên các plan, vạch ra solution , ghi rõ chi phí bỏ ra và lợi ích đạt đc của mỗi solution thì sẽ tìm ra giải pháp tốt nhất, tất cả mọi thứ đều quy ra $ để cân đong đo đếm không thì so sánh bằng niềm tin mất smilie

"Cho nên kết lại thì gọn nhất là 2 ông này nên đưa ra chiến lược để tăng hiệu suất có bao gồm cả 2 phương án là nâng cấp phần cứng và tối ưu phần mềm. Sau đó xem xét hiệu quả của từng phương án trong ngữ cảnh thời gian, khả năng tài chính và tính đến cả chiến lược lâu dài. Cuối cùng quyết định làm thế nào cho hiệu quả nhất là được".
==> Ý kiến của St Konqueror là chuẩn nhất .Chứ bạ đâu cũng tối ưu thì có khi lại mang vạ.

[Discussion] Case study: tối ưu không cần thiết	16/08/2010 08:07:52 (+0700) \| #22 \| 218468

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

vikjava wrote:

Hi anh conmale và mọi người !

Cho em hỏi tí, để thực hiện tối ưu hoá thì cần những gì ? Chẳng hạn tối ưu hoá hệ thống cỡ lớn như corebanking ở các công ty tài chính chứng khoáng, ngân hàng ! Em nghĩ chúng ta phải biết tối ưu hoá là gì, tối ưu hoá cái gì, triển khai như thế nào, rồi sau đó mới tính tới chuyện bàn luận tại sao triển khai

p/s: Các bạn nên tập trung vào chủ đề, có gì thì mở topic mới ra để tranh luận. Tranh luận mang tính cá nhân dễ gây loãng topic, vài lời ...

Hì hì, em rất thích cụ thể "ngô khoai" hả?

Với những hệ thống lớn của các công ty tài chính, chứng khoán, ngân hàng.... việc tối ưu thực hiện cụ thể trên từng "tier". Ví dụ, bên ngoài vào trong, network tier nếu không có QoS cụ thể và packets ra vào tràn lan thì không thể nào bảo đảm chất lượng truyền tải, dẫn đến những trì trệ chồng chất. Tiếp đến là những ứng dụng / thiết bị như firewall, reverse proxies... nếu không kiện toàn thì hiệu suất bị giảm vì bước qua mỗi chặng là bị giảm vận tốc truy cập. Đi vào đến tầng web, nếu không tối ưu đúng mức, số lượng connection được dùng bị thiếu hoặc thời gian cho phép được duy trì xuất truy cập quá dài không cần thiết khiến tài nguyên bị thiếu hụt, dẫn tới tình trạng trì trệ. Trong tầng application bên trong, nếu coding không hữu hiệu và không tối ưu đúng mức sẽ tạo tình trạng kém hiệu suất và "nuốt tài nguyên" nghiêm trọng. Những thứ đơn giản như database connection pool nếu không "tune" cho đúng mức cũng sẽ tạo tình trạng kém hiệu suất một cách nghiêm trọng.

Xét tổng quát cho các tiers thì:
network BW --> router --> FW --> proxies --> web --> app --> database --> storage

Mỗi tầng có thể có một hoặc nhiều thiết bị song song và có đòi hỏi khác nhau.

Nói chung, nguyên tắc optimization áp dụng cho mỗi tầng xuyên suốt trong kiến trúc của một hệ thống. Mỗi optimization khác nhau (vì có tính chất và vai trò khác nhau) nhưng đều có chung mục đích:
- Nhanh.
- Bền.
- Bảo mật.

What bringing us together is stronger than what pulling us apart.

[Discussion] Case study: tối ưu không cần thiết	16/08/2010 11:04:48 (+0700) \| #23 \| 218490

vikjava
Elite Member

Joined: 28/06/2004 02:32:38
Messages: 926
Location: NQN
Offline

conmale wrote:

Xét tổng quát cho các tiers thì:
network BW --> router --> FW --> proxies --> web --> app --> database --> storage

Mỗi tầng có thể có một hoặc nhiều thiết bị song song và có đòi hỏi khác nhau.

Nói chung, nguyên tắc optimization áp dụng cho mỗi tầng xuyên suốt trong kiến trúc của một hệ thống. Mỗi optimization khác nhau (vì có tính chất và vai trò khác nhau) nhưng đều có chung mục đích:
- Nhanh.
- Bền.
- Bảo mật.

Hi all !

Xét trên mô hình các tiers đã đề ra :

- Để thực hiện tối ưu hoá chúng ta phải có ít nhất là 6 người thật giỏi , nắm vững các tầng , đồng thời có một người đứng đầu và có thể có một số nhân viên IT khác. Xét trên bình diện tài chính thì chi phí cho đội ngũ tối ưu hoá này thấp hơn rất nhiều so với việc nâng cấp hệ thống. Chẳng hạn ta nâng cấp hệ thống với giá 1 triệu USD đáp ứng được nhu cầu trong 1 năm, trong khi đó 1 năm thì tiền lương cho các chú này ko tới giá đó.

- Về phương diện thời gian, việc nâng cấp giải quyết được vấn đề một cách nhanh chóng tuy nhiên về lâu dài thì ta không thể cứ nâng cấp liên tục, trong khi đó việc tối ưu phải có thời gian nghiên cứu, chỉnh thử ...

- Tuỳ thuộc vào yêu cầu cấp thiết của công ty mà ta có phương án cụ thể và hữu ích

- Xét trên bình diện kỹ thuật và trách nhiệm thì một người quản trị hệ thống phải nắm rõ hệ thống của mình, phải control được hệ thống đó. Trách nhiệm của mình không phải chỉ là cài đặt cho nó chạy mà phải làm sao cho nó chạy tốt, đáp ứng nhu cầu công việc với chi phí thấp nhất.

- Tất cả các vấn đề đều nằm ở tầm nhìn của lãnh đạo, đối với môi trường làm việc tại việt nam đa số chọn phương án mua thiết bị, vừa nhanh, ít rủi ro lại có hoa hồng - 5% trên 1 triệu usd

p/s: hi anh conmale, em thích "thực chiến quyền pháp" học làm và áp dụng được, cũng như võ bình định - hiểm độc đánh là gục, không múa máy linh tinh chả được tích sự gì smilie

Go to:

Users currently in here
1 Anonymous