Unlimited CPU license+better bandwidth protection

[danielspencer2]

Myself and alot of friends currently have a server and once our website starts getting lots of visitors we are going to keep adding more and more CPU's.
Currently we have to purchase different licenses depending on the number of CPU's we have.

Our suggestion is, litespeed should have an unlimited CPU license that supports an unlimited amount of CPUs. I think i read that litespeed can support up to 16 CPU cores, and that's fine, so you should keep on working on supporting more and more CPU cores and customers won't have to purchase a different license.

For example, an Unlimited CPU license could cost $120 per month and it would support unlimited CPU's but you could state litespeed currently only supports 16 cores, and state when litespeed supports more cores the customer won't have to upgrade their license.



Our next suggestion is regarding the bandwidth protection feature you have. Our suggestion is, the admin should be able to set a maximum amount of bandwidth(in and out. http/https/ftp etc) they want their server to use each month, and once the bandwidth limit is reached, their server will shut down, instead of displaying a 'bandwidth exceeded' type page. The shutdown feature should work on CentOS, Ubuntu, etc. There could be a graphical 12 month calendar so users can choose when the month starts and ends. The date could be retrieved from the CentOS/Ubuntu/etc clock.

 

[anewday]

How do you know for sure that cpu is the bottleneck? Maybe faster hdd or more ram would help instead of adding more cpu license.

 

[ffeingol]

Currently we have to purchase different licenses depending on the number of CPU's we have

No, you do not. You don't license LSWS based on the number of CPU's on your server, you license based on the number of CPU's you want to use. We have many 4 core servers with 2 CPU's licenses. This leaves 2 CPU's available for PHP, MySQL etc.

 

[envygeeks]

No, you do not. You don't license LSWS based on the number of CPU's on your server, you license based on the number of CPU's you want to use. We have many 4 core servers with 2 CPU's licenses. This leaves 2 CPU's available for PHP, MySQL etc.

And how do you know that PHP and MySQL are going to different processors? Unless you have the ability to set affinity in Litespeed for both PHP and httpd it's all just theory that it's more efficient and they are being segregated properly. You should actually be putting PHP+HTTPD on 2 processors with MySQL on one processor and leaving CPU0 open for system operations. In otherwords CPU0=System, CPU1=MySQL, CPU{2,3}=HTTPD+PHP.

What I am trying to say is, unless you set the affinity for MySQL, and you manually set the affinity for Litespeed, you have no idea where and what processor those processes are going to. For all you know litespeed could be ending up on the same processor as MySQL. Yeah, you can check after the fact, but you can't control that factoring, which is a flaw in Litespeed in my eyes.

 

[MikeDVB]

which is a flaw in Litespeed in my eyes.

It would be a flaw with any single-threaded application on a multi-core system imho unless the system itself switches the thread to different cores based upon load. I don't get that deep into the details so I wouldn't know for sure.

 

[mistwang]

For all you know litespeed could be ending up on the same processor as MySQL. Yeah, you can check after the fact, but you can't control that factoring, which is a flaw in Litespeed in my eyes.

It is completely up to the task scheduler of the kernel, not likely be controlled by user land application, no matter it is single-threaded or multi-threaded application. Even if you can control that, you should not, as the kernel task scheduler usually does better job on that.

 

[envygeeks]

It is completely up to the task scheduler of the kernel, not likely be controlled by user land application, no matter it is single-threaded or multi-threaded application. Even if you can control that, you should not, as the kernel task scheduler usually does better job on that.

That's very subjective and broad. Any good Engineer knows you should control affinity for better efficiency. The task schedulers job is to try and balance, not try and create affinity. We create affinity for efficiency, it's faster to remain on the same processor because of caching than it is to constantly switch between processors where on a dual core system we have little caching and on a multi-socket system we have no affinity. Affinity does not affect the algorithm, as the Task scheduler algorithm will still move processes between processors if it sees the need to, anybody who has worked with this, knows this. In other words I'm saying, by not allowing us to set CPU affinity, you remove all of our ability to try and effort CPU affinity and create better system efficiency and speed, however that's alright because we just bypass you and use schedutils. You can't sit there and tell me that an application switching between CPU0 and CPU1 is faster than a process who has CPU1 dedicated to it and is cached in the processor...

 

[triedia09]

Unlimited CPU licensebetter bandwidth protection

Done.

While this is a very good idea and long overdue, it will not make a dent in our bandwidth or storage excess.

Any other ideas?