1 Minute Crons

[Alex]

Hey guys,

 

Currently Blesta only allows a maximum cron frequency of 5 minutes for any particular task. I would like to see more frequent options, especially for ticket importing from email where you do not want a 5 minute delay if a customer is seeking technical support. If the mail is going to bounce because they need to use an e-mail which they have on file for the department to accept the mail, you also do not want a 5 minute delay sending that response to them.

 

Thanks,

Alex

[hostingDifferent-Scott]

Agreed. Support tickets need to be polled much quicker.

[Evaske]

I also think account creation should be done every minute and not every five. 

[Michael]

You've just got to be careful, if you have 10 people signing up every minute / placing orders or tickets you could end up causing loading problems.

 

Well that's what I believe would happen.

[Alex]

You've just got to be careful, if you have 10 people signing up every minute / placing orders or tickets you could end up causing loading problems.

 

Well that's what I believe would happen.

 

If your mail server can't handle sending 10 emails per minute, or even 100 for that matter, then I would say it's probably time to consider a dedicated mail provider. Furthermore, mail servers have an internal mail queue to prevent any real harm from rapid sending, as the mails will "wait in line until it is their turn" when load is high. But realistically, I've managed mail servers which handle 10+ emails sent per minute regularly for years on end without even a reboot. Regardless, the cron is granular and adjustable enough that if a particular setting causes you issues it can be tweaked. Maybe we should have 1, 2, 3 and 5 minute options for those cases?

[Andreas]

I do not understand the reason for this.

 

Such as "Provision Paid Pending Services"

 

Would this mean when a new person signs up they have to wait the time specified??

If I uncheck that option will it be automatic instead?

[Michael]

If your mail server can't handle sending 10 emails per minute, or even 100 for that matter, then I would say it's probably time to consider a dedicated mail provider. Furthermore, mail servers have an internal mail queue to prevent any real harm from rapid sending, as the mails will "wait in line until it is their turn" when load is high. But realistically, I've managed mail servers which handle 10+ emails sent per minute regularly for years on end without even a reboot. Regardless, the cron is granular and adjustable enough that if a particular setting causes you issues it can be tweaked. Maybe we should have 1, 2, 3 and 5 minute options for those cases?

 

It's called running a cron job.. Sorry they aren't just sending emails by air.

[Alex]

It's called running a cron job.. Sorry they aren't just sending emails by air.

 

I'm quite familiar with what a cron job is, as is evident by this thead... But, I don't know what you're talking about. Ideally you're sending email from a decent server in a real data center..? You make it sound like everyone is using a circa 2001 laptop in their basement on dial-up as a mail server.

[silvatech]

I am a little confused here as 5 minute wait on cron is standard in the industry. Some of the larger providers actually endup setting it to 15 minutes on allocation.

[Alex]

I do not understand the reason for this.

 

Such as "Provision Paid Pending Services"

 

Would this mean when a new person signs up they have to wait the time specified??

If I uncheck that option will it be automatic instead?

 

No, that is the frequency in which the system will perform the action. So, the system will do it every 5 minutes if you set it to that, for example, 12:05, 12:10, 12:15, etc. If a client signs up at 12:06 they wait 4 minutes. If they sign up at 12:09 they wait 1 minute. If you disable a particular cron it will not cause that action to execute instantly, but rather it will not be executed at all! Hopefully I've responded quick enough to catch you before you disable the provisioning of pending orders.

[Alex]

I am a little confused here as 5 minute wait on cron is standard in the industry. Some of the larger providers actually endup setting it to 15 minutes on allocation.

 

It depends on the task the cron is performing. I deal with a multitude of vendors whom have ticketing systems and none of them wait more than 1 minute to poll the mail server for new tickets. (Rackspace, Google, Enom... none of them, even the "larger providers".) Not that I have access to their systems, but the fact that emails sent to them consistantly receives an automated receipt confirmation response email from their ticket system in less than a minute...

 

A cron is just the scheduled execution of a task, so stating any cron frequency is "standard" really makes no sense considering that cron frequency should depend on the task the cron is executing. In the case of downloading tickets, I would argue that the "standard" frequency is more often than 5 minutes.

 

I also think account creation should be done every minute and not every five.

Yes, this is another good example where increased cron frequency would be useful.

Blesta already has the flexibility to schedule particular tasks to happen more often than others, so I can't see why this would be a big development task. We would just need to change our cron job to run every minute if they add the option for some tasks to be that frequent. But, tasks scheduled at 5 minute intervals would still only be run every 5 minutes, based on the testing I have done with the current system.

[Ken]

+1 for this request

[Andreas]

I dont understand why there is all these cron jobs period.  Such as when a user purchases a new service. Why doesn;t it get executed right away.  Why is a cron job needed to do this task?

[Alex]

I dont understand why there is all these cron jobs period.  Such as when a user purchases a new service. Why doesn;t it get executed right away.  Why is a cron job needed to do this task?

 

Batch processing is a common technique when building scalable systems. It allows the system to scale with the needs instead of having a static overhead / demand ratio. In the case of provisioning it may have been fine to run the task when a service is paid for; I'm not quite sure why they used a cron for that. Maybe the developers can shed some light on that. But, in the case of downloading ticket emails it is clear why they used a cron, because there is no other trigger to tie the event to. For me it's less about whether these should be cron jobs at all and more about making sure the individual cron tasks are flexible enough to be run more frequently than 5 minutes.

[Alex]

Agreed. Support tickets need to be polled much quicker.

 

I also think account creation should be done every minute and not every five. 

 

+1 for this request

 

Thanks for the support on this feature request everyone. I didn't expect this much support so quickly but I'm glad I'm not alone on this.

[hostingDifferent-Scott]

NO problem. My cron isn't working automatically. It works fine when run manually, but doesn't auto run. When I add the cron manually to my domain, it causes an error. Weird all the way around.

[Alex]

NO problem. My cron isn't working automatically. It works fine when run manually, but doesn't auto run. When I add the cron manually to my domain, it causes an error. Weird all the way around.

 

Well, I have no problem with the cron working as expected. This may be an issue specific to your installation, or I think we would have heard about it by now.

[Paul]

I dont understand why there is all these cron jobs period.  Such as when a user purchases a new service. Why doesn;t it get executed right away.  Why is a cron job needed to do this task?

 

There are a few reasons..

1. Working over an API can be slow, it can take a long time for the hosting account (or whatever) to be provisioned. The user should not have to wait for this.
2. The request could time out.
3. If a module fails, for whatever reason, it shouldn't prevent the order from being placed.
4. Orders can be approved automatically or manually approved.
5. If an order is set for automatic approval, and the customer pays with PayPal or another non-merchant gateway, the service cannot be activated while the user is present, and it's not a good idea to do it when payment comes in from the gateway for the same reason as #1 above.

If adding a primary service as an admin via the client profile, the service is provisioned immediately. The system for approving "pending" services via cron doesn't need to take into account any special circumstances, such as whether the order should be approved automatically, or manually, or whether payment has come in at the time of order or after order, or anything else. The system is autonomous.

 

On average, with a 5 min cron, the user has to wait 2.5 minutes.

 

Separately for trouble tickets, 5 minutes is a long time to wait (2.5 min on average) for an update to be reflected in the system. Where this matters, we recommend using ticket piping.

 

There may be a case for 1 minute crons, but we feel a 5 minute cron lends more to stability. Blesta is very careful about not running the same task in duplicate, which is critical to prevent issues. A 1 minute cron may push up against this feature frequently, with mixed results. A change to the cron is something we may consider in the future, but the last thing we want to do is introduce any issues so it's an area we will tread lightly. Stability is more important.

[hostingDifferent-Scott]

I didn't notice it wasn't running until I logged in today and saw that it hadn't been logged in since I ran it manually a week ago. I copied the command into directadmin and it runs, but get an ioncube error even though ioncube is running on the server. 

[Paul]

Ioncube may not be running via CLI. Can you SSH in and run..

 

php -i | grep IonCube

 

.. and see if there is any output? If there isn't, maybe it's running off a different php.ini file.

 

 

php -i | grep php.ini

 

Alternatively you can run it with GET or wget.

 

for example: GET -t 15m https://www.yourdomain.com/blesta/install/path/cron/?cron_key=CRONKEY where CRONKEY is your cron key as displayed under "Update Cron Key" (From http://docs.blesta.com/display/user/Installing+Blesta)

[hostingDifferent-Scott]

my php.ini file is located here: /usr/local/lib/php.ini

[Paul]

my php.ini file is located here: /usr/local/lib/php.ini

 

Does in include the ioncube loaders in it?

[hostingDifferent-Scott]

Yes, it does. I changed my cron to /usr/local/bin and now it works. Apparently, there's php in two different locations.

[Paul]

Yes, it does. I changed my cron to /usr/local/bin and now it works. Apparently, there's php in two different locations.

 

That's what I was worried about, glad you got it working!

[hostingDifferent-Scott]

Me, too.

 

Now just to get email piping to work. LOL That's another thread.